Fantasy makes no effort to disguise itself as ransomware.


Agrius operators used a new tool, Sandals, to connect remotely to systems and execute Fantasy.

Fantasy  a new Agrius wiper deployed through a supplychain attack


For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com.


ESET Research also offers private APT intelligence reports and data feeds.


For any inquiries about this service, visit the ESET Threat Intelligence page.


IoCs SHA-1FilenameDetectionDescription 1A62031BBB2C3F55D44F59917FD32E4ED2041224fantasy35.exeMSIL/KillDisk.


IFantasy wiper.


1AAE62ACEE3C04A6728F9EDC3756FABD6E342252host2ip.execleanResolves a hostname to an IP address.


LsassDumper.


HImplementation of Mimikatz minidump that dumps credentials from LSASS.


NRGBatch file that wipes some registry keys and is dropped and executed by the Fantasy wiper.


APython script that dumps credential hashes.


XHSandals lateral movement tool and Fantasy spreader.


MITRE ATT&CK techniques This table was built using version 12 of the MITRE ATT&CK framework.


TacticIDNameDescription Resource DevelopmentT1587Develop CapabilitiesAgrius builds utility tools to use during an active exploitation process.


T1587.001Develop Capabilities: MalwareAgrius builds custom malware including wipers (Fantasy) and lateral movement tools (Sandals).


Initial AccessT1078.002Valid Accounts: Domain AccountsAgrius operators attempted to capture cached credentials and then use them for lateral movement. T1078.003Valid Accounts: Local AccountsAgrius operators attempted to use cached credentials from local accounts to gain initial access to additional systems within an internal network.


ExecutionT1059.003Command and Scripting Interpreter:


Windows Command ShellFantasy and Sandals both use batch files that run via the Windows command shell. Privilege EscalationT1134Access Token ManipulationFantasy uses the LookupPrivilegeValue and AdjustTokenPrivilege APIs in advapi32.dll to grant its process token the SeShutdownPrivilege to reboot Windows.


Defense EvasionT1070.006Indicator Removal on Host: TimestompAgrius operators timestomped the compilation timestamps of Fantasy and Sandals.


Credential AccessT1003OS Credential DumpingAgrius operators used several tools to dump OS credentials for use in lateral movement.


DiscoveryT1135Network Share DiscoveryAgrius operators used cached credentials to check for access to other systems within an internal network.


Lateral MovementT1021.002Remote Services: SMB/Windows Admin SharesAgrius operators used cached credentials to connect over SMB to systems within an exploited internal network.


T1570Lateral Tool TransferAgrius operators used Sandals to push batch files over SMB to other systems within an internal network.


ImpactT1485Data DestructionThe Fantasy wiper overwrites data in files and then deletes the files.


T1561.002Disk WipeFantasy wipes the MBR of the Windows drive and attempts to wipe the OS partition.


T1561.001Disk Wipe: Disk Content WipeFantasy wipes all disk contents from non-Windows drives that are fixed drives.


T1529System Shutdown/RebootFantasy reboots the system after completing its disk and data wiping payloads.


Appendix File extensions (682) targeted by Fantasy wiper when not targeting all file extensions.


File extensions highlighted in yellow (68) are common filename extensions in Windows.


Notably absent are file extensions dll and sys. $$$blenddrwjspnyfqualsoftcodetdb $dbblend1dsbkb2oabquicken2015backuptex 001blend2dsskbxobjquicken2016backuptga 002blobdtdkc2obkquicken2017backupthm 003bm3dwgkdbodbquickenbackuptib 113bmkdxbkdbxodcqv~tibkp 3dmbookexportdxfkdcodfr3dtif 3dsbpadxgkeyodgraftig 3frbpbem1kfodmrartis 3g2bpmepkkpdxodprattlg 3gpbpnepslayoutodsrawtmp 3prbpserbsqllbfodtrbtmr 73bbpwerflcboebrbctor 7zbsaesmldabakoggrbftrn __abupexelitemodoilrbkttbk __bcexfllxoldrbstxt abcaafbclnkonepkgrdbuci ab4casfbfltxorfre4upk abacbkfbkluaorirgss3av2i abbucbsfbulvlorigrimvb abfcbufbwmostrmvbk abkcdffdbm2otgrmbakvbm abucdrffm3uothrmgbvbox-prev abu1cdr3ffdm4aotproflvcf accdbcdr4fffm4votsrrrvdf accdecdr5fhmapottrtfvfs0 accdrcdr6fhdmaxoyxrw2vmdk accdtcdrwfhfmbfp12rwlvob achcdxflambkp7brwzvpcbackup acpce2flatmbwp7cs3dbvpk acrcelflkamcmetapabsafenotebackupvpp_pc actcenon~flkbmdbpagessas7bdatvrb adbcerflvmdbackuppaksavvtf adicfpfmbmdcpaqsayw01 adscfrforgemddatapassbw3x aeacgmfosmdfpatsbbwallet aficibfpkmdinfopbasbswalletx agdlck9fpsxmefpbbsbuwar aiclassfpxmempbdsdOwav aitclsfshmenupbfsdawb2 alcmfftmbmfwpbjsdcwbb apjcmtfulmigpblsdfwbcat apkconfigfwbackupmkvpbx5scriptsidwbk arccpifxgmlxpbxscriptsiddwbx arch00cppfzammwpcdsidnwin arwcr2fzbmoneywellpctsiewjf as4crawgb1mospdbsimwma asdcrdsgb2movpddsiswmo asfcrtgbpmp3pdfskbwmv ashbakcrwgdbmp4pefsldmwotreplay asmcsghompbpemsldxwpb asmxcsdghsmpegpfislmwpd aspcshgraympgpfxslnwps aspxcslgreympqgephpsmewspak assetcsmgrymrwphp5sn1wxwanam asvcssgs-bckmrwrefphtmlsn2x asvxcsvgzmsgpk7snax11 asxd3dbsphmsipkpasssnsx3f ateda0hbkmsimplsnxxbk atidachkdbmv_plcspfxf avidashkxmydplcspgxis awgdashhplgmynotesbackuppngspixla ba6daziphppnb7potspsxlam ba7dbhtmnbapotmsqbxlk ba8db-journalhtm1nbakpotxsqlxlm ba9db0htmlnbdppamsqlitexlr bacdb3hvplnbdppssqlite3xls backdbaibanknbfppsmsqlitedbxlsb backupdbfibdnbippsxsr2xlsm backup1dbkibknbkpptsrfxlsx backupdbdbsibznbspptmsrrxlt bakdbxicbunbupptxsrtxltm bak2dc2icfncfpqb-backupsrwxltx bak3dcricxsncoprfst4xlw bakxdcsidxndprvst6xml bak~dddiifndapsst7ycbcra bankddociiqnddpsast8yrcbck barddrwincpasnefpsafe3stdyuv batddsinddnfbpsdstgzbfx bayderindexnfcpskstizip bbbdesinprogressnk2pspimagestwztmp bbzdescipdnoppststx~cw bc6designisonoyptbsty bc7dgcitdbnpfptxsum bckdimitlnpspvcsv$ bckpdivxitmnrbakpvhdsv2i bcmdiyiv2inrspysvg bdbdjvuiwdnrwqbaswf bffdmpiwins2qbbsxc bgtdnaj01ns3qbksxd bifdngjarns4qbmsxg bifxdocjavansdqbmbsxi bigdocmjbknsfqbmdsxm bikdocxjdcnsgqbrsxw bk1dotjpanshqbwsyncdb bkcdotmjpentlqbxt12 bkfdotxjpegnwbqbyt13 bkpdovjpgnwbakqdftar bkupdpbjpsnx2qictax bkzdrfjsnxlqsftbk 7 Dec 2022 - 11:30AM


Executive Summary Malware authors often throw curve balls that are meant to confound automated detection systems.

Tailoring Sandbox Techniques to Hidden Threats


We’ve adapted to these techniques by tailoring our analysis platform in a couple of notable ways that we’ll discuss, particularly to address malware that engages in sandbox evasion.


The first is an approach we call “dependency emulation,” where we can successfully detonate malware samples that would not normally be able to execute in our sandbox environment due to a lack of dependencies.


We will also discuss our strategies of stealthy instrumentation for analysis of encrypted network traffic, to combat the ways SSL can be used to complicate command-and-control (C2) traffic analysis.


One overarching goal malware authors share is to remain undetected until their overall objective is reached.


As we’ve previously detailed in this blog post series, this has resulted in a seemingly limitless number of evasions and strategies targeted at confounding sandboxing and static analysis approaches.


Due to the endless cat-and-mouse nature of reacting to malware authors’ efforts to remain undetected, we’ve come to understand that the most important characteristic for any automated malware analysis platform is adaptability.


Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire.


Table of Contents Dependency EmulationExample File InfectorMitigating the Dependency ProblemVMI SSL/TLS DecryptionTLS HandshakesExample SSL Decryption With WiresharkConclusionIndicators of Compromise Dependency Emulation In the context of malware execution, we talk a lot about dependencies.


When we do, we’re referring to additional code that an executable depends on that is not inside the executable file.


On Windows, external dependencies are usually Dynamically Linked Libraries (DLLs) that contain additional functionality that can be imported into the process to execute.


Often malware does not require external libraries in order to execute its malicious code, or it might call functions from those external libraries in a very late stage of its execution.


Over the past few years we’ve noticed a large uptick in malicious Windows executables that require external libraries for things like graphical user interfaces or better cross-platform support, and if the libraries are missing, then the malicious sample won’t be able to run.


When Windows cannot load an application because of a missing library, it will show a “System Error” error message box that displays the missing library name.


When we run any executable in our sandbox environment that requires dependencies that are not present, we would see the same error.


But we wouldn’t be able to get any analysis information from the sample because no malicious code was executed.


In Figure 1, we can see a screenshot of the ATMSpitter malware family, which requires the DLL MSXFS.dll to fully detonate.


Without the required DLL, we would just see an error dialog telling us that Windows can’t run this file.


If we place the correct file inside the same directory and run the sample again, it runs just fine


and we can extract information such as executed system calls and modified memory regions.


ATMSpitter malware requires MSXFS.dll to run.


File infectors like Sality, Floxif, Expiro and Ramnit typically infect predefined sets of executables that they find on the disk.


If the infected file requires specific libraries that are not part of the operating system (OS), then chances are it’s not going to detonate inside a malware analysis sandbox because these dependencies likely won’t be preinstalled in the environment.


Our sandbox environments are constrained in resources like disk space, and the number of DLL files in the world is seemingly infinite.


