Defense Evasion Incident #1 The threat actor executed two actions to bypass Windows Defender [T1562.001 – Impair Defenses: Disable or Modify Tools] 5001 - Real-time Protection was disabled New Value">HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\C:\ Guidance The first line of defense available to organizations is to use a security agent that has robust tamper protection.


In terms of monitoring for this activity, these are detection-ready event sources.


While its possible a system administrator would make such exceptions during troubleshooting, given the risk of this activity, it’s something that should be investigated promptly if a corresponding support ticket isn’t found.


Command and Control Incident #1 During this incident, the threat actor leveraged one of the most popular dual-use agents, AnyDesk, to provide persistent remote access into the affected organization on multiple systems.


[T1219 – Remote Access Software] UserAssist entry: 86 Value name: C:\Users\administrator.<Redacted> \AppData\Local\Microsoft\Windows\INetCache\IE\14J9H2AA\AnyDesk.exe Count: 1 Event ID [7045] "Service Name: Anydesk" "C:\Program Files (x86)\AnyDesk\AnyDesk.exe"" --service" Prefetch


[ANYDESK.EXE] was executed - run count 9 path: \PROGRAM FILES (X86)\ANYDESK\ANYDESK.EXE hash: 0x389EE9E9 volume:


1 [serial number: 0x7077BC2C device path: \VOLUME{01cf89bc76f2a351-7077bc2c}] Incident #2 The threat actor almost immediately installed Cloudflare’s freely available tunnelling software here, C:/ProgramData/windows_update.exe, followed by the download and execution of another dual-use agent, Radmin [T1572 – Protocol Tunneling ]


All non-approved remote access solutions should be blocked by default by an application control capability.


A good approach to prevent theft of data is to adopt least privilege access, which means ensuring only the required people have access, followed by granular controls on exporting, sharing, or moving the files.


Impact Incident #1 C:\ProgramData\Update.bat file executed the ransomware binary dllhost32.exe, which is detected as Troj/Ransom-GWA by Sophos (Figure 4)


[T1490 – Inhibit System Recovery] dllhost32.exe -n=10 -s


=C:\ESD\sharez.txt dllhost32.exe -n=1 -s


=C:\program files\sharez.txt powershell.exe -Command "Get-WmiObject Win32_Shadowcopy


| Remove-WmiObject" –n option is for encryption percentage, the attacker used different settings during the incident -s option is for –share_file, there is a –p option for –encryption_path Removing the shadow copies prevents recovery using native Window’s features and Sophos detects this as Impact_6a.


[T1490 – Inhibit System Recovery] Creates the C:\fn.txt ransom note when complete Dwell time of 30+ days before executing ransomware As previously reported by Bleeping Computer, Akira targets 26 specific file extensions for encryption.


Notably, it it does not target PDFs or typical Microsoft Office file types: .abcddb .accdb .accde .accdc .accdt .accdr .accdw .accft .dacpac .daschema .dadiagram .db-shm .db-wal .fmpsl .fmp12 .kexic .kexis .nrmlib .sas7bdat .sqlite .sqlitedb .sqlite3 .xmlff .nvram .subvol .qcow2 SophosLabs researchers have also confirmed which file extensions are avoided by Akira in order to not impact system stability.


In the case of Sophos, it’s critical for customers to have their CryptoGuard policy activated, which is something support can guide customers on.


rule ecrime_AKIRA_strings { meta: id = "8c59c35d-8fb8-4644-9fa4-ce05b30e91c3" version = "1.0" author = "Paul Jaramillo" intrusion_set = "AKIRA" description = "Detects common strings" source = "PE binaries" creation_date = "2023-05-03" modification_date = "2023-05-09" classification = "TLP:CLEAR" strings: $s1 = ".akira" ascii nocase $s2 = "akira_readme.txt" ascii nocase $s3 = ".onion" ascii nocase $s4 = /\\akira\\asio\\include\\asio\\impl\\co_spawn\.hpp/ $s5 = /MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAylJbjtFvzHapC/ condition: (filesize>250KB and filesize<1MB) and uint16(0) == 0x5A4D and uint32(uint32(0x3C))


== 0x4550 and (($s1 and $s2 and $s3) or $s4 or $s5) } Please be aware that threat actors will continue to modify the code, which was evident when we uncovered the following new file name being used “readme-asldkas.txt”.


Conclusion Sophos MDR is sharing this information with the specific goal of aiding defenders in the seemingly never-ending battle with ransomware threat groups.


Through each of the covered steps in the attack flow, specific guidance is provided to drive actions with context.


Aside from the differences in C2 tools used (AnyDesk vs Cloudflared), one of the key points to highlight is the dwell time.


Incident #1 had a dwell time of 7 days compared to incident #2 with over 30 days of dwell time.


Both of these events demonstrate a slower operational tempo, which bodes well for defenders having opportunities to disrupt in-flight compromises.


The time from initial access to ransomware impact is indicative of the complex e-crime ecosystem, where there are distributors, initial access brokers, malware developers, and ransomware affiliates working together from resource development to payment.


Adwind Trojan Circumvents Antivirus Software To Infect Your PC url: https://www.anomali.com/blog/wtb-adwind-trojan-circumvents-antivirus-software-to-infect-your-pc

WTB Adwind Trojan Circumvents Antivirus Software To Infect Your PC


The intelligence in this week’s iteration discuss the following threats: Credit card theft, DDoS, Phishing, Ransomware, Trojan, Vulnerabilities, and Web cache poisoning.


Unknown threat actors have been observed conducting a spear phishing campaign that targets various industries such as finance, manufacturing, shipping, telecoms, and others targeted upon machines in Germany and Turkey in an effort to infect the targets with a Remote Access Trojan (RAT), “Adwind.”


MacOS, Windows and Linux operating systems are all vulnerable to this particular jRAT.


This specific malware is observed to log keystrokes, steal credentials, tamper with system files as all RATs do, but also steals cryptographic keys to access cryptocurrency wallets on infected systems.


This jRAT is spread via spear phishing emails that contain a .csv or .xlt file attachment with a so-called Dynamic Data Exchange (DDE) code injection that intends to compromise Microsoft Excel and circumvent signature-based antivirus protections.


The threat actor behind the attack modified the RAT to have a low-detection rate.


[MITRE ATT&CK] Dynamic Data Exchange (T1173) |


Spearphishing Attachment (T1193)


AdGuard Reset User Passwords After Enduring Credential Stuffing Attacks (September 24, 2018) Ad-blocking software company AdGuard reported that they had recently suffered a cyber-attack in the form of credential stuffing, and issued a password reset to all users for all accounts.


They noticed repeated login attempts from suspicious IP addresses belonging to a variety of servers world-wide, using login credentials from what the company suspects are past data breaches from other companies.


Associate Professor Zhiyun Qian and doctoral student Weiteng Chen from the University of California discovered a vulnerability in unencrypted Wi-Fi routers that makes them susceptible to a TCP exploit.


The exploit can be employed when threat actors intercept the communication between the router and a user’s machine, and send a malicious payload that appears legitimate to poison the web cache.


This allows the threat actor to inject a malicious copy of a web page (typically a login or checkout page one is visiting) so that every time that page is visited, it is the compromised version.


This has the potential to give the actor access to the information and credentials entered in those sites.


A bug has been identified in Microsoft JET Database Engine that could allow remote execution.


This bug is an out-of-bounds write (when software writes data past the end, or before the beginning of the intended buffer, hence “out-of-bounds”) that can be triggered through opening a Jet data source via OLEDB.


At the time of the article’s publication, a patch has yet to be released.


A Distributed-Denial-of-Service (DDoS) vulnerability was discovered to affect Bitcoin Core versions 0.14.0 up to 0.16.2 that could bring down the entire Bitcoin blockchain by flooding full node operators with traffic.


The vulnerability originates in the consensus code and allowed for Bitcoin miners to have the option of sending transaction data twice.


This would cause the Bitcoin network to crash whilst it attempted to validate the duplicate transaction.


This type of DDoS attack, however, would require the threat actor to basically throw away 12.5 BTC ($80,000 USD) to actually cause any damage to the network, so it is unlikely it will be exploited.


Bitcoin software developers have issued a patch for anyone running nodes.


Click here for Anomali recommendation Flaw In 4GEE WiFi Modem Could Leave Your Computer Vulnerable (September 20, 2018) Security researcher, Osanda Malith, from ZeroDayLab discovered a severe vulnerability in 4G-based wireless 4GEE Mini modems sold by mobile operator, EE.


This vulnerability, registered as “CVE-2018-14327,” allows a low-privileged user account to escalate privileges on any Windows machine that had connected to the EE Mini modem via USB.


For an attacker to exploit this vulnerability, they just have to replace the “ServiceManager.exe” file from the driver folder with a malicious file to trick the driver into running the tainted file and executing with higher SYSTEM privileges following a reboot.


A patch has been released for this vulnerability by EE.


[MITRE ATT&CK] File System Permissions Weakness (T1044)


This Windows File May Be Secretly Hoarding Your Passwords And Emails (September 19, 2018) Windows machines that have handwriting recognition features enabled that translate stylus and touchscreen writing into formatted texts are susceptible to a Windows “WaitList.dat” file storing sensitive information, such as passwords, without the user’s knowledge.


However, once the handwriting recognition feature is enabled, text from every document and email is indexed into this file, not only the files that interacted with the touchscreen feature.


This means that if threat actors gained unauthorised access to this specific file on a machine, they would have access to sensitive data that is unwittingly stored in it, compromising many facets of information.


Click here for Anomali recommendation Magecart Strikes Again: Newegg


In The Crosshairs (September 19, 2018) E-Commerce company, Newegg, is the latest victim of credit card-skimming campaign by threat group, MageCart.


Between late August and early September 2018, MageCart stole credit card data from British Airways and Feedify, and appear to have used the same malicious JavaScript code to compromise the Newegg checkout page to obtain card credentials.


This particular breach of information occurred between August 13, 2018 and September 18, 2018.


Both data theft campaigns against Newegg and British Airways appear to have occurred around the same time, with the Newegg campaign starting a week earlier than the British Airways campaign.


[MITRE ATT&CK] Drive-by Compromise (T1189) Authentication Bypass Vulnerability In Western Digital


A vulnerability in the “My Cloud” devices from the storage solutions company, "Western Digital," was discovered.


This vulnerability, registered as “CVE-2018-17153,” can allow for unauthorised actors to bypass authentication and register their activity on a specific IP address as an administrator.


A threat actor could establish an administrator session using the “network_mgr.cgi CGI” module in the HTTP and set the IP address as an admin session that will allow the actor to bypass future authentication when logging into the device over the internet.


At the current publication of the article, a patch has not been developed or released.


[MITRE ATT&CK] Account Manipulation (T1098) Paste Site Used As Hosting Service For FilesMan Backdoor (September 18, 2018)