Normally, when we run into this situation and the OS loader refuses to execute our file, we are left with no data at all from dynamic analysis.


What is even more frustrating about this situation is that in many cases, those dependencies don’t matter for infected files in that they aren’t even going to be used.


File infectors usually call their malicious code very early (e.g., by replacing an early call instruction to their malicious code, or by overwriting the entry point in the PE header) before any function calls from external libraries are ever called.


The OS will refuse to load and execute our file, despite the fact that none of the dependencies mattered anyway.


Example File Infector Let’s take a look at one file that has been infected by the Sality malware, which requires external dependencies to run inside a sandbox.


The original file is Groove Audit Service from Microsoft Office, and it requires dependencies from the libraries GrooveNew.dll and GroveUtil.dll (shown in Figure 2).


If those two libraries are missing on the system, then the sample won’t be able to run.


The required dependencies.


If we compare the original file to the infected file inside a PE viewer like StudPE (shown in Figure 3), we notice that the infector has modified only a few values in the PE headers including the size of the image, checksum and section flags to make the last section executable.


Sality infected executable compared to the original file.


But if we open both the executables inside IDA Pro, we immediately see that the code at the entry point is totally different compared to the original (shown in Figures 4 and 5, below).


The malicious code in the infected file is being called right at the entry point and doesn’t require any dependencies to fully infect the system.


However, because of the required dependencies, regular malware analysis sandboxes won’t be able to run this kind of file.


Original entry point.


Modified entry point.


Mitigating the Dependency Problem What can we do about this dependency problem for analysis at scale?


Dependency emulation is an approach we’ve recently prototyped and found useful to address this.


The main idea of this approach is to detect this situation automatically, and to adapt our sandbox environment to the files being detonated to ensure executables will have a chance to detonate.


Since we have full control over the sandbox, it’s easy to determine that the executable under analysis requires an external library, and to lie to the executable that all of its dependency requirements are met.


Given the million or so unique Windows executables we process daily, it would be an extremely difficult (if not impossible) task to automatically detect and add the specific external libraries for each executable that required external dependencies.


There are literally hundreds of millions of libraries out there with numerous versions for each, and it’s not really feasible to support providing any arbitrary library in a way that guarantees the intended execution of every sample.


However, as we’ve discussed in our initial post in this blog series, we often don't need full execution for accurate detection.


If we can get the malware sample under analysis to get past the Windows loader, initialize itself and unpack any additional payloads, we have a much better shot at detection.


Otherwise, we simply get an error from the Windows loader (as shown in Figure 1) and no additional information beyond what static analysis would buy us.


But what happens when the executable tries to call a function in one of those dependencies?


The bad news is that, since we aren’t trying to provide actual copies of the required libraries, we can’t correctly simulate the function calls into any of the libraries not present in our environment.


The good news is that, in most cases, this is still enough for accurate detection.


We don’t need to correctly execute every code path present in the executable, we just need enough execution and memory artifacts for accurate detection.


For this reason, in order to avoid unintentional crashes or bugs from the analyzed sample, our sandbox stops the execution if any function from the generated stub libraries is called.


All things considered, with this approach we've seen a lot of samples detonate that wouldn't otherwise, and we've seen many correct detections.


VMI SSL/TLS Decryption Another challenge we’ve faced with analyzing malware at scale is how to stealthily spy on TLS encrypted traffic in a way that’s not detectable by the malware.


As HTTPS and other protocols built on SSL have become increasingly ubiquitous for accessing resources across the internet, it’s not surprising that malware authors also use this protocol for other things, such as pulling down the next stage of their payload, or C2 communications.


It is possible, of course, to take the easy route and intercept and decrypt all of the traffic from our sandbox with a meddler-in-the-middle approach.


The problem with this is that it’s detectable by examining and validating TLS certificates.


It’s also possible to instrument and log calls to some of the higher level networking APIs, but again, this is also detectable in many cases and isn’t going to get us all encrypted communications.


One solution we’ve found useful for this problem is to detect when TLS connections are being initiated and log the symmetric keys generated for the SSL/TLS connection using virtual machine introspection (VMI).


Before we look into that detection method, let’s have a quick lesson on TLS handshakes.


TLS Handshakes When an SSL/TLS connection is being established, certain data between the local system and the remote server is exchanged to validate each side's authenticity and generate symmetric keys to encrypt data over the wire.


This data includes the following: Preferred TLS version Supported cipher suites 32 bytes of random data used in the key generation algorithm A data signature, in the case of an ephemeral elliptic-curve Diffie-Hellman (ECDHE) key exchange An example of an ECDHE “Server Hello” message is shown in Figure 6. Figure 6.


Wireshark screenshot illustrating the initial handshake for an SSL connection.


In the case of a Diffie-Hellman (DH) handshake, additional DH parameters are then exchanged, and each side separately calculates a pre-master secret.


Finally, the same master secret key is calculated on each side by utilizing the pre-master secret and the client and server random values.


The calculated master secret is 48 bytes in length.


Through reverse engineering efforts, we discovered that this key generation occurs in the ncrypt.dll library in recent versions of the Windows OS.


The key generation happens in memory, so the key is never written to disk and it doesn’t traverse the wire.


By knowing the exact location in code where each master key is generated and precisely where it resides in memory, it is possible to extract the key.


This can be accomplished with, for example, an analysis engine via virtual machine introspection, which makes a system invisible to the malware.


A similar approach can be implemented in instances where other third party libraries are used for key generation, such as OpenSSL.


An example output, which includes everything needed to decrypt TLS traffic, is shown in Figure 7.


Extracted random value and master key.


Final keys and initialization vectors used to encrypt and decrypt network traffic are generated from the master secret through a key expansion.


Conveniently, the open source tool Wireshark/Tshark accepts a keyfile to perform this decryption automatically on collected pcap traffic.


Example SSL Decryption With Wireshark Let's take a look at a real world example of a sample that belongs to the malware family FormBook.


The sample is loaded by a loader written in Delphi, which downloads the next stage from a public file storage service using HTTPS.


If we open the recorded package capture in Wireshark and provide the extracted SSL/TLS keys that were extracted by the analysis platform, we should be able to see the SSL encrypted traffic to the public file storage service, including the downloaded data.


The random client value and the master secret key must be stored in a specific file format that Wireshark supports.


It looks like this: CLIENT_RANDOM


<random_client_value> <master_secret_key> To provide the decryption keys to Wireshark, we have to use the option ssl.keylog_file, which we can pass through the command line.


For example: Wireshark -r guest_traffic.pcap -o "ssl.keylog_file:key_capture.keys" After opening the capture (pcap) in Wireshark, the TLS encrypted data will be decrypted, and we can use the http filter to get the decrypted HTTPS traffic.


This is shown in Figure 8. Figure 8.


Decrypted HTTPS traffic.


In Figures 9 and 10, we can see the communication to the public file storage service.


Communication to the public file storage service.


Downloaded data from public file storage.


With the decrypted content, we can write more precise behaviors and signatures that match a malicious sample's network communication.


Conclusion In this post we have discussed two important ways we’ve been able to tailor our analysis environment.


As we’ve mentioned in previous posts, adaptability in sandboxing is exceptionally important when it comes to staying on top of the malware detection problem.


Threats are continually evolving, and architecting analysis systems as more of a flexible, nicely abstracted software development kit instead of a stand-alone monolithic application is crucial.


With this in mind, we’ve gone over two important ways our platform adaptability has paid off in Advanced WildFire.


With Dependency Emulation, we can increase our detonation rates to collect more execution logs necessary for accurate detection.


With VMI SSL/TLS Decryption, we have visibility into all SSL/TLS communications in a way that isn’t detectable by malware authors.


Once again, if you’ve made it this far, thank you again for reading and we hope you enjoyed this peek into some of the more interesting work we’ve been doing as part of our never-ending endeavor to accurately detect every last malicious file the global internet has to offer us.


Indicators of Compromise SHA-256 Name c5b43b02a62d424a4e8a63b23bef8b022c08a889a15a6ad7f5bf1fd4fe73291f ATMSpitter a3b2de8f0d648f3e157300d0a88971919eb273b7d1c7b9ed023f26b5cc0ac3ca Sality infected file 4e32a6000a2b33ed0b8e4cf1256876c356cf5508ce0df2752fcfa214b6c2795b Formbook (SSL Decryption)


Get updates from Palo Alto Networks! Sign up to receive the latest news, cyber threat intelligence and research from us


SUMMARY Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors.


These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware.


Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.


Actions to take today to mitigate cyber threats from ransomware: Prioritize remediating known exploited vulnerabilities.


Train users to recognize and report phishing attempts.


Enable and enforce multifactor authentication.


The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known Royal ransomware IOCs and TTPs identified through FBI threat response activities as recently as January 2023.


Since approximately September 2022, cyber criminals have compromised U.S. and international organizations with a Royal ransomware variant.


FBI and CISA believe this variant, which uses its own custom-made file encryption program, evolved from earlier iterations that used “Zeon” as a loader.


After gaining access to victims’ networks, Royal actors disable antivirus software and exfiltrate large amounts of data before ultimately deploying the ransomware and encrypting the systems.


Royal actors have made ransom demands ranging from approximately $1 million to $11 million USD in Bitcoin.


In observed incidents, Royal actors do not include ransom amounts and payment instructions as part of the initial ransom note.


Instead, the note, which appears after encryption, requires victims to directly interact with the threat actor via a .onion URL (reachable through the Tor browser).


Royal actors have targeted numerous critical infrastructure sectors including, but not limited to, Manufacturing, Communications, Healthcare and Public Healthcare (HPH), and Education.


FBI and CISA encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.


Download the PDF version of this report: #StopRansomware: Royal Ransomware (PDF, 586.96 KB )


For a downloadable copy of IOCs, see AA23-061A STIX XML (XML, 114.26 KB ) TECHNICAL DETAILS Note: This advisory uses the MITRE ATT&CK:registered: for Enterprise framework, version 12.


See MITRE ATT&CK for Enterprise for all referenced tactics and techniques.


Royal ransomware uses a unique partial encryption approach that allows the threat actor to choose a specific percentage of data in a file to encrypt.


This approach allows the actor to lower the encryption percentage for larger files, which helps evade detection.[1]


In addition to encrypting files, Royal actors also engage in double extortion tactics in which they threaten to publicly release the encrypted data if the victim does not pay the ransom.


Initial Access Royal actors gain initial access to victim networks in a number of ways including: Phishing.


According to third-party reporting, Royal actors most commonly (in 66.7% of incidents) gain initial access to victim networks via successful phishing emails [T1566].


According to open-source reporting, victims have unknowingly installed malware that delivers Royal ransomware after receiving phishing emails containing malicious PDF documents [T1566.001], and malvertising [T1566.002].[2] Remote Desktop Protocol (RDP).


The second most common vector Royal actors use (in 13.3% of incidents) for initial access is RDP compromise.


Public-facing applications.


FBI has also observed Royal actors gain initial access through exploiting public-facing applications [T1190]. Brokers.


Reports from trusted third-party sources indicate that Royal actors may leverage brokers to gain initial access and source traffic by harvesting virtual private network (VPN) credentials from stealer logs.


Command and Control Once Royal actors gain access to the network, they communicate with command and control (C2) infrastructure and download multiple tools [T1105].


Legitimate Windows software is repurposed by Royal operators to strengthen their foothold in the victim’s network.


Ransomware operators often use open-source projects to aid their intrusion activities; Royal operators have recently been observed using Chisel, a tunneling tool transported over HTTP and secured via SSH [T1572], to communicate with their C2 infrastructure.


FBI has observed multiple Qakbot C2s used in Royal ransomware attacks, but has not yet determined if Royal ransomware exclusively uses Qakbot C2s.


Lateral Movement and Persistence Royal actors often use RDP to move laterally across the network


Microsoft Sysinternals tool PsExec has also been used to aid lateral movement.


FBI has observed Royal actors using remote monitoring and management (RMM) software, such as AnyDesk, LogMeIn, and Atera, for persistence in the victim’s network


In some instances, the actors moved laterally to the domain controller.


In one confirmed case, the actors used a legitimate admin account to remotely log on to the domain controller [T1078].


Once on the domain controller, the threat actor deactivated antivirus protocols


[T1562.001] by modifying Group Policy Objects


[T1484.001]. Exfiltration Royal actors exfiltrate data from victim networks by repurposing legitimate cyber pentesting tools, such as Cobalt Strike, and malware tools and derivatives, such as Ursnif/Gozi, for data aggregation and exfiltration.


According to third-party reporting, Royal actors’ first hop in exfiltration and other operations is usually a U.S. IP address.


Note: In reference to Cobalt Strike and other tools mentioned above, a tool repository used by Royal was identified at IP: 94.232.41[.]105 in December 2022.


Encryption Before starting the encryption process, Royal actors: Use Windows Restart Manager to determine whether targeted files are currently in use or blocked by other applications [T1486].[1] Use Windows Volume Shadow Copy service (vssadmin.exe) to delete shadow copies to prevent system recovery.[1] FBI has found numerous batch (.bat) files on impacted systems which are typically transferred as an encrypted 7zip file.


Batch files create a new admin user [T1078.002], force a group policy update, set pertinent registry keys to auto-extract


and execute the ransomware, monitor the encryption process, and delete files upon completion—including Application, System, and Security event logs [T1070.001].


Malicious files have been found in victim networks in the following directories: C:\Temp\ C:\Users\


Xollam, the Latest Face of TargetCompany This blog talks about the latest TargetCompany ransomware variant, Xollam, and the new initial access technique it uses.


We also investigate previous variants' behaviors and the ransomware family's extortion scheme.


By: Earle Maui Earnshaw, Nathaniel Morales, Katherine Casona, Don Ovid Ladores June 06, 2023Read time: ( words) Save to Folio Subscribe After first being detected in June 2021, the TargetCompany ransomware family underwent several name changes that signified major updates in the ransomware family, such as modifications in encryption algorithm and different decryptor characteristics.


The earliest samples of the TargetCompany ransomware appended victims’ files with the extension “.tohnichi,” the name of its victim enterprise at that time, signifying a targeted attack on the organization of the same name.


As a result, it was initially known as the Tohnichi ransomware.


Later, the group continued appending encrypted files with names based on its victims, such as “.artis” for the Artis Zoo in Amsterdam.


Other extensions include “.herrco,” “.brg,” and “.carone.” Industry experts then later identified the ransomware as TargetCompany from the pattern it adopted of appending encrypted files after the company it was targeting.


The variants Tohnichi (active in 2021), Mallox, and Fargo (both active in 2022) targeted vulnerabilities in Microsoft SQL (MS SQL) Server for initial access.


We elaborate on the behavior of these variants in our Ransomware Spotlight: TargetCompany.


The infection chain of the earlier TargetCompany variants Our investigations show that its latest variant, Xollam, now deviates from the gang’s tried-and-tested initial access method.


In this blog, we discuss this latest development in the TargetCompany ransomware’s behavior and look into its previous infection chains.


Simultaneously active: Xollam and Mallox variants


In 2023, Xollam was observed as following a technique similar to the one followed by phishing campaigns: using Microsoft OneNote files as initial access to spread and deliver malware.


This latest TargetCompany variant executed a spam campaign with malicious OneNote file attachments, a deviation from its roots of targeting vulnerable MS SQL databases.


Based on our investigations, Xollam uses a pseudo-fileless technique through PowerShell, which executes reflective loading to download its payload.


As we discuss in later sections, we have also observed this technique in earlier variants of the TargetCompany ransomware.


The attack flow of the latest TargetCompany variant, Xollam, which uses malicious OneNote files for initial access The latest variant of the ransomware, Xollam, was detected in February this year.


In the same month, the older Mallox variant was also active, as it claimed the attack on the Federation of Indian Chambers of Commerce and Industry (FICCI).


The gang released 1.28 GB of compressed datasets that included financial balance sheets, employee reimbursement details, bank statements and internet banking credentials, industry audit reports, and documents related to FICCI subcommittees.


Reflective loading, Mallox, and Fargo variants


The Mallox variant of the ransomware was first detected in the wild in October 2021.


Later samples in January of the following year showed that the ransomware group started to employ reflective loading as part of its defense evasion.


The Mallox variant connects to an IP address to load the encrypted ransomware, with its download URL only available for approximately 24 hours.


Notably, this made the dynamic analysis of old samples difficult.


Our investigations revealed that the payload downloaded by the PowerShell script was a .NET downloader, which would subsequently retrieve an encrypted payload from the command-and-control (C&C) server.


The downloaded file has a random file name and might have different extensions such as “.png,” “.bmp,” and “.jpg,” among others.


A closer look at the reflective loading technique that TargetCompany threat actors incorporated; the IP address it connects to changes every 24 hours and deploys different payloads The payload would then be decrypted through XOR or inversion and executed in memory.


The specific payload that is downloaded varies depending on the link on the .NET downloader.


Both Mallox and Fargo variants use a set of tools via remote desktop for defense evasion.


It’s important to note that reflective loading enabled the Mallox variant to evade traditional antivirus solutions, making it challenging for organizations to protect themselves against these attacks.


Meanwhile, the Remcos backdoor payload is executed via WmiPrvSE.exe, and the payload most likely arrives by exploiting public-facing websites and domains.


Our investigations showed that the gang used different sets of defense evasion and reconnaissance tools such as GMER and Advance Process Termination to manually uninstall antivirus products on the target system.


We also observed the presence of YDArk.exe (PCHunter64) for performing rootkit behaviors, and that TargetCompany attempts to terminate security-related processes and services by dropping KILLAV.


In addition, the ransomware drops a batch file named killer.bat that terminates various services and applications, including GPS-related services.


Afterward, it proceeds to steal system information like machine details and other relevant data.


TargetCompany ransomware defense evasion routine


The ransomware encrypts the victim's files using the ChaCha20 encryption algorithm and generates the encryption keys using a combination of Curve25519, an example of elliptic curve cryptography, and AES-128.


In June 2022, the gang targeted other victims with encrypted files appended with the extension “.fargo.”


We also observed that like Mallox, the Fargo variant employed reflective loading.


In the last two months of 2022, there was an increase in attacks launched by the TargetCompany ransomware using its Mallox variant.


Extortion While the Mallox and Fargo variants were operating simultaneously in 2022, TargetCompany initiated its double-extortion scheme by setting up a Telegram channel where it could publish stolen information.


In August 2022, just two months after the group launched its Fargo variant, Mallox created a Twitter account where it could announce its victims.


Since this account was eventually suspended, the threat actors created a new one. Figure 6.


The first Twitter account (eventually suspended) that Mallox created for announcing its victims (top), and the new Twitter account that replaced it (bottom); the new account remains active as of this writing In November of the same year, Mallox launched its data leak site where, as of writing, it has declared only 20 victims.


However, our telemetry data revealed far more attacks at 269 attempts on Trend Micro customers from March 2022 to April 2023.


In a January 2023 interview, threat actors behind TargetCompany said that they choose only a small percentage of their victims to publish on their leak site.


They also limit the amount of leaked data to what they deem particularly interesting and claim to have no intention of publishing everything.


While the group said that it remains small and closed, the actors behind it mentioned that they are “open to suggestions.”


Interestingly, a new member of the cybercrime forum RAMP under the name “Mallx” was observed recruiting affiliates for the Mallox ransomware-as-a-service (RaaS) affiliate program.


Our investigations also revealed that the ransomware might have connections with other groups such as the BlueSky ransomware, as well as the threat actors who perform brute-force attacks on MS SQL Servers.


TargetCompany shares similarities with these groups in terms of threat actor profiles, targets, deployed remote control, and encryption algorithm.


We discuss other possible affiliations, as well as victim profiles and behaviors in our Spotlight feature on the ransomware group.


Conclusion The TargetCompany ransomware is making bolder ventures beyond its tried-and-tested techniques by joining the bandwagon of OneNote phishing campaigns, which allows it to cast a wider net for increased profitability.


Within just two years of activity, the threat actors behind the ransomware are proving their hunger for prolificacy, expanding their business model with a RaaS affiliate program and maintaining several platforms to announce victims and expose stolen data.


We can expect TargetCompany to make even bigger moves in the future, especially since the threat actors behind it have admitted that they created TargetCompany to move away from the restrictions and inflexibility of their previous groups.


Now unhindered, the gang will naturally try to maximize profits from its victims.


To protect systems from ransomware attacks, we recommend that both individual users and organizations implement best practices such as applying data protection and backup and recovery measures to secure data from possible encryption or erasure.


Conducting regular vulnerability assessments and patching systems in a timely manner can also minimize the damage dealt by ransomware families that abuse exploits.


We advise users and organizations to update their systems with the latest patches and apply multilayered defense mechanisms.


End users and enterprises alike can mitigate the risk of infection from new threats like the TargetCompany ransomware by following these security best practices: Enable multifactor authentication (MFA) to prevent attackers from performing lateral movement inside a network.


Adhere to the 3-2-1 rule when backing up important files.


This involves creating three backup copies on two different file formats, with one of the copies stored in a separate location.