Researcher Bruno Zanelato discovered a backdoor, called “FilesMan,” dropped into several websites due to a pre-existing PHP file placed into the website’s structure by threat actors.


The PHP file “wp-content/themes/buildup/db.php” decrypts that specific payload code to the install the FilesMan backdoor that allows the threat actor to gain access to a website through their own machine.


[MITRE ATT&CK] Shared Webroot (T1051) Bristol Airport Flight Display Screens Failed After Ransomware Incident (September 18, 2018)


Flights were able to operate as normal, though the airport did request that travellers arrive to the airport earlier to allow extra time for checking in and the boarding process.


Security officials reported that no ransom was paid and the safety of the security systems remain unaffected during the cyber incident.


Click here for Anomali recommendation Just 13 – No, Er, Make That 3,200 Punters Hit In Oz's Perth Mint Hack (September 18, 2018)


A security breach at the Australian government’s official mint “Perth Mint” that was initially believed to have only affected 13 customers, has ended up actually affecting over 3,200 customers.


The company contacted affected customers to notify them of the breach and that their personal information was breached, but their investments were not impacted and are secure.


Click here for Anomali recommendation Beware Of Emails Purporting To Be From The IRS (September 17, 2018)


Researchers at Fortinet discovered a recent phishing email campaign pretending to be from the US Internal Revenue Service (IRS).


The file does not contain any malicious macros or code, so it appear to be clean to open on a computer.


The email asks the target to file out the attached form and then fax it over to a specific fax number.


The objective of this campaign is to steal Personally Identifiable Information (PII).


Click here for Anomali recommendation Tenable Research Advisory: Peekaboo Critical Vulnerability In NUUO Network Video Recorder (September 17, 2018)


Researchers at Tenable Research discovered two vulnerabilities in monitoring and surveillance company NUUO’s “Network Video Recorder” software in the “NVRMini2” network-connected, video recording device.


The second vulnerability, CVE-2018-1150, is a backdoor that is believed to be caused by leftover debug code, and allows the list of all user accounts on a system to be accessible with their passwords capable of being manipulated.


Changing the passwords could then allow a threat actor access to that account with their own passcode, and then sign on as a legitimate user to view camera feeds or CCTV footage and recordings as well as delete a camera from a system completely.


These vulnerabilities could allow threat actors to tamper with security footage and live feeds.


A patch is currently in development for both vulnerabilities.


[MITRE ATT&CK] Third-party Software (T1072)


Backdoor authors show deep knowledge of the targeted POS software, decrypting database passwords from Windows registry values ESET researchers have discovered ModPipe, a modular backdoor that gives its operators access to sensitive information stored in devices running ORACLE MICROS Restaurant Enterprise Series (RES) 3700 POS – a management software suite used by hundreds of thousands of bars, restaurants, hotels and other hospitality establishments worldwide.

Hungry for data ModPipe backdoor hits POS software used in hospitality sector


What makes the backdoor distinctive are its downloadable modules and their capabilities.


One of them – named GetMicInfo – contains an algorithm designed to gather database passwords by decrypting them from Windows registry values.


Exfiltrated credentials allow ModPipe’s operators access to database contents, including various definitions and configuration, status tables and information about POS transactions.


However, based on the documentation of RES 3700 POS, the attackers should not be able to access some of the most sensitive information – such as credit card numbers and expiration dates – which is protected by encryption.


The only customer data stored in the clear and thus available to the attackers should be cardholder names.


This would limit the amount of valuable information viable for further sale or misuse, making the full “business model” behind the operation unclear.


One possible explanation is that another downloadable module exists that allows the malware operators to decrypt the more sensitive data in the user’s database.


According to the documentation, to achieve this the attackers would have to reverse engineer the generation process of the “site-specific passphrase”, which is used to derive the encryption key for sensitive data.


This process would then have to be implemented into the module and – due to use of the Windows Data Protection API (DPAPI) – executed directly on the victim’s machine.


The majority of the identified targets were from the United States, with indications that they were in the restaurant and hospitality sectors – the primary customers of RES 3700 POS.


persistent loader – unpacks and loads the next stage of the malware, namely the main module.


main module – performs the main functionality of the malware.


It creates a pipe used for communication with other malicious modules, un/installs these modules and serves as a dispatcher that handles communication between the modules and attacker’s C&C server.


Overview of ModPipe backdoor architecture Downloadable modules Probably the most intriguing parts of ModPipe are its downloadable modules.


We’ve been aware of their existence since the end of 2019, when we first found and analyzed its “basic” components.


In April 2020, after a couple of months of hunting, we found three of these modules in the wild.


Our research also suggests that the operators use at least four other downloadable modules, whose functionality remains completely unknown to us for now.


It’s worth mentioning that some of these modules can create a named pipe with a GUID-formatted name derived from the module’s ID.


Other modules can use this pipe to send commands to the module that created it.


This information is encrypted and stored in DataS5 (for dba) and DataS6 (for micros) registry values within one of the following registry keys: HKLM\Software\Micros\UserData or HKLM\Software\WOW6432Node\Micros\UserData if run in Windows 32-bit on Windows 64-bit (WOW64) subsystem Figure 2.


So as not to aid other malicious actors, we won’t be disclosing the inner workings of the algorithm.


The attackers could have gained the information describing the implementation of the encryption and decryption mechanism from a 2016 data breach described in a blogpost by Brian Krebs.


Our analysis shows that in cases where the GetMicInfo module decrypts the password for the dba username, it will also try to acquire the path to the SQL Anywhere API library from the environment variable “SQLANY_API_DLL” and load it if it’s available.


This library is a part of Sybase SQL Anywhere, which is used by RES 3700 POS.


If one of these approaches is successful, GetMicInfo attempts to connect to the database using the following connection string: DBN=micros;UID=dba;ENG=sql%PCNAME%;PWD=%decrypted_DataS5% %PCNAME% represents the computer name retrieved via the GetComputerName API and %decrypted_DataS5% stands for the decrypted dba user password.


After establishing a connection, GetMicInfo tries to execute the following SQL queries and report the results to the main module, using a pipe message with ID 0x10000013 (see Table 3 for a full list of pipe messages and their IDs): SELECT lan_node_seq,obj_num,name,lan_addr,ob_diskless,type,ip_addr,ip_netmask FROM micros.lan_node_def SELECT dvc_tbl_seq,obj_num,name,type,com_port_seq,com_port,baud_rate,num_data_bits,num_stop_bits,parity_type,filename FROM micros.dev_def SELECT tmed_seq,obj_num,name,type,ca_driver,edc_driver FROM micros.tmed_def SELECT *


FROM micros.caedc_driver_def SELECT *


Other information stolen by the module includes the version of the MICROS POS and information about specific registry keys most likely related to various credit card services configurations.


For all the other versions, we were able neither to confirm nor deny the ability of the component to obtain the targeted libraries.


Downloadable module: ModScan 2.20


The main purpose of ModScan 2.20 is to collect additional information about the installed MICROS POS environment on the machines by scanning selected IP addresses.


The list of IP addresses intended for scanning and the special “ping” IP address are specified by the C&C in one of two ways.


It is either: downloaded from the C&C along with the ModScan module, or received during runtime, using the named pipe associated with the ModScan module.


The ModScan module handles pipe commands listed in Table 2. Table 2.


ModScan 2.20 module pipe commands Command nameCommand description exitExit stopTerminate scanning threads scanStart scanning IPs specified in the command data to collect additional information about the environment prmSpecify special “ping” IP address Scanning procedure routine Before scanning, the module sends a special “ping” message containing a 32-bit value generated by the GetTickCount Windows API function to TCP ports 50123 (used by MDS HTTP Service) and 2638 (used by SAP Sybase database server) of the “ping” IP address.


The response from the “ping” IP address should contain the same 32-bit value rotated right by one bit and XORed with the value 0x6CF6B8A8.


If the response on at least one of the ports provides the appropriate value, the module will start the scan of the selected IP addresses.


A decompilation of this ping function is shown in Figure 4. Figure 4.


HTTP/1.1Accept: text/xmlUser-Agent: MDS POS ClientHost: %s:50123Content-Length: 459Connection: Keep-AliveCache-Control: no-cache <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:MCRS-ENV="MCRS-URI"> <MCRS-ENV:Service>MDSSYSUTILS</MCRS-ENV:Service> <MCRS-ENV:Method>Reg_GetValue</MCRS-ENV:Method> <MCRS-ENV:SessionKey>Session</MCRS-ENV:SessionKey> <MCRS-ENV:InputParameters> <Key>SOFTWARE\MICROS</Key> <KeyType>HKEY_LOCAL_MACHINE</KeyType> <KeyName>Version</KeyName> </MCRS-ENV:InputParameters> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 5.


MDS HTTP Service request Name of the database, extracted by sending a specially crafted TCP packet (possibly using the CMDSEQ command protocol) to the selected IP address on port 2638 used by the SAP Sybase Database Server.


The string representing the name of the database is located at offset 0x28 of the response sent by the database server.


Database server data, such as its name, version of the TDS protocol and the TDS server version.


To gain this information, the ModScan module sends a hardcoded TDS 4.2 & 5.0 Login Packet (Figure 6) to the specified IP address on port 2638.


The TDS login packet is hardcoded, with username set to the built-in dba and a hardcoded password, which is potentially the default password in some RES 3700 POS versions.


As we haven’t found any public reference to this password, we won’t be publishing it in our blogpost. Figure 6.


TDS 4.2 & 5.0 Login Packet used by the ModScan module, dissected using Wireshark Downloadable module: ProcList


The last of the downloadable modules we were able to obtain and dissect was ProcList.


Its main purpose is to collect information about currently running processes, including: name, process identifier (PID), parent process PID, number of threads, token owner, token domain, process creation time, and command line.


Optionally, ProcList can also collect information about loaded modules for each of the running processes.


Collected information is sent to the main module of the backdoor (using pipe message 0x10000013).


During our investigation, we discovered one dropper executable on two compromised machines, stored in the following locations: C:\IQXDatabase\Live\1.exe C:\OasisLive\1.exe Each time the initial dropper is executed, a unique configuration is generated, using mostly random bytes.


This causes the hash of the dropped loader to change with each execution, complicating detection and tracking of the malware.


The dropper component can drop the loader into two possible locations and set up the persistence mechanism by creating a Windows service or Windows registry Run key (for details, please refer to the Indicators of Compromise section).


The dropper decrypts this payload using the provided command line parameter, then executes it.


Each of the loaders is encrypted using its own XOR key, each 0x80 bytes long.


Decompiled code responsible for loading the payload from the binary’s resources, its decryption and execution is shown in Figure 7.


Hex-Rays decompiled code – decryption and execution of the payload in the initial dropper An example of an encrypted and decrypted configuration with explanations is visible in Figure 8.


The configuration shown comes from the loader installed by the dropper sample with SHA-1 hash 9f8530627a8ad38f47102f626dec9f0173b44cd5.


Note that the structure of the configuration can vary between older and newer versions of the loader executable.


Example of the loader’s generated configuration (upper is encrypted, lower decrypted)


Persistent loader This component is responsible for both unpacking the main module and for its injection into one of the following processes: lsass.exe wininit.exe services.exe To unpack the main module, the persistent loader uses different approaches for the 32-bit and 64-bit versions.


While the 32-bit loader is almost identical to the initial dropper – the only difference being the payloads stored in the resources – the 64-bit loader uses completely different “unpacking” code.


A list of all the loader hashes is included in the Indicators of Compromise section.


Timeline of known ModPipe variants and their timestamps.


Main module The main module is mostly responsible for managing C&C communication and for handling received messages/commands, either from C&C or downloadable modules.


To facilitate the communication with modules, the main module starts by creating a pipe with a randomly generated name formatted using the following format string: {%08X-%04X-%04X-%04X-%08X%04X}


It then periodically checks the pipe for new messages using the PeekNamedPipe Windows API function.


Messages are parsed and handled according to their content.


For a full list of recognized pipe commands and messages see Table 3. Table 3.


0x10000014write requested configuration data to the file handle received in this message (most likely handle to named pipe created by some other module) (main config, network config, loader name, main module PID, ...) 0x10000020C&C commands (not encrypted) – see Table 4 for the full list of available commands 0x10000022set module status (or err code)


Structure of the main module’s named pipe messages For communication with its C&C server, the main module uses HTTP and port 80.


Each of the dissected samples contained a list of potentially available servers from which one was randomly chosen.


A list of all C&C addresses discovered over the course of our research is available in the Indicators of Compromise section.


Messages sent to the C&C (see Figure 11) are constructed and encrypted within the main module’s code.


Communication with the C&C is encrypted using AES in CBC mode with the following 128-bit key:


Before encryption, C&C messages start with a 4-byte checksum, which is calculated as CRC32 (message) XORed with the first 4 bytes of the AES key used to encrypt the message.


In the case of the key mentioned above, this would be F4 5D 07 6F. The data is transmitted using the lightweight networking module, which is injected on demand and exits immediately after uploading or downloading the requested message.


To select the process for injection, the main module enumerates running processes and assigns them a priority value between 3 and 6.


Those with higher priority are injected first, based on the following criteria: Priority 6 The highest priority, assigned to any process that has already been used successfully to inject a networking module, received a response from the C&C and that is still running under the same PID, name and CreationTime.


Priority 5 Process name with no extension that matches one of the following process names used for browsers: iexplore, opera, chrome, firefox Priority 4 Process name with no extension that matches the following process names: explorer, svchost Priority 3 All the other running processes excluding the following system processes: system, lsass, csrss, lsm, winlogon, smss, wininit The main reason behind the priority list is to inject processes that are expected to communicate over the network and at the same time avoid system processes that might attract attention if caught communicating over the network.


Networking module This ModPipe module is responsible for sending requests to C&C and parsing payload received in the C&C responses.


HTTP GET message header Responses from the C&C server have to be at least 33-bytes long in order to be parsed by the networking module and the malicious payload is located after a sequence of 13 spaces followed by an HTML comment opening tag.


An example of a server response including this sequence is shown in Figure 14.


The main module then decrypts the payload, verifies its checksum and executes the C&C command.


Available commands are listed in Table 4.


Table 4.


0x0FSave network configuration to the encrypted storage Conclusion ModPipe shows quite a few interesting features.


By acquiring the database passwords, the attackers gain broad access to sensitive information even though the most sensitive data stored in devices running RES 3700 POS should still be protected by encryption.


The proficiency of the operators could stem from multiple scenarios, including stealing and reverse engineering the proprietary software product, misusing its leaked parts or buying code from an underground market.


To keep the operators behind ModPipe at bay, potential victims in the hospitality sector as well as any other businesses using the RES 3700 POS are advised to: Use the latest version of the software.


Use it on devices that run updated operating system and software.


Dropper samples 9F8530627A8AD38F47102F626DEC9F0173B44CD5 FEE9C08B494C80DBF73A6F70FACD20ED0429330D Loader samples 0D1A4CB620576B8ADD34F919B4C6C46E7C3F9A59 B47E05D67DC055AF5B0689782D67EAA2EB8C75E3 F213B4EEF63F06EC127D3DC3265E14EE190B71E5 B2CE307DFE65C188FDAE169ABD65B75B112522C4 2AC7A2C09E50EAFABF1F401194AC487ED96C6781 0F4355A17AABD3645788341EAC2A9BB759DB95EE


File paths %CSIDL_APPDATA%\Microsoft\Windows\{%rand_guid%}\explorer.exe %WINDIR%\system32\%random_name%.exe %rand_guid% – pseudo-random GUID formatted string %random_name% – from 4 to 7 pseudo-random letters (a-z) with the first one capital e.g. “Cvoeqo.exe” MITRE ATT&CK techniques Note: This table was built using version 7 of the MITRE ATT&CK framework.


Windows Command ShellAttackers were seen using Windows Command Shell to execute the initial dropper. PersistenceT1547.001Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderModPipe can use Registry Run key for persistence.


T1543.003Create or Modify System Process:


Windows ServiceModPipe can create a new service for persistence.


Privilege EscalationT1134.001Access Token Manipulation:


Token Impersonation/TheftAttackers were seen using partially modified PrintSpoofer tool to drop and subsequently execute loader with SYSTEM privileges.


Defense EvasionT1055.002Process Injection: Portable Executable InjectionModPipe can inject it’s modules into various processes.


T1205Traffic SignalingModPipe’s ModScan module sends random 32-bit values to TCP ports 50123 and 2638 of the specified IP address and requires a specific response in order to continue executing its scan functionality.


Credential AccessT1552.002Unsecured Credentials: Credentials in RegistryModPipe’s GetMicInfo module retrieves encrypted database passwords for ORACLE MICROS RES 3700 POS software from Windows Registry and uses a custom algorithm to decrypt them before uploading to the C&C. DiscoveryT1057Process DiscoveryModPipe’s ProcList module can get information about processes running on a system.


T1012Query RegistryModPipe’s GetMicInfo module queries the Registry for ORACLE MICROS RES 3700 POS version, database passwords and other configuration data.


T1033System Owner/User DiscoveryModPipe gathers username and computer name from victim machines and reports them to the C&C in initial message.


Symmetric CryptographyModPipe encrypts communication with C&C using AES in CBC mode.


12 Nov 2020 - 11:30AM


Sophos X-Ops is tracking a developing situation concerning a seeming supply-chain attack, possibly undertaken by a nation-state-related group.

Update 2 3CX users under DLLsideloading attack What you need to know


We will update this page as events and understanding develop, including our threat and detection guidance.


[Latest version published 23:00 UTC 01-April-23, adding Troj/Steal-DLG to Detection Protections/Static detection, two more queries customers may use to determine their exposure to the attack, new analysis of an emergent line of inquiry concerning a timestamp mechanism in the malicious code, and information on analysis of other Electron-built apps using ffmpeg.dll 23:30 UTC 30-March-23, adding detail on affected versions, misuse of ffmpeg.dll, removal of malicious repository, comparison of PE shellcode loader to that used by Lazarus threat group, more queries customers may use to determine their exposure to the attack, and various additional detections] Overview The affected software is 3CX – a legitimate software-based PBX phone system available on Windows, MacOS, Linux, Android, and iOS.


The software is a digitally signed version of the softphone desktop client for both Windows and MacOS, which includes a malicious payload.


The most common post-exploitation event we have observed to date is the presence of an infostealer that targets the browser(s) on a compromised system.


At this writing, 3CX has deprecated the affected versions of the Windows application.


At present, the only platforms confirmed by our customer data to be affected are Windows and MacOS, which is in agreement with 3CX’s information on affected platforms.


According to information on their support forum, Android and iOS versions of the software are not believed to be affected.


Threat analysis On March 22, users of 3CX began discussion of potential false-positive detections of 3CXDesktopApp by their endpoint security agents.


Figure 1: The update process at the moment the malicious version drops Sophos MDR first identified malicious activity directed at its own customers and stemming from 3CXDesktopApp on March 29, 2023.


Additionally, Sophos MDR has observed the campaign leveraging a public file storage to host encoded malware.


This repository has been in use since December 8, 2022; after news of the compromise spread widely on March 29, the repository was taken down.


The attack revolves around a DLL sideloading scenario, one with a remarkable number of components involved.


This is likely to ensure that customers were able to use the 3CX desktop package without noticing anything unusual about the affected package.


We have identified three crucial components: 3CXDesktopApp.exe, the clean loader d3dcompiler_47.dll, a DLL with an appended encrypted payload ffmpeg.dll, a Trojanized loader Figure 2 presents a high-level look at the attack flow as it works in Windows; there are some minor variations in the later steps with the MacOS version.


Figure 2: A high-level view of the attack flow The file ffmpeg.dll contains an embedded URL which retrieved a malicious encoded .ico payload from GitHub file storage at https[:]//raw.githubusercontent.com/IconStorages/images/main/ — though, again, once news of the compromise spread widely, this repository was taken down.


We saw several variations on the ffmpeg.dll file, including one that was signed by 3CX’s own certificate; these appear to be maliciously patched versions of the legitimate ffmpeg.dll.


In a statement on Thursday, the team responsible for ffmpeg’s source code took pains to distance their work from the 3CX compromise.


Figure 3: When ffmpeg stepped onto Twitter to defend its code In a normal DLL sideloading scenario, the malicious loader (ffmpeg.dll) would replace the clean dependency; its only function would be to queue up the payload.


However, in this case, that loader is also entirely functional, as it would normally be in the 3CX product – instead, there’s an additional payload inserted at the DllMain function.


This adds bulk, but may have lowered suspicions – the abused 3CX application functions as expected, even as the Trojan addresses reached out to the C2 beacon.


We conclude from this that this compromise does not affect other Electron apps — only the 3CX ffmpeg.dll. Figure 4: What the affected 3CX developers and customers experienced Allowing the abused software to remain functional is not dissimilar to other DLL sideloading cases we’ve seen, but this campaign is slightly different even from the current rash of DLL sideloading cases we’ve seen.


In particular, we’ve noted that the PE shellcode loader in use is unique in our experience.


Previous to this, we’ve only seen it in incidents attributed to the Lazarus group; the code in this incident is a byte-to-byte match to those previous samples.


TimeStamp Check Analysis As part of our ongoing investigation, we found a timestamp mechanism in the code as shown below.


The results of check_timestamp are evaluated against “v6,” a variable which holds the value coming from cbData.


cbData is collected from the “manifest” file as shown below.


Figure 6: Collecting the cbData “manifest” is a file that the malware writes to the system under the “3cxdesktopapp” folder during the initial stage of the infection.


When the manifest is created, a dword value is written based on the current timestamp, with additional arithmetic operations performed on it.


In other words, the value be up to a total of 28 days ahead.