Patch and update systems regularly.


It’s important to keep operating systems and applications up to date and maintain patch management protocols that can deter malicious actors from exploiting any software vulnerabilities.


Authors Earle Maui Earnshaw Threats Analyst Nathaniel Morales Threat Analyst Katherine Casona Threat Analyst Don Ovid Ladores Threats Analyst


Prilex is a Brazilian threat actor that has evolved out of ATM-focused malware into modular point-of-sale malware.


The group was behind one of the largest attacks on ATMs in the country, infecting and jackpotting more than 1,000 machines, while also cloning in excess of 28,000 credit cards that were used in these ATMs before the big heist.


But the criminals’ greed had no limits: they wanted more, and so they achieved it.


Active since 2014, in 2016, the group decided to give up ATM malware and focus all of their attacks on PoS systems, targeting the core of the payment industry.


These are criminals with extensive knowledge of the payment market, and EFT software and protocols.


They quickly adopted the malware-as-a-service model and expanded their reach abroad, creating a toolset that included backdoors, uploaders and stealers in a modular fashion.


Since then, we have been tracking the threat actor’s every move, witnessing the damages and great financial losses they brought upon the payments industry.


The Prilex PoS malware evolved out of a simple memory scraper into very advanced and complex malware, dealing directly with the PIN pad hardware protocol instead of using higher level APIs, doing real-time patching in target software, hooking operating system libraries, messing with replies, communications and ports, and switching from a replay-based attack to generate cryptograms for its GHOST transactions even from credit cards protected with CHIP and PIN technology.


It all started with ATMs during a carnival celebration During the carnival of 2016, a Brazilian bank realized that their ATMs had been hacked, with all the cash contained in those machines stolen.


According to reports from law enforcement agencies, the criminals behind the attack were able to infect more than 1,000 machines belonging to one bank in the same incident, which allowed them to clone 28,000 unique credit cards across Brazil.


The attackers did not have physical access to the machines, but they were able to access the bank’s network by using a DIY device containing a 4G router and a Raspberry PI.


By opening a backdoor, they were able to hijack the institution’s wireless connection and target ATMs at will.


After obtaining initial network access, the attacker would run a network recognition process to find the IP address of each of the ATMs.


With that information in hand, the attackers would launch a lateral movement phase, using default Windows credentials and then installing custom-crafted malware in the desired systems.


The backdoor would allow the attacker to empty the ATM socket by launching the malware interface and typing a code supplied by the mastermind, the code being specific to each ATM being hacked.


ATM infected with Prilex ready to dispense money The malware used in the attack was named Prilex and had been developed from scratch by using privileged information and advanced knowledge of the ATM network.


To control the ATMs, Prilex did patch in legitimate software for jackpotting purposes.


Besides its capability to perform a jackpot, the malware was also capable of capturing information from magnetic strips on credit and debit cards inserted into the infected ATMs.


Afterwards, this valuable information could be used to clone cards and steal further funds from the bank’s clients.


Evolving into PoS malware Prilex has evolved out of ATM-focused malware into modular point-of-sale malware targeting payment systems developed by Brazilian vendors, the so-called EFT/TEF software.


As we noted in 2018, there are many similarities between their ATM and PoS versions.


Their first PoS malware was spotted in the wild in October 2016.


The first two samples had 2010/2011 as the compilation date, as shown on the graph below.


However, we believe that invalid compilation dates were set due to incorrect system date and time settings.


In later versions, the timestamps corresponded to the times when the samples were discovered.


We also noticed that in the 2022 branch, the developers started using Subversion as the version control system.


Versions of the Prilex PoS malware: 3 new versions in 2022 (download)


As we see on the graph, Prilex was highly active in 2020, but suddenly disappeared in 2021, resurfacing in 2022 with a release of three new variants.


The PoS version of Prilex is coded in Visual Basic, but the stealer module, described in this article, is in p-code.


In a nutshell, this is an intermediate step between high-level instructions in a Visual Basic program and the low-level native code executed by a CPU.


Visual Basic translates p-code statements into native code at runtime.


A link to the past Prilex is not the only type of PoS malware to originate in Brazil.


We saw a weak link with the old Trojan-Spy.Win32.SPSniffer, which we described in 2010: both families are able to intercept signals from PIN pads, but use different approaches in doing so. PIN pads are equipped with hardware and security features to ensure that security keys are erased if someone tries to tamper with the device.


In fact, the PIN is encrypted in the device upon entry using a variety of encryption schemes and symmetric keys.


Most often, this is a triple DES encoder, making it hard to crack the PIN.


There is a problem, though: these devices are always connected to a computer via a USB or serial port, which communicates with the EFT software.


Older and outdated PIN pad devices use obsolete and weak cryptography schemes, making it easy for malware to install a USB or serial port sniffer to capture and decrypt the traffic between the PIN pad and the infected system.


This is how SPSniffer gets credit card data.


Sometimes the traffic is not even encrypted.


SPSniffer: serial port sniffer allowing capture of not-encrypted traffic


The main approach used by Prilex for capturing credit card data is to use a patch in the PoS system libraries, allowing the malware to collect data transmitted by the software.


The malware will look for the location of a particular set of executables and libraries in order to apply the patch, thus overwriting the original code.


With the patch in place, the malware collects the data from TRACK2, such as the account number and expiration date, in addition to other cardholder information needed to perform fraudulent transactions.


Initial infection vector Prilex is not a widespread type of malware, as it is not distributed through email spam campaigns.


It is highly targeted and is usually delivered through social engineering, e.g., a target business may receive a call from a “technician” who insists that the company needs to update its PoS software.


The fake technician may visit the target in person or request the victims to install AnyDesk and provide remote access for the “technician” to install the malware.


Warning from a PoS vendor about Prilex social engineering attacks Messing with the EMV standard Brazil began migrating to EMV in 1999, and today, nearly all cards issued in the country are chip enabled.


A small Java-based application lives inside the chip and can be easily manipulated in order to create a “golden ticket” card that will be valid in most—if not all—point-of-sale systems.


This knowledge has enabled the criminals to upgrade their toolset, allowing them to create their own cards featuring this new technology and keeping them “in the business.”


The initial versions of Prilex were capable of performing the “replay attack,” where, rather than breaking the EMV protocol, they instead took advantage of poor implementations.


Since payment operators fail to perform some of the validations required by the EMV standard, criminals can exploit this vulnerability within the process to their benefit.


In this kind of attack, fraudsters push regular magnetic stripe transactions through the card network as EMV purchases, as they are in control of a payment terminal and have the ability to manipulate data fields for transactions put through that terminal.


Later they switched to capturing traffic from real EMV-based chip card transactions.


The thieves could insert stolen card data into the transaction stream, while modifying the merchant and acquirer bank account on the fly.


Brazilian cybercriminals have successfully launched replay attacks since at least 2014.


As pointed out by Brian Krebs, a small financial institution in New England battled some $120,000 in fraudulent charges from Brazilian stores within less than two days.


The bank managed to block $80,000, but the bank’s processor, which approves incoming transactions when the core systems are offline, let through the other $40,000.


All of the fraudulent transactions were debit charges.


All of them came across MasterCard’s network and appeared to be chip transactions without a PIN to MasterCard’s systems.


Also worth mentioning is the attack against a German bank in 2019, which registered €1.5 million in losses and used the same technique.


The Prilex gang claimed responsibility.


Judging by the name fields and the functionality of the tool, they probably used the software they are selling in the black market.


To automate attacks using cloned credit cards, Prilex criminals used tools like Xiello, discovered by our telemetry in 2020.


This tool allows the cybercriminals to use credit cards in a batch when making fraudulent purchases.


It sends the purchase data to credit card acquirers, who then approve or deny the transactions.


Xiello tool used by Prilex to automate transactions


As the payment industry and credit card issuers fixed EMV implementation errors, replay attacks became obsolete and ineffective, pushing the Prilex gang to innovate and adopt other ways of credit card fraud.


From “Replay” to “Ghost” The latest versions of Prilex show certain differences to previous ones in the way the attack occurs: the group has switched from the replay attacks to fraudulent transactions using cryptograms generated by the victim card during the in-store payment process, referred to by the malware authors as “GHOST transactions.”


In these attacks, the Prilex samples were installed in the system as RAR SFX executables that extracted all required files to the malware directory and executed the installation scripts (VBS files).


From the installed files, we can highlight three modules used in the campaign: a backdoor, which is unchanged in this version except for the C2 servers used for communication; a stealer module; and an uploader module.


Prilex methods of maintaining persistence The stealer module is responsible for intercepting all communications between the point-of-sale software and the PIN pad used for reading the card during the transaction.


Once it identifies a running transaction, the malware will intercept and modify the content of the transaction in order to be able to capture the card information and to request new EMV cryptograms to the victim’s card.


These cryptograms are then used in the GHOST transactions.


Method used to parse the PIN pad messages sent/received In order to target a specific process, the criminals will perform an initial screening of the machine—to check if it is an interesting target with enough credit card transactions and to identify the process they will target.


After the process is identified, the malware will move forward to install the hooks needed to intercept the transaction information.


As the communication between the PoS software and the card reader happens through the COM port, the malware will install a hook to many Windows APIs inside the targeted process, aiming to monitor and change data as needed.


Interestingly enough, instead of allocating memory to the hook procedure, Prilex finds free space within the modules memory, a technique called code cave, making it hard for some security solutions to detect the threat in an infected system.


Hook code added into CloseHandle process All captured information from the transaction is saved to an encrypted file placed in a directory previously set by the malware configuration.


Those files will later be sent to the malware C2 server, allowing the cybercriminals to make transactions through a fraudulent PoS device registered in the name of a fake company.


Captured credit card data that will be later sent to the operator server The previous version monitored the transaction in order to get the cryptogram, generated by the card for the original transaction, and then to perform a replay attack using the collected cryptogram.


In this case, the cryptogram has the same ATC (Application Transaction Counter), allowing the fraudulent transaction to be identified by the reuse of the ATC as well as the fact that the date inside the cryptogram did not match the date when it was submitted, as the fraudulent transactions were submitted at a later point in time.


In GHOST attacks performed by the newer versions of Prilex, it requests new EMV cryptograms after capturing the transaction.


These cryptograms will then be used in a fraudulent transaction through one of the cybercrime tools whose output log can be seen below.


[START GHOST] _ 80CA9F17 |9F1701039000 | 002000800826435643FFFFFFFF


| Check PIN9000 _


| 80AE80001D00000000010000000000000000760000008000098620060600B4E5C6EB -> Generate AC80128000AA5EA486052A8886DE06050A03A4B8009000 -> Generated ARQC[END GHOST]