So long as the results of check_timestamp are less than v6 (the timestamp value from manifest), the loop continues to sleep.


Only once the results of check_timestamp are greater than the manifest timestamp will the code proceed and generate the HTTP request to connect with GitHub, which initiates the payload download.


Hunting information Determining impact with Sophos XDR 1.


Determining whether hosts have communicated with threat actor infrastructure:


Data Lake The below query will search for hosts that have communicated with the various known URLs in use by this campaign.


SELECT meta_hostname, sophos_pids, domain, clean_urls, source_ips, destination_ips, timestamps, ingestion_timestamp FROM xdr_data WHERE query_name = 'sophos_urls_windows' AND (LOWER(domain) LIKE '%akamaicontainer[.]com%' OR LOWER(domain) LIKE '%akamaitechcloudservices[.]com%' OR LOWER(domain) LIKE '%azuredeploystore[.]com%' OR LOWER(domain) LIKE '%azureonlinecloud[.]com%' OR LOWER(domain) LIKE '%azureonlinestorage[.]com%' OR LOWER(domain) LIKE '%dunamistrd[.]com%' OR LOWER(domain) LIKE '%glcloudservice[.]com%' OR LOWER(domain) LIKE '%journalide[.]org%' OR LOWER(domain) LIKE '%msedgepackageinfo[.]com%' OR LOWER(domain) LIKE '%msstorageazure[.]com%' OR LOWER(domain) LIKE '%msstorageboxes[.]com%' OR LOWER(domain) LIKE '%officeaddons[.]com%' OR LOWER(domain) LIKE '%officestoragebox[.]com%' OR LOWER(domain) LIKE '%pbxcloudeservices[.]com%' OR LOWER(domain) LIKE '%pbxphonenetwork[.]com%' OR LOWER(domain) LIKE '%pbxsources[.]com%' OR LOWER(domain) LIKE '%qwepoi123098[.]com%' OR LOWER(domain) LIKE '%sbmsa[.]wiki%' OR LOWER(domain) LIKE '%sourceslabs[.]com%' OR LOWER(domain) LIKE '%visualstudiofactory[.]com%' OR LOWER(domain) LIKE '%zacharryblogs[.]com%' OR (LOWER(domain) LIKE '%raw.githubusercontent[.]com%' AND LOWER(clean_urls) LIKE '%/iconstorages/images/main/%'))


2. Determining whether hosts have interacted with malicious files SELECT f.filename, f.directory, ROUND((f.size * 10e-7),2) AS size_MB, h.sha256, f.type, f.attributes, f.mode, datetime(f.btime,'unixepoch') AS file_created_time, datetime(f.atime,'unixepoch') AS file_last_access_time, datetime(f.mtime,'unixepoch') AS file_last_modified_time, datetime(f.ctime,'unixepoch') AS file_last_status_change_time, f.uid, u.username AS file_owner FROM file f LEFT JOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid LEFT JOIN hash h ON f.path = h.path


AND (f.filename = 'ffmpeg.dll' OR f.filename LIKE 'd3dcompiler%.dll' OR f.filename = 'trololo.dll')


AND (h.sha256 = 'c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02' OR h.sha256 = '11be1803e2e307b647a8a7e02d128335c448ff741bf06bf52b332e0bbf423b03' OR h.sha256 = '7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896' OR h.sha256 = 'aa4e398b3bd8645016d8090ffc77d15f926a8e69258642191deb4e68688ff973')


Determining whether hosts are running affected versions SELECT MIN(ingestion_timestamp) AS first_seen, MAX(ingestion_timestamp) AS last_seen, meta_hostname, ARRAY_JOIN(ARRAY_AGG(DISTINCT(meta_hostname)), ', ')


AS hosts, ARRAY_JOIN(ARRAY_AGG(sophos_pid),', ')


AS spids, LOWER(name) AS name, sha256, company_name, file_description, file_size, file_version, original_filename FROM xdr_data WHERE query_name = 'running_processes_windows_sophos' AND ( LOWER(name) = '3cxdesktopapp.exe' OR LOWER(original_filename) = '3cxdesktopapp.exe' OR LOWER(product_name)


='3cx desktop app')


GROUP by meta_hostname, LOWER(name), sha256, company_name, file_description, file_size, file_version, original_filename ORDER BY meta_hostname desc 4.