The table above shows the data collected from the malware.


It contains the Authorization Request Cryptogram (ARQC) that was generated by the card and should now be approved by the card issuer.


After dissecting the response (80128000AA5EA486052A8886DE06050A03A4B8009000), we have the following information.


Data Field details 80 12 Size of the response: 18 bytes 80 Cryptogram Information Data: ARQC (Authorization Request Cryptogram): go and ask the issuer 00AA ATC: Application Transaction Counter 5EA486052A8886DE Application Cryptogram 06050A03A4B800 Issuer Application Data 9000 Response OK


Multiple application cryptograms are applied to the card, where the amount of the transaction (blue), ATC (green) and the generated cryptogram (red) change for each transaction.


[START GHOST] 80CA9F179F1701039000002000800826435643FFFFFFFF900080AE80001D00000000010000000000000000760000008000098620060600B4E5C6EB80128000AA5EA486052A8886DE06050A03A4B8009000


[END GHOST]


[START GHOST] 80CA9F179F1701039000002000800826435643FFFFFFFF900080AE80001D00000000100000000000000000760000008000098620060600E22CB55580128000AB8E988F00ACEE5D4806050A03A4B8009000


[START GHOST] 80CA9F179F1701039000002000800826435643FFFFFFFF900080AE80001D0000000020000000000000000076000000800009862006060007EBA76480128000AC5E1E75557CC57E1206050A03A4B8009000


[START GHOST]


[END GHOST] In a nutshell, this is the entire Prilex scheme: Prilex: from infection to cashout Backdoor module The backdoor has many commands, and aside from memory scanning common to memory scrappers, older (ATM) Prilex versions also featured a command to debug a process and peek into its memory.


It is highly likely that this was used to understand target software behavior and perform adjustments on the malware or environment to perform fraudulent transactions.


Older versions of Prilex performed patching on specific software libraries, whereas newer samples do not rely on specific software anymore and will instead hook Windows APIs to perform its job.


The Prilex debugger Here’s a list of commands used in the ATM version of Prilex, which include debugging:


Reboot, SendKeys, ShowForm, Inject, UnInject, HideForm, Recursos, GetZip, SetStartup, PausaProcesso, LiberaProcesso, Debug, SendSnapShot, GetStartup, CapRegion, CapFerro, KillProcess, Shell, Process, GetModules, GetConfig, StartSendScreen, StopSendScreen, ReLogin, StartScan, GetKey, SetConfig, RefreshScreen, Download, TakeRegions, Enviar Arquivo, ScanProcessStart, ScanProcessStop, StartRegiao, StopRegiao, StartDownload, StopDownload.


Even though a new set of commands has been added to the PoS version, we could find some of those from the ATM attack still being used.


Numerous available commands are for general use, allowing the criminals to collect information about the infected machine.


Command Description Download Download a file from the remote server Shell Execute a specified command via CMD GetConfig Get the configuration file KillProcess Terminate a process SetStartup Add the process to a startup registry key StartSendScreen Start screen capture StopSendScreen Stop screen capture Uploader Module This module is responsible for checking the directory specified in the CABPATH parameter in the config file and sending all cab files generated from the stolen transactions to the server; the files are sent through an HTTP POST request.


The endpoint used by the module is also mentioned in the uploader configuration file.


[SNDCAB]CABHOST=C2CABPORT=80CABPAGE=/upload.phpCABPATH=c:\cab The use of this module indicates a change in the group’s operation structure, since in the previous version, the collected information was sent to a server whose address was hardcoded into the stealer code, and the module used the same protocol as the backdoor.


This uploader allows the operator to set the endpoint for the collected information as indicated in the configuration file; judging from the samples analyzed, it is possible to see a different infrastructure involved in the process.


Captured data stored in the uploader C2 Malware-as-a-service In 2019, a website claiming to be affiliated with Prilex started offering what it said was a malware package created by the group.


We have little confidence in these claims: the site could be operated by copycats trying to impersonate the group and catch some money using the reputation Prilex has earned over the years.


This website was still up and running at the time of writing this.


The asking price for what is supposedly a Prilex PoS kit is $3,500.


The website says its owners have worked with Russian cybercriminals in the past, another claim we cannot confirm.


Worth mentioning, too, is that our Digital Footprint Intelligence service found citations of a Prilex malware package sold through Telegram chats, in an underground channel, priced between €10,000 and $13,000.


We have no way of confirming that what is being offered is the real Prilex malware.


At the same time, Prilex now using Subversion is a clear sign they are working with more than one developer.


Conclusions The Prilex group has shown a high level of knowledge about credit and debit card transactions, and how software used for payment processing works.


This enables the attackers to keep updating their tools in order to find a way to circumvent the authorization policies, allowing them to perform their attacks.


Over years of activity, the group has changed its attack techniques a lot.


However, it has always abused processes relating to PoS software to intercept and modify communications with the PIN pad.


Considering that, we strongly suggest that PoS software developers implement self-protection techniques in their modules, such as the protection available through our Kaspersky SDK, aiming to prevent malicious code from tampering with the transactions managed by those modules.


To credit card acquirers and issuers, we recommend avoiding “security by obscurity”: do not underestimate the fraudster.


All EMV validations must be implemented!


Prilex’s success is the greatest motivator for new families to emerge as fast-evolving and more complex malware with a major impact on the payment chain.


To financial institutions who fell victims to this kind of fraud, we recommend our Kaspersky Threat Attribution Engine to help IR teams with finding and detecting Prilex files in attacked environments.


The Prilex family is detected by all Kaspersky products as HEUR:Trojan.Win32.Prilex and HEUR:Trojan.Win64.Prilex.


More details about the threat and a full analysis is available to customers of our Threat Intelligence Reports.


With any requests about our private reports, please contact crimewareintel@kaspersky.com.


Recently, the Eclypsium platform began detecting suspected backdoor-like behavior within Gigabyte systems in the wild.

Supply Chain Risk from Gigabyte App Center Backdoor  Eclypsium  Supply Chain Security for the Modern Enterprise


These detections were driven by heuristic detection methods, which play an important role in detecting new, previously-unknown supply chain threats, where legitimate third-party technology products or updates have been compromised.


Our follow-up analysis discovered that firmware in Gigabyte systems is dropping and executing a Windows native executable during the system startup process, and this executable then downloads and executes additional payloads insecurely.


It uses the same techniques as other OEM backdoor-like features like Computrace backdoor (a.k.a. LoJack DoubleAgent) abused by threat actors and even firmware implants such as Sednit LoJax, MosaicRegressor, Vector-EDK.


Subsequent analysis showed that this same code is present in hundreds of models of Gigabyte PCs.


We are working with Gigabyte to address this insecure implementation of their app center capability.


In the interest of protecting organizations from malicious actors, we are also publicly disclosing this information and defensive strategies on a more accelerated timeline than a typical vulnerability disclosure.


This backdoor appears to be implementing intentional functionality and would require a firmware update to completely remove it from affected systems.


While our ongoing investigation has not confirmed exploitation by a specific threat actor, an active widespread backdoor that is difficult to remove poses a supply chain risk for organizations with Gigabyte systems.


At a high level, the relevant attack vectors include: Compromise in the supply chain Compromise in the local environment Malware persistence via functionality of this firmware in systems A more detailed analysis of these risks is provided with suggested mitigations below.


After a more traditional vulnerability disclosure timeline, we plan to publish details about how this works.


Key Findings There are two important aspects of our findings: Eclypsium automated heuristics detected firmware on Gigabyte systems that drops an executable Windows binary that is executed during the Windows startup process.


This executable binary insecurely downloads and executes additional payloads from the Internet.


Since many more issues like this continue to be discovered, Eclypsium is continuously running at-scale analysis of the information technology supply chain.


Look for additional findings on this blog and the Eclypsium Platform for your organization.


Stage 1:


Firmware dropping OS executable An initial analysis of the affected UEFI firmware identified the following file: 8ccbee6f7858ac6b92ce23594c9e2563ebcef59414b5ac13ebebde0c715971b2.bin


This is a Windows Native Binary executable embedded inside of UEFI firmware binary in a UEFI firmware volume with the following GUID: AEB1671D-019C-4B3B-BA-00-35-A2-E6-28-04-36.


This Windows executable is embedded into UEFI firmware and written to disk by firmware as part of the system boot process, a technique commonly used by UEFI implants and backdoors.


During the Driver Execution Environment (DXE) phase of the UEFI firmware boot process, the “WpbtDxe.efi” firmware module uses the above GUID to load the embedded Windows executable file into memory, installing it into a WPBT ACPI table which will later be loaded and executed by the Windows Session Manager Subsystem (smss.exe) upon Windows startup.


The “WpbtDxe.efi” module checks if the “APP Center Download & Install” feature has been enabled in the BIOS/UEFI Setup before installing the executable into the WPBT ACPI table.


Although this setting appears to be disabled by default, it was enabled on the system we examined.


This executable uses the Windows Native API to write the contents of an embedded executable to the file system at the following location:


%SystemRoot%\system32\GigabyteUpdateService.exe It then sets registry entries to run this executable as a Windows Service.


The mechanism described here is similar to the methods used by other UEFI firmware implants such as LoJax, MosiacRegressor, MoonBounce, and Vector-EDK, referenced previously.


Stage 2: Downloading and running further executables


The dropped Windows executable is a .NET application.


It downloads and runs an executable payload from one of the following locations, depending on how it’s been configured: http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4 https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4 https://software-nas/Swhttp/LiveUpdate4 Plain HTTP (the first bullet above) should never be used for updating privileged code as it is easily compromised via Machine-in-the-middle (MITM) attacks.


However, we noticed that even when using the HTTPS-enabled options, remote server certificate validation is not implemented correctly.


Therefore, MITM is possible in that case also.


The firmware does not implement any cryptographic digital signature verification or any other validation over the executables.


The dropped executable and the normally-downloaded Gigabyte tools do have a Gigabyte cryptographic signature that satisfies the code signing requirements of Microsoft Windows, but this does little to offset malicious use, especially if exploited using Living-off-the-Land techniques (like in the recent alert regarding Volt Typhoon attackers).


As a result, any threat actor can use this to persistently infect vulnerable systems either via MITM or compromised infrastructure. Risks and Impact These issues expose organizations to a wide range of risks and attack scenarios.


Abuse of an OEM backdoor by threat actors – Previously, threat actors have taken advantage of legitimate but insecure/vulnerable “OEM backdoor” software built into the firmware of PCs.


Most notably, Sednit group (APT28, FancyBear) exploited Computrace LoJack to masquerade as legitimate laptop anti-theft feature.


Compromise of the OEM update infrastructure and supply chain – Gigabyte does have documentation on their website for this feature so it may be legitimate, but we cannot confirm what is happening within Gigabyte.


In August 2021, Gigabyte experienced a breach of critical data by the RansomEXX group and then experienced another breach in October 2021 by the AvosLocker group.


Persistence using UEFI Rootkits and Implants – UEFI rootkits and implants are some of the stealthiest and most powerful forms of malware in existence.


They reside in firmware on motherboards or within EFI system partitions of storage media, and execute before the operating system, allowing them to completely subvert the OS and security controls running in higher layers.


Additionally, since most of the UEFI code exists on the motherboard instead of storage drives, UEFI threats will easily persist even if drives are wiped and the OS is reinstalled.


The rate of discovery of new UEFI rootkits has accelerated sharply in recent years as seen by the discovery of LoJax (2018), MosaicRegressor (2020), FinSpy (2021) ESPecter (2021), MoonBounce (2022), CosmicStrand (2022), and BlackLotus (2023).


Most of these were used to enable persistence of other, OS-based malware.


This Gigabyte firmware images and the persistently dropped Windows executable enable the same attack scenario.


Often, the above implants made their native Windows executables look like legitimate update tools.


In the case of MosaicRegressor, the Windows payload was named “IntelUpdater.exe” MITM attacks on firmware and software update features – Additionally, the insecure nature of the update process opens the door to MITM techniques via a compromised router, compromised device on the same network segment, DNS poisoning, or other network manipulation.


It is also important to note that the third connection option, https://software-nas/Swhttp/LiveUpdate4 , is not a fully qualified domain name, but rather, a machine name that would presumably be on the local network.


This means an attacker on a local subnet could trick the implant into connecting to their system, without the need for DNS spoofing.


Ongoing risk due to unwanted behavior within official firmware – Backdoors hidden within UEFI or other firmware can be hard to remove.


Even if the backdoor executable is removed, the firmware will simply drop it again the next time the system boots up.


This challenge was demonstrated before when trying to remove Computrace LoJack and relates to vulnerabilities in Lenovo Service Engine on notebooks and desktops.


Recommendations We recommend exercising caution when using Gigabyte systems or systems with affected motherboards.


Organizations can also take the following actions to minimize the risk: Scan and monitor systems and firmware updates in order to detect affected Gigabyte systems and the backdoor-like tools embedded in firmware.


Update systems to the latest validated firmware and software in order to address security issues like this one. Inspect and disable the “APP Center Download & Install” feature in UEFI/BIOS Setup on Gigabyte systems and set a BIOS password to deter malicious changes.


Administrators can also block the following URLs: http://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4 https://mb.download.gigabyte.com/FileList/Swhttp/LiveUpdate4 https://software-nas/Swhttp/LiveUpdate4 Researchers at Eclypsium Labs are continuing to investigate for any signs of malicious activity related to this discovery.


We will provide additional updates as new information becomes available.


For more information or assistance contact Eclypsium at [email protected].


A list of affected models is available here.


This blog post was authored by Hasherezade and Jérôme Segura

German users targeted with Gootkit banker or REvil ransomware


On November 23, we received an alert from a partner about a resurgence of Gootkit infections in Germany.


Gootkit is a very capable banking Trojan that has been around since 2014 and possesses a number of functionalities such as keystroke or video recording designed to steal financially-related information.


In this latest campaign, threat actors are relying on compromised websites to socially engineer users by using a decoy forum template instructing them to download a malicious file.


While analyzing the complex malware loader we made a surprising discovery.


Victims receive Gootkit itself or, in some cases, the REvil (Sodinokibi) ransomware.


The decision to serve one or the other payload happens after a check with the criminal infrastructure.


Gootkit attacks observed in Germany Security researcher TheAnalyst was the first to publicly identify an active campaign in November using a sophisticated loader that was eventually attributed to Gootkit, a banking Trojan not observed in the wild for some time.


Germany’s Computer Emergency Response Team CERT-Bund later confirmed that German users were being targeted via compromised websites.


Around the same time, we started receiving reports from some of our partners and their ISPs about Gootkit-related traffic.


We were able to confirm Gootkit detections within our telemetry that were all located in Germany.


Figure 1: Gootkit infections in Germany in the wake of the campaign After a couple of days, we remediated over 600 unique machines that had been compromised.


Fake forum template on hacked websites The initial loader is spread via hacked websites using an interesting search engine optimization (SEO) technique to customize a fake template that tries to trick users to download a file.


The template mimics a forum thread where a user asks in German for help about a specific topic and receives an answer which appears to be exactly what they were looking for.


It’s worth noting that the hacked sites hosting this template are not German (only the template is); they simply happen to be vulnerable and are used as part of the threat actor’s infrastructure.


Figure 2: Compromised site loads decoy template to trick victims This fake forum posting is conditionally and dynamically created if the correct victim browses the compromised website.


A script removes the legitimate webpage content from the DOM and adds its own content (the template showing a link to a file to download).


Figure 3: A view of the HTML code behind the decoy template There is a server-side check prior to each visit to the page to determine if the user has already been served the fake template or not, in which case the webserver will return legitimate content instead.


Fileless execution and module installation


The infection process starts once the victim executes a malicious script inside the zip archive they just downloaded.


Figure 4: Malicious script, heavily obfuscated This script is the first of several stages that leads to the execution of the final payload.


The following diagram shows a high level overview: Figure 5: Infection flow Stage 1 – The first JavaScript The first JavaScript is the module that has to be manually executed by the victim, and it has been obfuscated in order to hide its real intentions.


The obfuscation consists of three layers where one decodes content for the next.


The first stage (a version with cleaned formatting available here) decodes the next element: Figure 6: First stage script The decoded output is a comma-separated array of JavaScript blocks: Figure 7: Decoded comma-separated array of scripts There are four elements in the array that are referenced by their indexes.


For example, the element with the index 0 means “constructor”, 1 is another block of JavaScript code, 2 is empty, 3 is a wrapper that causes a call to a supplied code.


Block 1 is responsible for reading/writing registry keys under “HKEY_CURRENT_USER\SOFTWARE\<script-specific name>”.


It also deobfuscates and runs another block of code: Figure 8: Third JavaScript layer This fragment of code is responsible for connecting to the C2.


It fetches the domains from the list, and tries them one by one.


If it gets a response, it runs it further.


The above downloader script is the first stage of the loading process.


Functionality-wise it is almost identical in all the dropped files.


The differentiation between the variants starts in the next part, which is another JavaScript fetched from the C2 server.


Stage 2 – The second JavaScript (downloaded from the C2)


The expected response from the server is a decimal string, containing a pseudorandom marker used for validation.


It needs to be removed before further processing.


The marker consists of “@[request argument]@”.


Figure 9: GET request with C2 server After conversion to ASCII, the next JavaScript is revealed, and the code is executed.


This JavaScript comes with an embedded PE payload which may be either a loader for Gootkit, or for the REvil ransomware.


There are also some differences in the algorithm used to deobfuscate it.


Example for the Gootkit variant (commented, full) Figure 10: The downloaded JavaScript The downloaded code chunk is responsible for installing the persistent elements.


It also runs a Powershell script that reads the storage, decodes it and runs it further.


Stage 3 – The stored payload and the decoding Powershell


The authors diversified the method of encoding and storing the payload.


During our tests we observed two ways of encoding.


In one of them, the PE is stored as a Base64 encoded string, and in the other as a hexadecimal string, obfuscated by having certain numbers substituted by a pattern.


The payload is usually stored as a list of registry keys, yet we also observed a variant in which similar content was written into a TXT file.


Example of the payload stored in a file: Figure 11: Payload as a file on disk The content of the file is an obfuscated Powershell script that runs another Base64 obfuscated layer that finally decodes the .NET payload.


Example of the Powershell script that runs to deobfuscate the file: "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy


Bypass -windowstyle hidden -Command "IEX (([System.IO.File]::ReadAllText('C:\Users\[username]\bkquwxd.txt')).Replace('~',''));" Below we will study two examples of the loader: One that leads to execution of the REvil ransomware, and another that leads to the execution of Gootkit.


Example 1—Loading REvil ransomware


The example below shows the variant in which a PE file was encoded as an obfuscated hexadecimal string.


In the analyzed case, the whole flow led to execution of REvil ransomware.


The sandbox analysis presenting this case is available here.


Execution of the second stage JavaScript leads to the payload being written to the registry, as a list of keys.


The content is encoded as hexadecimal, and mildly obfuscated.


Figure 12: Fragment of the payload stored in the registry, encoded as a hexadecimal string obfuscated with a pattern After writing the keys, the JavaScript deploys a PowerShell command that is responsible for decoding and running the stored content.


Figure 13: The JS component deploys PowerShell with a Base64 encoded script Decoded content of the script: Figure 14: Decoded content It reads the content from the registry keys and deobfuscates it by substituting patterns.


In the given example, the pattern “!@#” in the hexadecimal string was substituted by “1000”, then the PE was decoded and loaded with the help of .NET


Reflection.


The next stage PE file (.NET): REvil loader: (0e451125eaebac5760c2f3f24cc8112345013597fb6d1b7b1c167001b17d3f9f)


The .NET loader comes with a hardcoded string that is the next stage PE: the final malicious payload.


The Setup function called by the PowerShell script is responsible for decoding and running the next PE: Figure 15: Hardcoded string (PE) Figure 16:


Deploying the payload The loader runs to the next stage with the help of Process Hollowing – one of the classic methods of PE injection.


Figure 17: REvil ransom note Example 2 – Loading Gootkit In an other common variant, the payload is saved as Base64.


The registry keys compose a PowerShell script in the following format: $Command =[System.


Encoding]::Unicode.GetString([System.


Convert]::FromBase64String("[content]")); Invoke-Expression $Command;Start-Sleep -s 22222; Figure 18: Registry key storing payload After decoding the base64-encoded content, we get another PowerShell script: Figure 19:


More PowerShell It comes with yet another Base64-encoded piece that is further decompressed and loaded with the help of Reflection Assembly.


It is the .NET binary, similar to the previous one.


Gootkit loader:(973d0318f9d9aec575db054ac9a99d96ff34121473165b10dfba60552a8beed4)


The script calls a function “Install1” from the .NET module.


This function loads another PE, that is embedded inside as a base64 encoded buffer: Figure 20: Another buffer Figure 21: Deploying the payload This time the loader uses another method of PE injection, manual loading into the parent process.