Determining whether hosts have communicated with threat actor infrastructure, for MacOS SELECT meta_hostname, date_format(from_unixtime(time), '%Y-%m-%d


AS date_time, ingestion_timestamp pid, name, cmdline, path, parent, gid, uid, euid, egid, sha1, sha256 FROM xdr_data WHERE query_name = 'running_processes_osx_events' AND LOWER(cmdline) LIKE '%sh -c%' AND LOWER(cmdline) LIKE '%/3cx desktop app/updateagent%' 5.


Enabling firewall customers to identify activity to malicious domains SELECT timestamp, log_component, log_subtype, user_name, user_group, app_name, src_ip, src_port, protocol, dst_ip, dst_port, http_category, url, domain, http_user_agent, http_status FROM xgfw_data WHERE LOWER(log_component) = 'http' AND (LOWER(domain) = 'akamaicontainer.com' OR LOWER(domain) = 'akamaitechcloudservices.com' OR LOWER(domain) = 'azuredeploystore.com' OR LOWER(domain) = 'azureonlinecloud.com' OR LOWER(domain) = 'azureonlinestorage.com' OR LOWER(domain) = 'dunamistrd.com' OR LOWER(domain) = 'glcloudservice.com' OR LOWER(domain) = 'journalide.org' OR LOWER(domain) = 'msedgepackageinfo.com' OR LOWER(domain) = 'msstorageazure.com' OR LOWER(domain) = 'msstorageboxes.com' OR LOWER(domain) = 'officeaddons.com' OR LOWER(domain) = 'officestoragebox.com' OR LOWER(domain) = 'pbxcloudeservices.com' OR LOWER(domain) = 'pbxphonenetwork.com' OR LOWER(domain) = 'pbxsources.com' OR LOWER(domain) = 'qwepoi123098.com' OR LOWER(domain) = 'sbmsa.wiki' OR LOWER(domain) = 'sourceslabs.com' OR LOWER(domain) = 'visualstudiofactory.com' OR LOWER(domain) = 'zacharryblogs.com' OR (LOWER(domain) LIKE '%raw.githubusercontent.com%' AND LOWER(url) LIKE '%/iconstorages/images/main/%'))


3cxdesktopapp/18.12.407%' OR LOWER(http_user_agent) LIKE '%3cxdesktopapp/18.11.1213%' OR LOWER(http_user_agent) LIKE '


As of March 30, the company was recommending that customers uninstall and reinstall the app, and suggested that they might also use the company’s browser-based PWA client while the situation was sorted out.


On March 31, 3CX noted that Google has invalidated the company’s previous signing certificate, which means both the originally infected MSI files plus files issued by 3CX earlier in the week using that certificate will be blocked, and issued a fresh one.


3CX at this writing is building entirely new MSI installers using the newly issued certificate.


This applies to Windows only, as the company states they will not be rebuilding the Mac version of the desktop app yet while they focus on the Windows version (and on the security breach in general).


An updated list of IOCs for this attack is published on our GitHub.


Detection protection SophosLabs has blocked the malicious domains and published the following detections: Static detections: Troj/Loader-AF (Trojanized ffmpeg.dll) Troj/Mdrop-JTQ (installers) Troj/Steal-DLG OSX/Mdrop-JTR (installers) OSX/Loader-AG (Trojanized ffmpeg.dll) Reputation detection: Mal/Generic-R / Mal/Generic-S (d3dcompiler with appended shellcode) Memory detection: We have also blocked the list of known C2 domains associated with the threat and will continue to add to that list in the IOC file on our GitHub, as noted above.


Finally, the two malicious versions of the ffmpeg.dll bundled in the affected 3CXapplication are flagged by their hashes as being of low reputation.


SophosLabs is actively investigating additional detection opportunities for activity stemming from this software.


In addition, for customers of Sophos MDR, the MDR Detection Engineering team has a variety of behavioral detections in place that will detect follow up activity.


This post is also available in: 日本語 (Japanese)Executive Summary Unit 42 researchers recently discovered a new sample of Golang-based malware.

GoBruteforcer GolangBased Botnet Actively Harvests Web Servers


We have dubbed it GoBruteforcer, and it targets web servers, specifically those running phpMyAdmin, MySQL, FTP and Postgres services.


The sample was originally captured from our Next-Generation Firewall.


Upon further research, we found that the malware was hosted on a legitimate website.


Further investigation revealed that the attacker hosted binaries for x86, x64 and ARM processor architectures.


For successful execution, the samples require special conditions on the victim system like specific arguments being used and targeted services already being installed (with weak passwords).


Palo Alto Networks customers receive protections from malware families like GoBruteforcer and its malicious components with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.


Alongside this, Advanced URL Filtering and DNS Security can block the command and control (C2) domain and malware hosting URLs.


Table of Contents IntroductionScanning and System AccessFor the phpMyAdmin ServiceIRC Bot DeploymentFor MySQL and Postgres ServicesFor the FTP ServicePostResult Module and Web Shell ConnectionGoBruteforcer Makes AdvancesConclusionIndicators of Compromise Introduction Go programming language, also known as Golang, is a newer language that’s becoming more popular with malware programmers.


It has proven to be versatile enough to develop all kinds of malware, including ransomware, stealers or remote access trojans (RATs).


GoBruteforcer is a new kind of botnet malware that is written in Golang and targets web servers, specifically those running phpMyAdmin, MySQL, FTP and Postgres services.


GoBruteforcer chose a Classless Inter-Domain Routing (CIDR) block for scanning the network during the attack, and it targeted all IP addresses within that CIDR range.


The threat actor chose CIDR block scanning as a way to get access to a wide range of target hosts on different IPs within a network instead of using a single IP address as a target.


After achieving access, GoBruteforcer deploys an IRC bot containing the attacker’s URL.


Later, GoBruteforcer also tries to query the victim system using a PHP web shell.


GoBruteforcer attack chain.


The cache_init file highlighted in Figure 2 is the GoBruteforcer malware we found hosted in the /.x/ directory of the targeted server.


GoBruteforcer hosted on a victim server.


It seems likely that this is their OS of choice because *nix operating systems are a popular choice for hosting servers.


We’ve seen this malware remotely deploy a variety of different types of malware as payloads, including coinminers.


We believe that GoBruteforcer is in active development, and as such, things like initial infection vectors or payloads could change in the near future.


Scanning and System Access The GoBruteforcer malware samples are packed with UPX Packer.


Upon unpacking a sample (SHA256 ebe11121aafdac5d8f2eecba710ba85efa31617a5eb825ba2e89e23379b26b84), we observed that GoBruteforcer has a multiscan module (shown in Figure 3) it uses to scan for the hosts inside a CIDR for its attack.


GoBruteforcer multiscan function.


On the target IP address, the malware starts scanning for phpMyAdmin, MySQL, FTP and Postgres services.


The attacker has defined separate scanning modules against all the aforementioned services, as shown in Figure 4. Figure 4.


For this, the port scan module (shown in Figure 5) is called inside every scanning module.


Portscan function (present inside every scanning module).For the phpMyAdmin Service When scanning for phpMyAdmin services, if the target port (port 80) is open, the GoBruteforcer malware tries to login and get access to the victim server via brute force.


Hard-coded credentials for brute forcing.


IRC Bot Deployment Upon successful login via phpMyAdmin service into the victim server, GoBruteforcer deploys and executes an IRC bot on the victim server.


The files fb5 and ab5 are IRC bots compiled for x86_64 and ARM architectures respectively, as shown in Figures 7 and 8.


GoBruteforcer deploying IRC bot for ARM-supported platforms.


Later, the malware starts communication between the command and control channel (C2) and the victim server via the IRC bot, as shown in Figure 9. Figure 9.


Additionally, the IRC bot also registers itself inside cron for recurring execution. Figure 10.


IRC registering itself in cron.


(Figures 11 and 12 show this activity, and you can also refer to the following post on the Golang Issues forum for more information).


After that, the malware calls the PostResult module, which will be discussed in greater detail in the later section, PostResult Module and Web Shell Connection.


MySql ping done by GoBruteforcer malware.


If the malware finds it open, it tries to authenticate to the server (as shown in Figure 13) using the goftp library, which is an FTP client package for Golang.


FTP login attempt.


Upon successful authentication to the victim server, the malware calls the PostResult module.


PostResult Module and Web Shell Connection Inside GoBruteforcer's PostResult module, which is called after every service scanning module, we observed a hard coded link (query) as shown in Figure 14. Figure 14.


Hard coded link found inside GoBruteforcer binary.


This web shell seemed similar to the pst.php PHP file (SHA256 602129f00bb002f07db07affa78d46f67bd0b2c8fb0867ea2da5fc3e73dd2665) associated with http[:]//5.253.[.]84[.]159 (see Figure 15).


The PHP web shell had reverse shell and bind shell capabilities, as shown in Figure 15. Figure 15.


Bind shell and reverse shell capabilities inside webshell.


This gives the attacker the ability to gain more insight into the targeted network. Figure 16.


Simple packet crafter capabilities inside web shell.


GoBruteforcer Makes Advances During our hunt for the samples related to GoBruteforcer campaign, we found another sample (SHA256 acc705210814ff5156957c028a8d6544deaca0555156504087fdc61f015d6834).


The sample was uploaded on VirusTotal some months ago and had 0 detections, as shown in Figure 17. Figure 17.


Weak passwords could lead to serious threats as web servers are an indispensable part of an organization.


The GoBruteforcer bot comes with a multiscan capability, which gives it a wide range of targets that it can use to get into a network.


GoBruteforcer also seems to be in active development, so attackers could change the techniques they use to target web servers in the near future.


Alongside this, Advanced URL Filtering and DNS Security can block the command and control (C2) domain and malware hosting URLs. Indicators of Compromise Hashes de7994277a81cf48f575f7245ec782c82452bb928a55c7fae11c2702cc308b8b Web shell 602129f00bb002f07db07affa78d46f67bd0b2c8fb0867ea2da5fc3e73dd2665 Web shell acc705210814ff5156957c028a8d6544deaca0555156504087fdc61f015d6834 Older version of GoBruteforcer 426b573363277554c7c8a04da524ddbf57c5ff570ea23017bdc25d0c7fd80218 IRC bot(x86) 726ccd223a1cfb60fc6c3b48ea3dbf057da918efac5acf620cd026ee38fb0044 IRC bot(ARM) 526767fbb26c911601371745d603885b75deabcc18261ed2d5a509d58f95d28e GoBruteforcer (x86_64) dd3555025957cd51cd048d920027a0ff2d5501bc85792529217d54086e9351c2 GoBruteforcer (x86_64) df7dc0fe7e90a2414ac188c55d06ad3882cfc7394869c9ffa549fb1ddb304919 GoBruteforcer (x86_64) ebe11121aafdac5d8f2eecba710ba85efa31617a5eb825ba2e89e23379b26b84 GoBruteforcer (x86_64) 5548935e7c6cf3b38240a0579cac36906e9883a1ec5e85335609e9e2062588c5 GoBruteforcer ARM(64-bit) 5627b138bc857081d2251edd7eb3b68cbd58dfff2f51b7cd34c893fffff2cfab GoBruteforcer ARM(64-bit) 5c1d3fb43e9e35b835e62e05a7b97ed66ab132eab35bfc18ce543e8f58ccf5e2 GoBruteforcer ARM(32-bit) 7c27ac0daba19de227fcc467abfcdefa99426c768a3601b1b181e9741717665b GoBruteforcer (x86) URL and IP 5.253[.]84[.]159/x fi[.]warmachine[.]su Get updates from Palo Alto Networks! Sign up to receive the latest news, cyber threat intelligence and research from us


The LockBit ransomware (kinda) comes for macOS Analyzing a arm64 mach-O version of LockBit by: Patrick Wardle / April 16, 2023 Objective-See's research, tools, and writing, are supported by the "Friends of Objective-See" such as: :memo: :alien_monster: Want to play along?

The LockBit ransomware kinda comes for macOS


As “Sharing is Caring” I’ve uploaded the malicious binary LockBit to our public macOS malware collection.


The password is: infect3d ...please though, don't infect yourself!


Background Late Saturday (April 15the), @MalwareHunterTeam tweeted about a new LockBit ransomware variant targeting macOS: As shown in the tweet, the ransomware binary initially was undetected by any of the anti-virus engines on VirusTotal: locker_Apple_M1_64 on VirusTotal (image credit: @MalwareHunterTeam)


Good news, if you refresh the page on VirusTotal the av engines are now starting to pick up the file as malicious.


We believe this is the first time a large ransomware threat group has developed a payload for Apple products.”


-VXUnderground


Coupled with the fact that this may be, (as noted by @VXUnderground), “the first time a large ransomware threat group has developed a payload for Apple products” …I was intrigued to decided to dig right in!


In this blog post we’ll tear apart the sample, showing that ultimately, while yes it can indeed run on Apple Silicon, that is basically the extent of it’s impact.


Thus macOS users have nothing to worry about …for now!


Triage The (SHA-1) hash for the binary (aptly named locker_Apple_M1_64) is 9e9a5f8d86356796162cee881c843cde9eaedfb3 While we're only focusing on the macOS sample, it appears the LockBit group has built this sample for a host of other OS's: Using macOS’s file utility, we see the locker_Apple_M1_64 binary is an x86_64 (Intel) Mach-O: % file LockBit/locker_Apple_M1_64 LockBit/locker_Apple_M1_64: Mach-O 64-bit executable arm64 And what about it’s code signing information?


% codesign -dvv


LockBit/locker_Apple_M1_64 Executable=LockBit/locker_Apple_M1_64 Identifier=locker Format=Mach-O thin (arm64) CodeDirectory v=20400 size=3295


flags=0x20002(adhoc,linker-signed) hashes=100+0 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements=none % spctl -a -vvv


-t install LockBit/locker_Apple_M1_64 LockBit/locker_Apple_M1_64: invalid signature (code or signature have been modified)


The codesign utility shows that though it’s signed, it’s signed “ad-hoc” (say vs. an Apple Developer ID).


This means if downloaded to a macOS system (i.e. deployed by the attackers) macOS won’t let it run.


This is confirmed by the spctl utility which shows “invalid signature” …or if you’re brave enough to try run it: An invalid signature means macOS will block it Let’s now run the strings command (with the "-" option which instructs it to scan the whole file), we find a few strings that appear to be related to standard ransomware activity including: Encryption File Extensions Ransom instructions % strings - -n 3 locker_Apple_M1_64 curve25519xsalsa20poly1305 blake2b blake2b_final blake2b-ref.c sodium_crit_enter _sodium_malloc /dev/urandom /dev/random ...


cmd ani adv msi msp com nls ocx mpa cpl mod hta prf rtp rdp bin shs wpx bat rom msc spl ics key exe dll ... restore-my-files.txt ... winmd ntldr ntuser.dat.log bootsect.bak autorun.inf thumbs.db iconcache.db Also interesting are the strings related to Windows artifacts (e.g. autorun.inf, ntuser.dat.log, etc…).


This may indicate the ransomware was originally written to target Windows platforms.


This wraps up our triage of the locker_Apple_M1_64 binary.


Time to dive in deeper with our trusty friends: the disassembler and debugger!


Analysis of locker_Apple_M1_64 In this section we’ll more deeply analyze the malicious logic of the locker_Apple_M1_64 binary …which is simplified by the fact that the binary’s symbols aren’t stripped.


First, we pointed out that the locker_Apple_M1_64 is an arm64 binary (Mach-O 64-bit executable arm64).


This means we better have at least a cursory understanding of AArch64.


If you’re not familiar with this instruction set, here’s two of my favorite resources to get you up to speed: Opening the malware in a disassembler, (starting at its main) we spot some (fairly common) anti-debugging logic: main ... 000000010000b108 bl imp___stubs__getppid 000000010000b10c mov x1, x0 000000010000b110 mov w0, #0x1f 000000010000b114 mov x2, #0x0 000000010000b118 mov w3, #0x0 000000010000b11c bl imp___stubs__ptrace 000000010000b120 cmn w0, #0x1 In short, this snippet of code invokes ptrace with PT_DENY_ATTACH (0x1f) which will kill the process if a debugger is currently attached, and also prevent future attachments.


As we’ll want to debug the malware to gain a deeper understanding of its functionality, we’ll have to bypass this.


Just set a breakpoint on the address of the call to ptrace (b 0x000000010000b11c), and once this is hit, simply skip over the call by modifying the instruction pointer to point it to the next instruction (reg write $pc 0x000000010000b120).


% lldb locker_Apple_M1_64 (lldb) target create "locker_Apple_M1_64" Current executable set to 'locker_Apple_M1_64' (arm64).


+72>: bl 0x1000429cc ; symbol stub for: ptrace (lldb) reg write $pc 0x10000b120


(The rest of the malware’s binary simple looks like Linux code, compiled for macOS).


Next, we find an XOR loop that decrypts this configuration.


000000010000b144 mov x8, #0x0 000000010000b148 mov w9, #0x2458 loc_10000b14c: 000000010000b14c and x10, x8, #0xf 000000010000b150 ldrb w10, [x21, x10] 000000010000b154 add x11, x21, x8 000000010000b158 ldrb w12, [x11, #0x10] 000000010000b15c eor w10, w12, w10 000000010000b160 strb w10, [x11, #0x10] 000000010000b164 add x8, x8, #0x1 000000010000b168 cmp x8, x9 000000010000b16c b.ne loc_10000b14c Once de-XOR’d we find a few strings as "!!!


-Restore-My-Files-!!!


", "VMware vCenter Server", and XP_SP;Win10.


LockBit’s ransomware that targets Windows/Linux, and also VMware ESXi.


The malware then initializes various global variables, either with hard-coded values, or from the decrypted configuration (now held in g_Config).


_bdaemon: 0000000100059088 dd 0x00000001 ... 000000010000b174 adrp x9, #0x100059000 ... 000000010000b17c mov w8, #0x1 000000010000b180 nop 000000010000b184 str w8, [x9, #0x88] ; _bdaemon Here’s the list of global variables that are referenced …which based on their names, provide insight into the malware configuration options:


iMinfilesize iSpotMaximum bdaemon bSelfRemove publickey idelayinmin wholefile bfullog bnostop noext no_log bwipe bVMDKmode …also, by manually manipulating these values in a debugger (or as we’ll see via the command line) we can simplify analysis.


For example, setting bdaemon to false will prevent the binary from daemonizing (making it easier to debug), while setting bfullog to true to coerce the malware to log its actions!


We could step through this and dump each string manually, or, as a hard-coded XOR key is used, simply de-XOR the entire binary and see what falls out: with open("locker_Apple_M1_64", "rb") as f_in, open("strings", "wb") as f_out: while True: chunk = f_in.read(1024) if not chunk: break encrypted_chunk = bytes(byte ^


This produces strings including a commandline usage: Usage: %s


[OPTION]... -i


'/path/to/crypt' Recursively crypts files in a path or by extention.


Mandatory arguments to long options are mandatory for short options too.


-i, --indir path to crypt -m, --minfile minimal size of a crypted file, no less than 4096 -r, --remove self remove this file after work -l, --log prints the log to the console -n, --nolog do not print the log to the file /tmp/locker.log -d, --daemonize runs a program as Unix daemon -w, --wholefile encrypts whole file -b, --beginfile encrypts first N bytes -e, --extentions encrypts files by extentions -o, --nostop prevent to stop working VM -t, --wipe wipe free space -s, --spot upper bound limitation value of spot in Mb -p, --pass password -f, --full full log -a, --delay start delay in minutes -y, --noexts do not search for extentions -v, --vmdk search for extentions inside VMDK files Clearly these match to the global variables that apparently can be set via the command-line as well.


As we’ll set this makes analysis even easier!


Also the de-XOR’d strings, we find the full ransom note (here, truncated):


~~~ LockBit 3.0 the world's fastest and most stable ransomware from 2019~~~ >>>>>


If you don't pay the ransom, the data will be published on our TOR darknet sites.


Keep in mind that once your data appears on our leak site, it could be bought by your competitors at any second, so don't hesitate for a long time.


Tor Browser Links: http://lockbitapt2d73krlbewgv27tquljgxr33xbwwsp6rkyieto7u4ncead.onion http://lockbitapt2yfbt7lchxejug47kmqvqqxvvjpqkmevv4l3azl3gy6pyd.onion http://lockbitapt34kvrip6xojylohhxrwsvpzdffgs5z4pbbsywnzsbdguqd.onion http://lockbitapt5x4zkjbcqmz6frdhecqqgadevyiwqxukksspnlidyvd7qd.onion http://lockbitapt6vx57t3eeqjofwgcglmutr3a35nygvokja5uuccip4ykyd.onion http://lockbitapt72iw55njgnqpymggskg5yp75ry7rirtdg4m7i42artsbqd.onion http://lockbitaptawjl6udhpd323uehekiyatj6ftcxmkwe5sezs4fqgpjpid.onion http://lockbitaptbdiajqtplcrigzgdjprwugkkut63nbvy2d5r4w2agyekqd.onion http://lockbitaptc2iq4atewz2ise62q63wfktyrl4qtwuk5qax262kgtzjqd.onion Links for normal browser: http://lockbitapt2d73krlbewgv27tquljgxr33xbwwsp6rkyieto7u4ncead.onion.ly http://lockbitapt2yfbt7lchxejug47kmqvqqxvvjpqkmevv4l3azl3gy6pyd.onion.ly http://lockbitapt34kvrip6xojylohhxrwsvpzdffgs5z4pbbsywnzsbdguqd.onion.ly http://lockbitapt5x4zkjbcqmz6frdhecqqgadevyiwqxukksspnlidyvd7qd.onion.ly http://lockbitapt6vx57t3eeqjofwgcglmutr3a35nygvokja5uuccip4ykyd.onion.ly http://lockbitapt72iw55njgnqpymggskg5yp75ry7rirtdg4m7i42artsbqd.onion.ly http://lockbitaptawjl6udhpd323uehekiyatj6ftcxmkwe5sezs4fqgpjpid.onion.ly http://lockbitaptbdiajqtplcrigzgdjprwugkkut63nbvy2d5r4w2agyekqd.onion.ly http://lockbitaptc2iq4atewz2ise62q63wfktyrl4qtwuk5qax262kgtzjqd.onion.ly ... >>>>


Very important!


For those who have cyber insurance against ransomware attacks.


Insurance companies require you to keep your insurance information secret, this is to never pay the maximum amount specified in the contract or to pay nothing at all, disrupting negotiations.


The insurance company will try to derail negotiations in any way they can so that they can later argue that you will be denied coverage because your insurance does not cover the ransom amount.


He will do anything to derail negotiations and refuse to pay us out completely and leave you alone with your problem.


If you do not pay the ransom, we will attack your company again in the future.


Interestingly also, the malware invokes a function named get_password to read from stdin …it checks against the value of test 000000010000a618 bl imp___stubs__strcmp (lldb)


x/s $x0 0x16fdfeb10: "hunter2" (lldb) x/s $x1 0x10005a0d2: "test At this point, armed with an decent understanding of the malware (yah, its ransomware) plus understanding of commandline options (that also allow us to enable logging), coupled with the fact that it’s a Sunday (aka the day of rest, not reversing malware) I decided to switch to passive dynamic analysis.


Also, maybe you’re tired of reading arm64?


My goal was now trigger the malware to encrypt (ransom) files, while passively observing it in action.


On my dedicated analysis machine, I first created a directory for it to encrypt (~/Downloads/lock_me_up) which I filled with files to encrypt (for some reason, I thought it was be funny to put other malware samples in there for the ransomware to encrypt).


Next, I ran the malware with the following command line: -f : full log -p pass : password -i ~/Downloads/lock_me_up : directory to encrypt / ransom First, the file monitoring detected the ransomware opening its log file (tmp/locklog).


# FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_OPEN", "file" : { "destination" : "/private/tmp/locklog", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Then, accessing (opening) the files in the specified directory, to encrypt them, and renaming the encrypted files with the .lockbit extension: # FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_OPEN", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/DazzleSpy.zip", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } }, { "event" : "ES_EVENT_TYPE_NOTIFY_RENAME", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/DazzleSpy.zip.lockbit", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Finally, it creates a file named "!!!


which is ransom note with the decryption instructions: # FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_CREATE", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/!!!-Restore-My-Files-!!!


", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Ransomed files and ransom note Let’s take a peek at the log (/tmp/locker.log), which gives us details in the ransomware’s actions: [19:16:45][74073472l][+] Launch parameters: ./locker_Apple_M1_64


-i '/Users/user/Downloads/lock_me_up' -m 16 -w 0 -b 0 -r 0 -l 1 -n 0 -d 1 -e '' -s 10 -p test -o 0


-z


-y 0 ~~~~~~~~~~~~~~~Hardware~~~~~~~~~~~~~~~~~~ [19:32:07][4329948544][+] Add directory to encrypt: /Users/user/Downloads/lock_me_up


[19:32:07][6140964864][+] Start encrypting file /Users/user/Downloads/lock_me_up/DazzleSpy.zip


[19:32:07][6140964864][+] Start encrypting file /Users/user/Downloads/lock_me_up/DazzleSpy.zip spot 0 from 1.


Original checksum 2846984875 ...


[19:32:07][6140964864][+] End file /Users/user/Downloads/lock_me_up/DazzleSpy.zip size 223464 time 1672883981 is encrypted.


Checksum after encryption 3269819564 ...


At this point, we have a fairly comprehensive analysis of the malware, and have confirmed it is (as wholly expected) ransomware.


And, being able to trigger its ransomware logic is helpful to testing detection tools (discussed next).


Detection Of course its goes without saying, having your files ransomed sucks!


And good news, in this case the average macOS is unlikely to be impacted by this LockBit macOS sample.


So, kudos to Cupertino.


Apple has also added (TCC) protections to user files founds in (now) protected directories such as ~/Desktop, ~/Documents, etc. etc.


Still an additional layer or detection/protection may be warranted, especially we’ve all probably clicked “Allow” on access prompts, while even Apple has been known to notarize malware.


If we stop to think specifically about ransomware, in theory, (at least in most cases) it should be trivial to detect.


Why?


Simply put, ransomware’s actions provide us with a powerful detection heuristic.


In April 2016 (yes, wayyyy back then!)


I posted a blog titled, “Towards Generic Ransomware Detection”.


In this post, I mused, “If we can monitor file I/O events and detect the rapid creation of encrypted files by untrusted processes, then ransomware may be generically detected” To back this up, I released a free (and now open-source) tool called “RansomWhere?” that implemented this heuristic-based approach.


Specifically it process file


I/O events and for newly created files asks: Is the process creating file untrusted (e.g. not an Apple platform binary)?


Is created file encrypted?


Is the (untrusted) process rapidly creating several encrypted files?


If these are all true, “RansomWhere?” will suspend process as its likely ransomware and alert the user and handle the response (resume/terminate).


As with any detection approach and security tool, there are limitations.


...doing it's thing!


Conclusion Today we dove into a macOS ransomware sample created by the infamous LockBit ransomware gang.


…still, as we stated earlier, the fact that a large ransomware gang (LockBit) has apparently set its sights on macOS, should give us all pause for concern.


The use of IronPython for malicious purposes isn’t new, but the way Turla uses it is new.

IronNetInjector Turlas New Malware Loading Tool


It describes the use of an interpreter, not present on a system by default, to run malicious code of an interpreted programming or scripting language.


The first malicious IronPython scripts of the tool we describe here were discovered last year by a security researcher from FireEye.


At the beginning of this year, another security researcher from Dragos pointed out some new scripts of the same threat actor uploaded to VirusTotal from two different submitters.


We found that one of the submitters also uploaded two other samples, which are most likely embedded payloads of one of the IronPython scripts.


These samples helped us to understand how this tool works, what malware it loads and which threat actor uses it.


We dubbed this toolchain IronNetInjector, the blend of IronPython and the injector’s internal project name NetInjector.


In this blog, we describe the IronPython scripts and how they’re used to load one or more payloads with the help of an injector.


In the words of the IronPython team: IronPython is an open-source implementation of the Python programming language which is tightly integrated with the .NET Framework.


IronPython can use the .NET Framework and Python libraries, and other


And further: IronPython’s sweet-spot is being able to use the .NET framework APIs directly from Python.


With IronPython, you can use .NET framework APIs directly in your Python script.


As one of two official projects formerly developed by Microsoft, the other being IronRuby, it uses the Dynamic Language Runtime (DLR).


Now, it becomes clear why IronPython is also attractive for malware authors.


Of course, this requires the IronPython interpreter to also be present on the system, but that can be accomplished in different ways.


In case of a sandbox that supports Python scripts, the interpreter would simply crash without any dynamic analysis result.


Further, as IronPython is written in C# and thus its process contains all the Common Language Runtime (CLR) on execution, one can easily load additional assemblies.


The payloads can be also .NET assemblies (x86/64) or native PEs (x86/64).


When an IronPython script is run, the .NET injector gets loaded, which in turn injects the payload(s) into its own or a remote process.


Strings are encrypted.


Contain an encrypted .NET injector and one or more encrypted PE payloads.


Take one argument that is the decryption key for the embedded .NET injector and PE payload(s).


Embedded .NET injector and payload(s) are encoded with Base64 and encrypted with Rijndael.


Log messages are written to %PUBLIC%\Metadata.dat Error messages are written to %PUBLIC%\Metaclass.dat


The following screenshot shows one of the IronPython scripts decoded: Figure 1.


Both versions are full-blown PE injection tools able to load a native x86/64 payload reflectively into a remote process.


This is accomplished via unmanaged functions and the use of PeNet, a publicly available PE parser library written in C#.


Additionally, log and error messages are being used extensively.


The 2018 variant is used within PowerShell scripts to load a payload from the same script into a process.


Most of its code is taken from PowerShell Empire’s ReflectivePEInjection script and got translated into C#.


It’s written in a much more specific manner than the 2019 variant, which is a generically written injection tool.


The newer version additionally contains the ability to inject .NET assemblies into unmanaged processes.


The newer injector has the following PDB path left: C:\Users\Devel\source\repos\c4\agent\build_tools\agent_dll_to_Python_loader\NetInjector\NetInjector\obj\Release\NetInjector.pdb The same submitters who uploaded the IronPython scripts also submitted other files which are directly related to IronNetInjector.


The following table shows the IronPython scripts categorized by the different VirusTotal submitters.


It also shows which other samples uploaded by the same submitter or the other submitters are connected and gives the assumed embedded malware: Submitter IronPython script(s) uploads Related samples uploaded by same submitter Payload assumptions 1 • prophile.py • profilec.py • IronPython-2.7.7z: Portable IronPython version that contains the two IronPython scripts and a Windows task XML to start profilec.py • prophile.py: .NET injector (variant 2018)


+ RPC backdoor variant • profilec.py: .NET injector (variant 2019)


ComRAT variant 2 • profile.py – • profile.py: .NET injector (variant 2019)


ComRAT variant 3 • 10profilec.py • 120profilec.py • 220profile.py – • 10profilec.py: .NET injector (variant 2018)


Unknown 4 • profilec.py • NetInjector.dll: .NET injector (variant 2019), most likely embedded .NET


Categorized IronPython samples according to VirusTotal submitters and their assumed payloads.


In one case, a variant of the RPC backdoor is used and in another a payload that we couldn’t associate with known malware.


We also couldn’t verify how the IronPython scripts get run in the first place.


One of the submitters uploaded a 7-Zip archive with the contents of the IronPython MSI file of version 2.7.0.40 from 2011.


This archive also contains two IronPython scripts (see table) and a Windows task XML file named mssch.xml with the following content: Figure 2.


Windows task XML file for IronNetInjector.


The task is used to start an IronPython script with the 64-bit version of the interpreter.


However, the key didn’t decrypt on any of the embedded files in the scripts we found.


IronNetInjector task triggers.


Depending on the system, the event with ID 8001 belongs to Microsoft Internet Information Services (IIS), Microsoft Exchange Server or Windows Server (Source: Netsurion EventTracker).


The other event with ID 5324 is likely related to the logoff from Winlogon.


Both triggers only happen when these events appear in the Microsoft-Windows-GroupPolicy(/Operational) event logs.


When we consider that the files in the 7-Zip archive were all taken from the same directory, we can make some assumptions.


The attacker might have used the IronPython MSI to install the interpreter to C:\ProgramData\IronPython-2.7 on the victim’s system.


The IronPython scripts and the Windows task XML were placed in the same directory.


However, it’s also possible that the submitter collected the files from different places and just bundled them into an archive for scanning purposes.


A Brief Walkthrough Let’s go briefly through the execution flow based on one of the scripts of VirusTotal submitter 4 that contains the 2019 variant of the injector and a ComRAT variant (SHA256: 3aa37559ef282ee3ee67c4a61ce4786e38d5bbe19bdcbeae0ef504d79be752b6).


When an IronPython script is run, it is loaded into the IronPython interpreter.


In the IronPython script, the embedded .NET injector (SHA256: a56f69726a237455bac4c9ac7a20398ba1f50d2895e5b0a8ac7f1cdb288c32cc) and ComRAT DLL payload (SHA256: a62e1a866bc248398b6abe48fdb44f482f91d19ccd52d9447cda9bc074617d56) get decoded and decrypted.


This is done with the Python Base64 module and the RijndaelManaged class from the C# cryptography namespace.


The decryption key is passed as an argument to the IronPython script.


The Rijndael initialization vector (IV) is stored in the script.


Next, the .NET injector gets loaded into the IronPython process with the help of the Assembly.


That’s possible because IronPython itself is a .NET assembly and thus its process already contains all the .NET runtime libraries.


After the injector assembly is loaded, the ID of the process where the ComRAT DLL gets injected is retrieved.


In this case, the explorer.exe was chosen.


This routine to get the PID slightly differs in the IronPython scripts we found.


While one script uses the C# method GetProcessesByName() to get the PID, the other scripts run the Windows tool tasklist.exe with the help of the Python os.popen() function.


Also, some scripts filter the PID based on a Windows service name.


When the PID is found, an instance of the injector assembly is created and the ComRAT payload bytes and PID are passed.


PID retrieval function variations in the different IronPython scripts.


In the latter, the exported function name VFEP of the ComRAT payload gets passed.


The .NET injector contains the following namespaces: DefaultSerializer PeNet PeNet.


Parser PeNet.


Structures PeNet.


Structures.


MetaDataTables.


Parsers PeNet.


Utilities While the PeNet code is copied from the project, the namespace DefaultSerializer contains the injector code and is made of the following classes: DefaultSerializer: Contains the injector code.


NetBootstrapper:


Contains 32-/64-bit bootstrappers to load an assembly into an unmanaged process.


Contains the imported unmanaged function declarations and win32 structures/constants.


The method InjectAssembly is used to inject a .NET assembly into a native process (or its own) and InvokeAssemblyMethod to call any chosen method of the injected assembly.


The method Invoke is used to inject a native PE into a remote process and InvokeVoid to call any exported function of the injected payload.


Decompiled NetInjector code.


Depending on the number of arguments passed to DefaultSerializer on creation time, the payload is either loaded into its own process or a remote one.


In case only the payload bytes are passed, it gets loaded into its own process space.


The other options are to also pass the ID or handle of the remote process the payload gets injected to.


In our case, the second option is used with the PID of explorer.exe to load the ComRAT payload reflectively into the process.


This needs some preparation in the remote process, as you cannot simply load and execute a .NET assembly there if the CLR isn’t present.


This is accomplished with a native bootstrapper DLL, which gets injected into the remote process and prepares it so a .NET assembly can be injected afterwards.


There are two bootstrappers (x86/64) contained in the NetBootstrapper class, which have the following PDB paths left: F:\Dev\NetInjector\bin\Release\NetBootstrapper_Win32.pdb F:\Dev\NetInjector\bin\Release\NetBootstrapper_x64.pdb Just like the injector itself, the bootstrappers contain meaningful function names (exported functions) and useful log messages.


It uses the following exported functions:


Bootstrap: Load CLR services into process.


Get method result from InvokeMethod.


InvokeMethod: Call method of injected assembly passed as a parameter.


Same as Bootstrap.


These functions are called from the injector to prepare and load a .NET assembly payload from the IronPython script into a remote process.


It’s similar in structure to the previously used in-memory loading mechanism to execute malware with the help of PowerShell scripts.


These scripts contain an embedded PE loader to execute an embedded malware payload.


The tool we discussed in this blogpost was likely developed to move away from PowerShell towards .NET.


The .NET injectors and bootstrappers contain clean code and meaningful function/method/variable names, and they use detailed log/error messages.


Only the initial IronPython scripts are obfuscated to prevent easy detection.


How do the IronPython scripts get run?


And how is the interpreter deployed to a victim’s system?


We will continue to monitor for this malware loading tool to get the missing pieces of the puzzle.


Our extended detection and response platform Cortex XDR can identify and block the malware execution.


AutoFocus customers can track the activity with the tag “IronNetInjector”.


Indicators of Compromise IronPython scripts b641687696b66e6e820618acc4765162298ba3e9106df4ef44b2218086ce8040 (prophile.py, submitter 1) c430ebab4bf827303bc4ad95d40eecc7988bdc17cc139c8f88466bc536755d4e (profilec.py, submitter 1) c1b8ecce81cf4ff45d9032dc554efdc7a1ab776a2d24fdb34d1ffce15ef61aad (profile.py, submitter 2) 8df0c705da0eab20ba977b608f5a19536e53e89b14e4a7863b7fd534bd75fd72 (10profilec.py, submitter 3) b5b4d06e1668d11114b99dbd267cde784d33a3f546993d09ede8b9394d90ebb3 (120profilec.py, submitter 3) b095fd3bd3ed8be178dafe47fc00c5821ea31d3f67d658910610a06a1252f47d (220profile.py, submitter 3) 3aa37559ef282ee3ee67c4a61ce4786e38d5bbe19bdcbeae0ef504d79be752b6 (profilec.py, submitter 4) Injector samples a56f69726a237455bac4c9ac7a20398ba1f50d2895e5b0a8ac7f1cdb288c32cc (2019 variant, submitter 4) c59fadeb8f58bbdbd73d9a2ac0d889d1a0a06295f1b914c0bd5617cfb1a08ce9 (2018 variant, submitter 5) Bootstrapper samples 63d7695dabefb97aa30cbe522647c95395b44321e1a3b08b8028e4000d1be15e ba17af72a9d90822eed447b8526fb68963f0cde78df07c16902dc5a0c44536c4 Related samples 82333533f7f7cb4123bceee76358b36d4110e03c2219b80dced5a4d63424cc93 (IronPython-2.7.7z, submitter 1) a62e1a866bc248398b6abe48fdb44f482f91d19ccd52d9447cda9bc074617d56 (ComRAT v4 variant, submitter 4) 18c173433daafcc3aea17fc4f7792d0ff235f4075a00feda88aa1c9f8f6e1746 (RPC backdoor variant, submitter 5) a64e79a81b5089084ff88e3f4130e9d5fa75e732a1d310a1ae8de767cbbab061 (RPC backdoor variant, submitter 5) Get updates from Palo Alto Networks! Sign up to receive the latest news, cyber threat intelligence and research from us


Mandiant has observed APT29 using a stealthy backdoor that we call POSHSPY.

Dissecting One of APT29s Fileless WMI and PowerShell Backdoors POSHSPY


POSHSPY leverages two of the tools the group frequently uses: PowerShell and Windows Management Instrumentation (WMI).


In the investigations Mandiant has conducted, it appeared that APT29 deployed POSHSPY as a secondary backdoor for use if they lost access to their primary backdoors.


Its use of a PowerShell payload means that only legitimate system processes are utilized and that the malicious code execution can only be identified through enhanced logging or in memory.


Every aspect of POSHSPY is efficient and covert.


We first discussed APT29’s use of this backdoor as part of our “No Easy Breach” talk.


WMI provides many administrative capabilities on local and remote systems, including querying system information, starting and stopping processes, and setting conditional triggers.


WMI can be accessed using a variety of tools, including the Windows WMI Command-line (wmic.exe), or through APIs accessible to programming and scripting languages such as PowerShell.


Windows system WMI data is stored in the WMI common information model (CIM) repository, which consists of several files in the System32\wbem\Repository directory.


WMI classes are the primary structure within WMI.


WMI classes can contain methods (code) and properties (data).


WMI permanent event subscriptions can be used to trigger actions when specified conditions are met.


Attackers often use this functionality to persist the execution of backdoors at system start up.


Subscriptions consist of three core WMI classes: a Filter, a Consumer, and a FilterToConsumerBinding.


WMI Consumers specify an action to be performed, including executing a command, running a script, adding an entry to a log, or sending an email.


WMI Filters define conditions that will trigger a Consumer, including system startup, the execution of a program, the passing of a specified time and many others.


A FilterToConsumerBinding associates Consumers to Filters.


Creating a WMI permanent event subscription requires administrative privileges on a system.


We have observed APT29 use WMI to persist a backdoor and also store the PowerShell backdoor code.


To store the code, APT29 created a new WMI class and added a text property to it in order to store a string value.


APT29 then created a WMI event subscription in order to execute the backdoor.


The subscription was configured to run a PowerShell command that read, decrypted, and executed the backdoor code directly from the new WMI property.


This “fileless” backdoor methodology made the identification of the backdoor much more difficult using standard host analysis techniques.


POSHSPY WMI Component The WMI component of the POSHSPY backdoor leverages a Filter to execute the PowerShell component of the backdoor on a regular basis.


Figure 1: “BfeOnServiceStartTypeChange” WMI Query Language (WQL) filter condition


The BfeOnServiceStartTypeChange Filter was bound to the CommandLineEventConsumer WindowsParentalControlsMigration.


The WindowsParentalControlsMigration consumer was configured to silently execute a base64-encoded PowerShell command.


Upon execution, this command extracted, decrypted, and executed the PowerShell backdoor payload stored in the HiveUploadTask text property of the RacTask class.


Figure 2: WindowsParentalControlsMigration


CommandLineTemplate Figure 3 contains the decoded PowerShell command from the “CommandLineTemplate.” Figure 3: Decoded CommandLineTemplate PowerShell code POSHSPY PowerShell Component The full code for a POSHSPY sample is available here.


The POSHSPY backdoor is designed to download and execute additional PowerShell code and Windows binaries.


Downloading and executing PowerShell code as an EncodedCommand 2.


Writing executables to a randomly-selected directory under Program Files, and naming the EXE to match the chosen directory name, or, if that fails, writing the executable to a system-generated temporary file name, using the EXE extension 3.


Modifying the Standard Information timestamps (created, modified, accessed) of every downloaded executable to match a randomly selected file from the System32 directory that was created prior to 2013 4.


Using a custom User Agent string or the system's User Agent string derived from urlmon.dll 7.


Using either custom cookie names and values or randomly-generated cookie names and values for each network connection 8.


Uploading data in 2048-byte chunks 9.


When combined with the other options in the DGA, 550 unique C2 URLs could be generated.


Infrequent beaconing, use of DGA and compromised infrastructure for C2, and appended file headers used to bypass content inspection made this backdoor difficult to identify using typical network monitoring techniques.


Conclusion POSHSPY is an excellent example of the skill and craftiness of APT29.


By “living off the land” they were able to make an extremely discrete backdoor that they can deploy alongside their more conventional and noisier backdoor families, in order to help ensure persistence even after remediation.


As stealthy as POSHSPY can be, it comes to light quickly if you know where to look.


Enabling and monitoring enhanced PowerShell logging can capture malicious code as it executes and legitimate WMI persistence is so rare that malicious persistence quickly stands out when enumerating it across an environment.


Additional Reading This PowerShell logging blog post contains more information on improving PowerShell visibility in your environment.


This excellent whitepaper by William Ballenthin, Matt Graeber and Claudiu Teodorescu contains additional information on WMI offense, defense and forensics.


This presentation by Christopher Glyer and Devon Kerr contains additional information on attacker use of WMI in past Mandiant investigations.


The FireEye FLARE team released a WMI repository-parsing tool that allows investigators to extract embedded data from the WMI repository and identify WMI persistence.


In this article, we describe how Hancitor compromises systems based on its infection chain observed in January and February 2021.

Hancitor Infection Chain Analysis An Examination of its Unpacking Routine and Execution Techniques


We cover its unpacking routine, information gathering and command and control (C2) functions, and payload execution techniques.


The malware Hancitor Hancitor (aka Chanitor) is a downloader which is used to gain initial access to a victim’s computer.


Its main purpose is to download and execute a second stage malware payload from one of multiple encrypted URLs contained in the malware itself.


Since then, almost every workday we have seen Hancitor activity.


The Word documents were droppers that install and execute the Hancitor downloader.


To find out how the OLE object is used and how the malware infection happens, we analyzed the VBA macros using Word’s developer tools. Figure 2 – Output from oledump showing the VBA macro in the Word document.


Open event.


The OLE object is then saved with a “.tmp” file extension into one of the local temp folders under “C:\Users\[username]\AppData\Local\Temp”.


As the VBA code does not know where the file was stored, it then recursively searches through all local temp folders.


Once the “.tmp” file is found, it is moved and renamed to the Office templates folder (C:\Users\username\AppData\Roaming\Microsoft\Templates) as “W0rd.dll” and loaded using rundll32.exe.


As a second argument, the macro passes the entry function “DllUnregisterServer” to rundll32.exe so that the execution starts correctly.


Packed DLL analysis Briefly looking at the DLL characteristics shows that there are two unknown sections, which could be an indicator of packing being used to obfuscate the malware.


Opening the DLL in a debugger and running through the program, focusing on what is happening with the suspicious sections confirms that there is indeed some sort of unpacking happening.


Although the unpacking procedure happens in multiple steps, it can be described in two broad stages: Decryption Stage 1 First, the malware allocates new memory which is used to copy the data from section “.rdata4” into it.


The data, however, is not copied identically from the section to the new memory region because the bytes containing 0x21 are omitted.


As soon as the copy operation is finished, the decryption process starts.


It uses an XOR operation with the key and plaintext being incremented after each four-byte operation.


To start, the key is initialized with 0xD508.


Figure 6 – Data view of the section containing the encrypted malware.


Looking at the decrypted data and the behavior of the program, we can see that there are multiple areas containing different types of information.


The names of Windows API functions are stored in the first 150 bytes.


The area after this contains encrypted data.


Finally, the executable code used to decrypt the encrypted data is located at the end of the section.


Figure 7 shows the structure of the memory section.


The API function located at the beginning of the memory section are resolved using GetProcAddress.


However, instead of being resolved within kernel32.dll, they are resolved in kernelbase.dll.


This is important to note because when debugging Hancitor samples, breakpoints are most commonly set on functions from kernel32.dll and thus would not be triggered during execution.


After resolving the functions, the second decryption stage occurs.


Decryption Stage 2 As indicated


, the decrypted memory structure contains executable code.


As expected, the instruction pointer jumps directly to this section, which also contains the decryption algorithm for the second stage.


Before the decryption starts, new memory is allocated and the encrypted data from stage 1 is copied to it.


The decryption algorithm of stage 2 is generally the same, but uses 0x3E9 as the initialization key.


The output of this decryption leads us to a PE file.


Figure 8 – Overview of Hancitor’s decryption procedure.


The copy procedure is done section by section to bring the executable into the loaded form.


This technique is called self-injection or PE overwrite.


These function addresses vary from installation to installation, so this patching cannot be done by a static unpacker.


For all the other decryption procedures described, you can find a static unpacker script in our GitHub repository.


To effectively run the new payload, a return to the correct DLL entry point is made.


When using x32dbg to analyze the sample, simply patching the AddressOfEntryPoint to one of the exported functions makes the DLL runnable.


The subsequent functions collect additional information such as the machine’s public IP address, domain trust information and the computer architecture.


All the collected information is then put together into a query string which is generated based on the computer architecture.


Figure 10 – Query string containing system information before being sent to the C2.


To determine the command and control (C2) servers waiting for the data to be sent to, the malware calls a decryption function that uses the RC4 algorithm to get a list of potential C2 URLs.


After successfully decrypting the C2 URLs, the data is sent there using a HTTP POST request adding the constructed query string as data.


To increase the probability of reaching an active server, the malware iterates over all the decrypted C2 URLs and tries to reach all of them until one of them sends a response.


Figure 12 – C2 communication function.


We assume that based on the received data the C2 server responds with either a simple string which can be decrypted to an active malware download server or with garbage data in the form of a simple string.


Although the decoding algorithm of the C2 response looks quite complex, it is actually Base64 decoding, followed by an XOR operation using the key 0x7A.


If the decryption leads to a valid URL, the malware initiates a download, which delivers an executable.


Create Thread The Create Thread method is as straightforward as Create Process.


The malware simply allocates some memory, writes the malware into it and creates a new thread from it.


Process Hollowing If the Process Hollowing method is used, a new svchost.exe process is created in a suspended state.


The malware then allocates new memory in the newly-created process, writes the executable to it and executes it in a new thread.


Figure 13 – Process creation function.


This method is mostly the same as the above described Process Injection method.


Conclusion This article should give a good overview of Hancitor’s capabilities and behavior as of February 2021. Indicators of Compromise (IOCs)


A list of IOCs is also available in the HP Threat Research GitHub repository.


Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website.

Smoking Out a DARKSIDE Affiliates Supply Chain Software Compromise


While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.


As reported in the Mandiant post, "Shining a Light on DARKSIDE Ransomware Operations," Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates.


UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.


The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background).


While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.


Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website.


Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.


Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers.


A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.


This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service.


Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate.


While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations.


Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month.


As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service.


Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.