The revealed payload is a Gootkit first stage binary: 60aef1b657e6c701f88fc1af6f56f93727a8f4af2d1001ddfa23e016258e333f.


This PE is written in Delphi.


In its resources we can find another PE (327916a876fa7541f8a1aad3c2270c2aec913bc8898273d545dc37a85ef7307f ), obfuscated by XOR with a single byte.


It is further loaded by the first one.


Loader like matryoshka dolls with a side of REvil


The threat actors behind this campaign are using a very clever loader that performs a number of steps to evade detection.


Given that the payload is stored within the registry under a randomly-named key, many security products will not be able to detect and remove it.


However, the biggest surprise here is to see this loader serve REvil ransomware in some instances.


We were able to reproduce this flow in our lab once, but most of the time we saw Gootkit.


The REvil group has very strict rules for new members who must pass the test and verify as Russian.


One thing we noticed in the REvil sample we collected is that the ransom note still points to decryptor.top instead of decryptor.cc, indicating that this could be an older sample.


Banking Trojans represent a vastly different business model than ransomware.


The latter has really flourished during the past few years and has earned criminals millions of dollars in part thanks to large ransom payments from high profile victims.


We’ve seen banking malware (i.e. Emotet) turn into loaders for ransomware where different threat actors can specialize in what they do best.


Time will tell what this return of Gootkit really means and how it might evolve. Detection and protection Malwarebytes prevents, detects and removes Gootkit and REvil via our different protection layers.


As we collect indicators of compromise we are able to block the distribution sites so that users do not download the initial loader.


Our behavior-based anti-exploit layer also blocks the malicious loader without any signatures when the JavaScript is opened via an archiving app such as WinRar or 7-Zip. Figure 22: Blocking on script execution If a system is already infected with Gootkit, Malwarebytes can remediate the infection by cleaning up the registry entries where Gootkit hides: Figure 23: Detection of payload hidden in registry Finally, we also detect and stop the REvil (Sodinokibi) ransomware: Figure 24: REvil ransomware blocked heuristically Indicators of Compromise Compromised websites downloading JavaScript loader: docs.anscommerce[.]comellsweb[.]netentrepasteles[.]supercurro.netm-uhde[.]degames.usc[.]edudoedlinger-erdbau[.]at 3rd stage JavaScript C2s: badminton-dillenburg[.]dealona[.]org[.]cyaperosaintmartin[.]com Variant 1 (Gootkit): NET loader


[973d0318f9d9aec575db054ac9a99d96ff34121473165b10dfba60552a8beed4]Delphi PE


[60aef1b657e6c701f88fc1af6f56f93727a8f4af2d1001ddfa23e016258e333f]PE stored in resources


[327916a876fa7541f8a1aad3c2270c2aec913bc8898273d545dc37a85ef7307f] Variant 2 (REvil): NET loader [0e451125eaebac5760c2f3f24cc8112345013597fb6d1b7b1c167001b17d3f9f]Delphi PE


[d0e075a9346acbeca7095df2fc5e7c28909961184078e251f737f09b8ef892b6] – the ransomwarePE stored in resources


[a7e363887e9a7cc7f8de630b12005813cb83d6e3fc3980f735df35dccf5a1341] – a helper component The post German users targeted with Gootkit banker or REvil ransomware appeared first on Malwarebytes Labs.


New IcedID variants have been found without the usual online banking fraud functionality and instead focus on installing further malware on compromised systems.

New IcedID variants shift from bank fraud to malware delivery


According to Proofpoint, these new variants have been seen used by three distinct threat actors in seven campaigns since late last year, focusing on further payload delivery, most notably ransomware.


Proofpoint has identified two new variants of the IcedID loader, namely “Lite” (first seen in November 2022) and “Forked” (first observed in February 2023), both delivering the same IcedID bot with a more narrow-focused feature set.


Removing unneeded functions on IcedID, which has been deployed in numerous malicious campaigns without many code changes since 2017, makes it stealthier and leaner, which can help the threat actors evade detection.


Separate clusters of IcedID activity (Proofpoint) New IcedID campaigns Starting in November 2022, the “Lite” variant of the IcedID loader was delivered as a second-stage payload on systems infected by the newly-returned Emotet malware.


The “Forked” version of the malware loader first appeared in February 2023, distributed directly through thousands of personalized invoice-themed phishing emails.


These messages used Microsoft OneNote attachments (.one) to execute a malicious HTA file that, in turn, runs a PowerShell command which fetches IcedID from a remote resource.


At the same time, the victim is served a decoy PDF.


Malicious OneNote attachment used in recent campaign (Proofpoint)


At the end of February, Proofpoint’s researchers observed a low-volume campaign distributing IcedID “Forked” via fake notices from the National Traffic and Motor Vehicle Safety Act and the U.S. Food and Drug Administration (FDA).


It is important to note that while some threat actors use new variants of the IcedID malware, others still choose to deploy the “Standard” variant, with one of the most recent campaigns dating March 10, 2023.


The new variants The “Forked” IcedID loader is quite similar to the “Standard” version in terms of its role, sending basic host info to the C2 and then fetching the IcedID bot.


However, “Forked” uses a different file type (COM Server) and features additional domain and string-decryption code, making the payload 12KB larger than the “Standard” version.


Domains decryption (Proofpoint) On the other hand, the “Lite” loader variant is lighter, at 20KB, and does not exfiltrate host info to the C2.


This change makes sense since it was deployed alongside Emotet, which had already profiled the breached system.


The “Forked” version of the IcedID bot is 64KB smaller than the “Standard” bot, and is basically the same malware minus the web injects system, the AiTM (adversary in the middle) functions, and the backconnect capabilities that give threat actors remote access to infected devices.


Standard and Forked bot comparison (Proofpoint) IcedID is generally used for initial access by threat actors, so developing new variants is a worrying sign, signifying a shift towards specializing the bot to payload delivery.


Proofpoint predicts that most threat actors will continue to use the “Standard” variant, but the deployment of new IcedID versions will likely grow, and more variants may pop up later in 2023.


Operation CMDStealer:

Operation CMDStealer Financially Motivated Campaign Leverages CMDBased Scripts and LOLBaS for Online Banking Theft in Portugal Peru and Mexico


Financially Motivated Campaign Leverages CMD-Based Scripts and LOLBaS for Online Banking Theft in Portugal, Peru, and Mexico url: https://blogs.blackberry.com/en/2023/05/cmdstealer-targets-portugal-peru-and-mexico Operation CMDStealer:


Financially Motivated Campaign Leverages CMD-Based Scripts and LOLBaS for Online Banking Theft in Portugal, Peru, and Mexico An unknown financially motivated threat actor, very likely from Brazil, is targeting Spanish- and Portuguese-speaking victims, with the goal of stealing online banking access.


The victims are primarily in Portugal, Mexico, and Peru.


This threat actor employs tactics such as LOLBaS (Living Off the Land Binaries and Scripts), along with CMD-based scripts to carry out its malicious activities.


The campaign utilizes phishing emails in Portuguese and Spanish, and social engineering tactics to target victims.


The emails exploit commonly encountered issues, such as transit infractions and taxes, to create a sense of urgency and legitimacy in their phishing messages.


By posing as authoritative entities or government agencies, the messages are intended to deceive unsuspecting individuals and get them to disclose their online banking credentials.


Brief MITRE ATT&CK:registered: Information Tactic Technique Initial Access T1566.001 Execution T1204.002, T1059.001, T1059.003, T1047, T1059.005, T1059.007 Defense Evasion T1027, T1140 Command and Control T1001, T1105, T1132.001, T1071.001 Discovery T1069, T1082, T1087 Exfiltration T1041 Credential Access T1555.003 Persistence T1547.009 Weaponization and Technical Overview Weapons CMD files, Autolt scripts Attack Vector Phishing Network Infrastructure Malicious domains Targets Portugal, Mexico, Peru Technical Analysis Context The Latin American threat landscape primarily consists of financially-motivated malware, usually compiled into the final PE payloads.


While deploying the final payloads, BlackBerry threat researchers saw a variety of techniques, such as abusing VBE scripts, ISO images, and MSI packages.


In this case, the threat actor behind the campaign used CMD-based scripts, AutoIt scripts, and LOLBaS. LOLBaS and CMD-based scripts help threat actors avoid detection by traditional security measures.


The scripts leverage built-in Windows:registered: tools and commands, allowing the threat actor to evade endpoint protection platform (EPP) solutions, and bypass security systems.


By utilizing these techniques, they can gain unauthorized access to victims' systems, extract sensitive information, and ultimately compromise online banking accounts and payment systems.


The geographical focus of this threat actor centers on Portugal, Mexico, and Peru, where a significant number of Spanish and Portuguese speakers reside.


Their selection of countries is likely influenced by the prevalence of online banking usage in these regions, making them lucrative targets for financial fraud.


The first .CMD file set seen to use AutoIt in its execution was discovered at the end of 2021.


This suggests that the threat actor was beginning its tests, naming these files “demo” or “test,” upon decompiling the AutoIt script into a human-readable script that supports the timeline of this attack campaign.


Figure 1 – CMDStealer files with a very low detection rate on Virus Total Operation CMDStealer Attack Vector


The infection chain begins with the user receiving a phishing email.


These phishing emails are specially crafted to grab victims’ attention.


In one instance, we observed one of the emails titled “Multa de Trânsito,“ which translates from Portuguese as “traffic infraction ticket.”


Each email has an HTML attachment.


Figure 2 – Phishing email contents The email text employs scare tactics, such as evidence of a traffic violation, prompting the user to open the HTML attachment which contains some junk code and data in HEX format.


Figure 3 – "multa_de_transito_502323.html" attachment content The data blob in HEX decodes to a slightly obfuscated URL address which upon cleanup translates to: hxxps[:]//multa-ansr-pt[.]fun/?hcBViJAi9EZSc3YQwxpEwfmD7xdG0IF34EWGHj6Q. This URL resolves to: 162.0.232[.]115 IP address.


During the extensive analysis of the “.HTML” files, BlackBerry identified a large list of HEX-encoded URLs, some of which are listed here: hxxps[:]//factura61[.]click/2/?j5szsmo0bk8tOSQSMS4mmp1XtQrmbNYoCB2GBem8 hxxps[:]//factura61[.]click/2/?vzlv9CZ1gnLrNIaWBJBhJNWRCt7IVXDDwVzOQhSs hxxps[:]//sunat-pe[.]fun/?D80gaUJDUfuLG6lodTSEi7qoqciBWk5xE5w81pJO hxxps[:]//factura61[.]click/2/?CTtBmkRN8KPXVTgUn1ArCPGb5WXTXTaT7etdD7TC hxxps[:]//factura61[.]click/2/?yqJl8r7henupax3WsUvITb0PuSw5sn7HyZWGMvDv hxxps[:]//factura61[.]click/2/?GxkVBvEBTFfSDqaFr8Yjw9kyKH01xRseHoF0DNQc hxxps[:]//multa-ansr-pt[.]fun/?UFqQBhFaXulvEfeTbI38FFDKRth1r2DWKOFqUI0Y hxxps[:]//multa-ansr-pt[.]fun/?l4mm0DEhDbJPYd5qAQmwst09TDTjjvYjiG7ByCvx Opening the attached “multa_de_transito_502323.html” file triggers the embedded JavaScript and reaches out to hxxps[:]//multa-ansr-pt[.]fun/?hcBViJAi9EZSc3YQwxpEwfmD7xdG0IF34EWGHj6Q to pull down the next stage which is a compressed archive (RAR) file.


The archive file is typically titled with one of the naming schemes (a few are listed below): doc-Impuestos_<[0-9]{6}>.rar doc-Impostos_<[0-9]{6}>.rar Documento_Impostos_<[0-9]{6}>.rar Multa_<[0-9]{6}>.rar Impuestos-Documento_<[0-9]{6}>.rar BlackBerry found different campaigns geofenced to each specific country.


Threat researchers reported similar campaigns in the past targeting Mexico.


Weaponization The contents of the previously mentioned archive include a single “.CMD” file typically titled from one of the following filenames, (but there are other names): doc-Impuestos.cmd doc-Impostos.cmd Impuestos-Documento.cmd doc_Factura.cmd Documento_Impostos.cmd The “.CMD” file is large, ranging between 1.34 - 1.37MBs, and consists of two base64 encoded data blobs and code instructions for its execution.


The script is described in the SANS write-up released on 1/06/2023.


Figure 4 – Code instructions for both base64 data block execution The first base64 data blob is compiled AutoIt script and the second is AutoIt interpreter (a benign file), used to run the first file.


The purpose of the AutoIt script is to enumerate the host and download a “.VBS” file which then gets executed via the “SHELLEXECUTE”.


Next, it invokes the “_OUTRECOVERY()” function to steal Outlook data such as server, user, and password from POP3, SMPT, and IMAP registry keys.


The script is then instructed to call the “_CHROMERECOVERY()” function.


It proceeds by downloading the “sqlite3.dll” file from “hxxps[:]//www[.]autoitscript[.]com/autoit3/pkgmgr/sqlite/” which will be required later during the Chrome password theft.


All data is then sent back to the attacker's C2 via the HTTP POST method.


The C2 is constructed with the victim's enumerated data, where the values are: v1 – OS language (e.g., 1033 – English US) v2 – keyboard layout (e.g., 1033 – English US) v3 – operating system version (Windows 7,8,10,11 or unknown) v4 – is target an admin or user v5 – OS architecture (x86 or x64)


The URL then becomes: hxxp[:]//publicpressmagazine[.]com/images/swan/do/it[.]php?b1=1&v1=1033&v2=1033&v3=windows%2010&v4=admin&v5=x86 hxxp[:]//websylvania[.]com/psj/do/it[.]php?b1=1&v1=3082&v2=1034&v3=windows%207&v4=user&v5=x64 To gain persistence on the infected system, it relies on the following code: Figure 5 – Persistence in the system Notably, within the decompiled AutoIt scripts that were used to target Mexico, a list of Mexican banks was also specified.


If found, some of that data was sent back to the attacker.


Figure 6 – Financial targets in Mexico Based on the URLs of the financial targets in Mexico, the threat actor behind CMDStealer is highly interested in compromising enterprise/business accounts.


Operation CMDStealer Network Infrastructure The phishing and C2 (command and control) infrastructure are hosted on services with numerous domains associated with a single address, including fast flux services.


Such services go a long way in obfuscating NetFlow traffic analysis and infrastructure tracking.


The domains utilized also heavily use redacted “whois” information and obscure registration data.


Every stage of this stealer uses domains that have redacted information for years.


Multiple hosts were identified communicating with most of the CMD Stealer’s C2, but communications were not reliable enough to confirm threat actor ownership.


Campaigns have utilized the same URL path */do/it.php since at least 8/20/2022, making it a reasonable path to alert.


Targets This attack primarily targets victims in Portugal, Mexico, and Peru.


Also, based on the configuration used to target victims in Mexico, the threat actor is interested in online business accounts, which usually have a better cash flow.


Attribution Based on the code and language analysis, research is confident that the threat actor behind this campaign belongs to Latin America, specifically Brazil.


Conclusions Defending against LOLBaS executions requires a multi-layered strategy.


First, organizations should implement robust endpoint security solutions to detect and block suspicious behavior and unauthorized execution of LOLBaS. Additionally, organizations should enforce the principle of least privilege, such as zero trust, confirming that users have only the permissions necessary to perform their tasks, thus limiting potential impact of LOLBaS execution.


Regular security awareness training should be provided to educate employees about the risks associated with social engineering.


Continuous monitoring and auditing of system logs can also help detect and investigate any suspicious activities related to LOLBaS. APPENDIX 1 – Referential Hashes SHA256 f6e84e43323ed9d8531fa2aeeb3c181c8f84fcbe950ce6dcdd8c3fa0b02c6cc0 MD5 e64f28174f646e26199d6b7735c84195 SHA256 0a277e51598ef364d5e0006817d32487eb9c0a3c150b7169cbc0bb7348088e63 MD5 f7f602f9b7fd04b64fbafe4dbfefa066 SHA256 2d87b9b071ace9f2ebfa33c1c0c21202f39876b312e135a491bf57ba731b798c MD5 fdcc1e1e3ccf30c63660e1f75042be43 SHA256 40017793f40a192b1dfdfc960742dd539b19fee9b15213307c8319fd88eee57f MD5 e212e8d740310cc565bc89c3b7966804 SHA256 cb1d1f039c07bd03b6eb14248a897dcefdefc28ae6f523b7c6f549c3c155640b APPENDIX 2 – Applied Countermeasures Yara Rules Available on request (see below).


Suricata Rule Available on request (see below).


Disclaimer:


The private version of this report is available on request.


It includes but is not limited to the complete and contextual MITRE ATT&CK:registered: mapping, MITRE D3FEND:trade_mark: countermeasures, Attack Flow by MITRE, and other threat detection content for tooling, network traffic, complete IOCs list, and system behavior.


For more information, email BlackBerry at cti@blackberry.com.


For similar articles and news delivered straight to your inbox, subscribe to the BlackBerry Blog.


About The BlackBerry Research & Intelligence Team The BlackBerry Research & Intelligence team examines emerging and persistent threats, providing intelligence analysis for the benefit of defenders and the organizations they serve.


Conti Team One Splinter Group Resurfaces as Royal Ransomware with Callback Phishing Attacks From September to December, we detected multiple attacks from the Royal ransomware group.


In this blog entry, we discuss findings from our investigation of this ransomware and the tools that Royal ransomware actors used to carry out their attacks.


By: Ivan Nicole Chavez, Byron Gelera, Monte de Jesus, Don Ovid Ladores, Khristian Joseph Morales December 21, 2022Read time: ( words) Save to Folio Subscribe Royal ransomware may have been first observed by researchers around September 2022, but it has seasoned cybercriminals behind it: The threat actors running this ransomware — who used to be a part of Conti Team One, according to a mind map shared by Vitali Kremez — initially dubbed it Zeon ransomware, until they rebranded it to Royal ransomware.


From September to December this year, we have detected multiple attacks from Royal ransomware, with the US and Brazil being the most targeted countries (Figure 1).


This blog entry discusses in depth the findings from our investigation of samples of this new piece of ransomware, as well as the tools that Royal ransomware actors used to carry out their attacks.


Percentage of Royal ransomware attacks by country Infection Routine External reports mention that the Royal ransomware group uses callback phishing as a means of delivering their ransomware to victims (Figure 2).


These phishing attacks contain a number that leads to a service hired by the threat actors.


When contacted, they will use social engineering tactics to lure victims into installing remote access software. Figure 2.


Royal ransomware’s attack flow Installation Our investigation found that the ransomware actors used a compiled remote desktop malware, which was used to drop the tools they needed to infiltrate the victim’s system: they used QakBot and Cobalt Strike for lateral movement, while NetScan was used to look for any remote systems connected to the network.


Once they infiltrated the system, the ransomware actors used tools such as PCHunter, PowerTool, GMER, and Process Hacker to disable any security-related services running in the system.


They then exfiltrate the victim’s data via the RClone tool.


We also observed an instance in which they used AdFind to look for active directories, then executed RDPEnable on the infected machine.


Payload Once everything has been set up, the ransomware actors used PsEXEC to execute the malware.


The PsEXEC commands contain the ID of the victim, along with any argument that the actors applied to the ransomware.


There were also instances of the malware actors using PsEXEC to enable the remote desktop protocol (RDP) of a target system before executing the ransomware.


Analysis


In part of our analysis, we used a ransomware sample with the detection name Ransom.Win64.YORAL.SMYXCJCT.


As shown in Table 1, Figure 3, and Figure 4, Royal ransomware requires an argument of “-id {32-byte characters}” to execute on a victim’s machine.


It also accepts “-path” to specify a target file for encryption and “-ep {value}” to calculate the partial file encryption of large files.


In some earlier samples of the ransomware, the binary wouldn’t parse all the arguments due to a bug in the code.


For example, “-path” won't be processed if provided after the "-id" argument; if provided before, there will be no "-id" argument, so it will not proceed.


Argument Description -path {target path} If provided, will only encrypt the contents of the target path -id {32-byte characters} Will be used as the victim’s ID, which will be appended on the TOR link found in the dropped ransom note.


The process exists if not provided or if provided characters is not 32 bytes long -ep This argument is for the full or partial encryption of file routine Table 1.


Arguments accepted by the Royal ransomware binary Figure 3.


Arguments accepted by the ransomware binary Figure 4.


Checking if length of provided “-id” is 32 bytes It enumerates files and directories for encryption using FindFirstFileW, FindNextFileW, and FindClose APIs (Figure 5).


File enumeration The ransomware looks for available network shares for network encryption by listing accessible local IPs, then uses NetShareEnum and attempts to connect on ADMIN$ and IPC$ shares (Figure 6).


Looking for accessible local IPs then trying to connect to ADMIN$ and IPC$ It checks for the number of processors in the infected system and uses it as a base for the concurrent running threads for file encryption, as shown in Figure 7.


By doing so, Royal ransomware significantly increases the speed of its file encryption process.