{"id":25559,"date":"2024-12-11T09:20:54","date_gmt":"2024-12-11T17:20:54","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2024\/12\/11\/news-19288\/"},"modified":"2024-12-11T09:20:54","modified_gmt":"2024-12-11T17:20:54","slug":"news-19288","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2024\/12\/11\/news-19288\/","title":{"rendered":"Keeping it real: Sophos and the 2024 MITRE ATT&CK Evaluations: Enterprise"},"content":{"rendered":"

Credit to Author: Michael Wood| Date: Wed, 11 Dec 2024 15:35:22 +0000<\/strong><\/p>\n

\n

Each year, several security solution providers \u2013 including Sophos \u2013 sign up for MITRE\u2019s ATT&CK Evaluations: Enterprise<\/a>, a full-scale cyber attack emulation covering one or more scenarios based on real-world threat actors and their tactics, tools, and procedures.<\/p>\n

The evaluation is designed to provide a realistic (and transparent \u2013 the results are publicly available) appraisal of security solutions\u2019 performances, based on end-to-end attack chains which include initial access, persistence, lateral movement, and impact. Emulations typically include a multi-device \u2018customer\u2019 environment, complete with endpoints, servers, domain-joined devices, and Active Directory-managed users.<\/p>\n

2024 marked the fourth year of Sophos participating, and to celebrate we wanted to provide some insight into what this year\u2019s assessment entailed, and to show how true to life it actually is. In particular, we\u2019ll dive into the realism of the tooling, nuances in the testing methodology, and Sophos\u2019 protection and detection capabilities. While we can\u2019t cover everything (each scenario has 20-40 steps!), we\u2019ll discuss a selection, highlighting the depth and accuracy of the emulations.<\/p>\n

The 2024 threat categories<\/h1>\n

For the 2024 evaluation, MITRE selected two threat categories, Ransomware and the Democratic People\u2019s Republic of Korea (DPRK). The former, as has been the case for a long time, is one of the biggest cyber security threats in the industry, and continues to evolve (for example, the increase in remote encryption<\/a>). The latter is also very relevant, given the proliferation of state-sponsored espionage attacks associated with the region<\/a>.<\/p>\n

MITRE built three scenarios around these categories: an attack by a DPRK-affiliated threat actor focused on MacOS (following threat actors targeting MacOS<\/a> in several campaigns<\/a>, a trend that looks set to continue<\/a>), and attacks by affiliates of two ransomware groups (Cl0p<\/a> and LockBit<\/a>).<\/p>\n

DPRK<\/h2>\n

The DPRK scenario was simple but realistic, based on the flow of the JumpCloud supply chain compromise<\/a>: an attacker compromises a device, establishes a persistent agent, and steals credentials. Threat actors affiliated with the DPRK are known to break their attacks into discrete stages and maintain backdoors for launching future attacks<\/a>.<\/p>\n

Initial access<\/h3>\n

While the evaluation presumes a supply chain attack, the scenario itself involved a user downloading and executing a malicious Ruby script (our analysis showed a user execution path of Ruby). In a real-world supply chain attack, pre-installed software would likely automatically execute the script. Nevertheless, this is still a plausible and meaningful approach \u2013 DPRK-affiliated attackers will use social engineering to convince users to run a script, as recent incidents show<\/a>.<\/p>\n

Just as in the JumpCloud attack, MITRE\u2019s Ruby script (called start.rb<\/strong>, thematically similar to the name of the real script: init.rb<\/strong>) downloads and executes a first-stage C2 agent (a Mach-O binary), masquerading as a docker-related component. It\u2019s worth noting that reverse-engineering genuine JumpCloud samples is not possible; to our knowledge, the real-world samples are not publicly available. As with all MITRE ATT&CK Evaluations, the malware used was custom-built for the assessment.<\/p>\n

Persistence<\/h3>\n

The first-stage C2 agent then downloaded a second-stage backdoor (known as \u2018STRATOFEAR\u2019 in the real-world JumpCloud attack), which established persistence in much the same way as the genuine article, via LaunchDaemons (\/Library\/LaunchDaemons\/us.zoom.ZoomHelperTool.plist<\/strong>).<\/p>\n

\"A<\/a><\/p>\n

Figure 1: Establishing persistence via ZoomHelperTool.plist<\/strong><\/em><\/p>\n

As with the Ruby script in the Initial Access phase, MITRE designed the backdoor to closely emulate the real thing. The backdoor was dropped in the same location (\/Library\/Fonts<\/strong>), and had a very similar name (the real version was named ArialUnicode.ttf.md5<\/strong>, whereas the evaluation version was pingfang.ttf.md5<\/strong>; both \u2018Arial\u2019 and \u2018pingfang\u2019 are names of genuine fonts).<\/p>\n

As in the real JumpCloud attack, the \u2018threat actor\u2019 was stealthy and evasive, removing the first-stage implant files from the system very quickly. In the emulation, they achieved this with an rm -f <FILE><\/strong> command, as our execution path analysis showed. We don\u2019t know if this was the exact method used by the JumpCloud threat actor (it\u2019s noisier than a direct API method, since a process execution is more likely to be logged), but, as noted previously, we can\u2019t confirm this since the real-world samples are not available.<\/p>\n

Like the genuine STRATOFEAR, the MITRE backdoor used encrypted configuration files, with a shell-out openssl enc -d<\/strong> command and a hardcoded password. Again, using a direct API-based method would be stealthier, but we don\u2019t know if the JumpCloud threat actor took that approach.<\/p>\n

A quick note on test safety: For its C2 infrastructure, MITRE uses domains that work within the confines of the test environment, but are not publicly resolvable via DNS. However, they do resolve to public IP addresses. This means that the network traffic looks like genuine C2 activity, but the domains are not reachable outside the test environment.<\/p>\n

Impact<\/h3>\n

As in the JumpCloud attack, the threat actor\u2019s goal is to collect data, including system information, credentials, and sensitive information held in the Keychain<\/a>. MITRE\u2019s STRATOFEAR backdoor was faithful to the original, in that it downloaded and executed additional modules from the C2 server to carry out the theft. Like the modules downloaded by the real STRATOFEAR, these were written to a .tmp<\/strong> file in the \/tmp<\/strong> directory, each named with a string of six random alphanumeric characters.<\/p>\n

In the evaluation, MITRE\u2019s STRATOFEAR downloaded \/private\/tmp\/rhkA2f.tmp<\/strong>, a module with the ability to read MacOS keychain files.<\/p>\n

\"A<\/a><\/p>\n

Figure 2: The ExecuteModule function in MITRE\u2019s STRATOFEAR sample, using dlopen\/dlsym to call an \u2018Initialize\u2019 function<\/em><\/p>\n

This scenario ended with the backdoor collecting the data; the evaluation did not involve any actual exfiltration. While some might call this out as an issue with the methodology \u2013 credentials are often only useful if exfiltrated \u2013 we would argue that it\u2019s a minor one. If you, as an incident responder, can observe credential theft, you\u2019ll be aware of the potential impact and the associated malicious activity.<\/p>\n

Cl0p<\/h2>\n

The second scenario involved an emulation of an attack by the Cl0p ransomware group (also known as TA505<\/a>), a prolific threat actor<\/a>. Here, the flow of the attack closely mimicked \u2013 for the most part \u2013 that of a 2019 incident<\/a>, involving a downloader, a persistent RAT, sophisticated process injection, and abuse of a trusted process \u2013 ultimately leading to a ransomware payload.<\/p>\n

Initial access<\/h3>\n

While most of the scenario was faithful to the 2019 real-world campaign, the initial access stage was slightly different. As in 2019, the threat actor used a DLL to install a persistent RAT. But whereas the real-world attack involved malicious Office documents containing an embedded DLL, which was loaded dynamically into the Office process, the MITRE scenario involved a user interactively running cmd.exe<\/strong> and executing the DLL via rundll32.exe<\/strong>.<\/p>\n

This DLL was already present on the host, having been downloaded via a curl<\/strong> command from a separate interactive cmd.exe<\/strong> (this step was not included in the scenario) following initial access over RDP. It\u2019s worth noting that this method of initial access is very common amongst ransomware groups and other threats actors, particularly when purchasing stolen credentials\/access via initial access brokers<\/a> (IABs). In one very prominent case, however, Cl0p also abused a zero-day vulnerability in the MOVEit file transfer application<\/a> (CVE-2023-34362<\/a>).<\/p>\n

While it\u2019s very plausible that an attacker would gain direct remote access to the compromised host, the scenario could perhaps have included the ingress of the DLL tooling for a more complete emulation.<\/p>\n

Persistence<\/h3>\n

As in the 2019 campaign, the MITRE \u2018threat actor\u2019 loaded the persistent RAT SDBbot<\/a> by compromising the trusted winlogon.exe<\/strong> process, using Image File Execution Options (IFEO) injection<\/a> with a \u2018VerifierDLL\u2019 key<\/a>.<\/p>\n

SDBbot uses encrypted strings and a mutex to guard its start-up. As with the DPRK scenario, the MITRE sample used a similar-but-different name for the mutex (\u2018windows_7_windows_10_check_running_once_mutex<\/strong>\u2019 in the real-world attack, \u2018win10x64_check_running_once<\/strong>\u2019 for the evaluation).<\/p>\n

\"A<\/a><\/p>\n

Figure 3: Disassembly of MITRE\u2019s SDBbot sample. Note the mutex name and the decryption function<\/em><\/p>\n

In MITRE\u2019s implementation of SDBbot, the key material is a repeat of the same 16 incrementing bytes from 0 to 15. This is not as secure as a genuinely random 128-byte string \u2013 but it\u2019s sufficient to obfuscate the strings used to reference API names and data fields beyond trivial static analysis methods. MITRE used this method of string obfuscation throughout the Cl0p scenario, as well as in the LockBit scenario discussed below.<\/p>\n

MITRE\u2019s sample was loaded via a reflective loader, overwriting image memory in setupapi.dll<\/strong>. Since the RAT exists in standard \u2018image\u2019 memory, it\u2019s harder to detect than if it were in dynamically-allocated heap memory. This is a sophisticated injection method, designed to evade modern defenses. MITRE\u2019s approach presented another challenge when it came to detecting the activity of the installer (the rundll32<\/strong> process) dropping the SDBbot loader component. The installer dropped the loader to a %TEMP%<\/strong> location, but created a symbolic link to that path in the SYSTEM<\/strong> folder, and the IFEO registry key was set up to point to the SYSTEM<\/strong> folder path \u2013 thereby creating an additional layer of abstraction between the dropper and the persistent RAT.<\/p>\n

\"A<\/a><\/p>\n

Figure 4: The symbolic link for the msverload.dll<\/strong> loader<\/em><\/p>\n

The use of the \u2018VerifierDLLs\u2019 method added further complexity to the execution flow, as the loader (msverload.dll<\/strong>) was loaded into the winlogon.exe<\/strong> process space prior to the process\u2019s entry point. It then used VirtualAlloc<\/strong> to inject and execute embedded shellcode, and VirtualProtect<\/strong> to make the otherwise RX image memory of setupapi.dll<\/strong> writeable, before overwriting its contents with the SDBbot RAT. The memory permissions were later reset to RX, in order to make the code look like \u2018regular\u2019 image memory \u2013 as a DLL would appear when loaded directly from disk.<\/p>\n

\"A<\/a><\/p>\n

Figure X: MITRE\u2019s SDBbot is loaded, and overwrites the module of the otherwise legitimate setupapi.dll<\/strong> IMAGE memory, with memory protections reset to PAGE_EXECUTE_READ<\/em><\/p>\n

Our detection strategy here involved several aspects: it\u2019s suspicious to have C2 activity originating from a winlogon<\/strong> process, and C2 activity in itself is a common memory scan trigger (as we discussed in a blog on this topic<\/a> in 2023). Memory scans also detected a shellcode pattern. The suspicious C2 event enabled Sophos Detection to capture the data exfiltration behavior, and we noted that the exfiltration method \u2013 using SDBbot and sending data over the C2 channel \u2013 was adopted by Cl0p in 2020<\/a>.<\/p>\n

\"A<\/a><\/p>\n

Figure 6: Detecting exfiltration during the Cl0p scenario<\/em><\/p>\n

Impact<\/h3>\n

MITRE\u2019s implementation of the Cl0p ransomware sample (sysmonitor.exe<\/strong>, downloaded via SBDbot) was modelled very closely on a real-world sample from 2019<\/a>. Just like the real thing, MITRE\u2019s sample used GetKeyboardLayout<\/strong> to check for layouts used in Russia, Georgia, and Azerbaijan (to avoid targeting any systems using them). It also employed an identical comparison for the GetDC<\/strong>\/GetTextCharset<\/strong> APIs, used to achieve the same objective.<\/p>\n

\"A<\/a><\/p>\n

Figure 7: MITRE\u2019s Cl0p sample calling GetDC<\/strong> and GetTextCharset<\/strong> to check for infected hosts in Russia, Georgia, or Azerbaijan<\/em><\/p>\n

We also noted other near-exact matches in behavior and methodology, particularly when it came to how the ransomware dealt with shadow volumes and attempting to kill various services on compromised hosts.<\/p>\n

Many ransomware families will attempt to delete shadow volumes, to prevent their targets from restoring data, and then resize the shadow storage, so that no further shadow volumes can be created. However, the 2019 Cl0p ransomware performed the latter step in a specific way, cycling through a hardcoded list of drives (from C to H). MITRE\u2019s sample emulated this behavior exactly.<\/p>\n

\"A<\/a><\/p>\n

Figure 8: MITRE\u2019s implementation of Cl0p cycling through various drives to resize the shadow storage<\/em><\/p>\n

Moreover, like many ransomware variants, Cl0p ransomware iterates through a list of various services \u2013 including security services and services that may contain key data to be encrypted \u2013 and attempts to terminate them via net stop<\/strong>.<\/p>\n

MITRE\u2019s sample employed the same list used by the genuine Cl0p ransomware, in the same order \u2013 albeit it excluded security services, presumably to prevent any disruption to the test.<\/p>\n

\"A<\/a><\/p>\n

Figure 9: Sophos detection, showing the net stop<\/strong> commands used in MITRE\u2019s Cl0p sample<\/em><\/p>\n

For its file encryption, the MITRE malware used AES, appending a special marker (\u201cCl1pCl0p!?<\/strong>\u201d) to the data within the encrypted files. This was a similar approach to the real malware, which used a marker of \u201cClop^<\/strong> \u201d. However, whereas the 2019 samples used the advapi32.dll<\/strong> CryptAcquireContextW<\/strong> API for cryptographic algorithm support, the MITRE version employed the open-source CryptoPP<\/a> library \u2013 a more modern approach<\/a> used by many ransomware families today.<\/p>\n

LockBit<\/h2>\n

LockBit, like Cl0p, is a prolific ransomware group, albeit one significantly disrupted by law enforcement agencies<\/a> in February 2024. Nevertheless, due to a LockBit builder leaked in 2022<\/a>, threat actors continue to deploy its ransomware<\/a>. MITRE\u2019s LockBit scenario included TTPs known to be used by some LockBit affiliates<\/a> (as with the Cl0p scenario, it\u2019s worth noting that while the behavior of ransomware binaries will generally be consistent across attacks, since these are developed and distributed centrally, affiliates may have more flexibility in their approaches, and so their playbooks \u2013 and subsequent TTPs and IOCs \u2013 may differ). These TTPS included the initial access method, the use of ThunderShell and PsExec, and various evasion strategies.<\/p>\n

Initial access<\/h3>\n

The MITRE \u2018threat actor\u2019 began their attack by authenticating over an externally-facing TightVNC service (a legitimate remote administration tool), using credentials that had previously been compromised. Ransomware-as-a-Service (RaaS) affiliates commonly obtain initial access in this way, using previously-compromised services and credentials that are sold on cybercrime forums<\/a> by IABS, as noted earlier with the Cl0p scenario.<\/p>\n

Once the attacker gained access, they executed various discovery commands, which aligned with commands that we often observe early on in a RaaS attack, including:<\/p>\n

nltest \/dclist:<domain>  cmdkey \/list  net group \u201cDomain Admins\u201d \/domain  net group \u201cEnterprise Admins\u201d \/domain  net localgroup Administrators \/domain  powershell \/c \"get-wmiobject Win32_Service |where-object { $_.PathName -notmatch \"C:Windows\" -and $_.State -eq \"Running\"} | select-object name, displayname, state, pathname<\/pre>\n
These commands are almost identical to those observed during a 2022 LockBit attack<\/a>.<\/p>\n
The execution of cmd.exe<\/strong> during a remote interactive session was a key indicator of attack here, as was a TightVNC connection and remote interactive logon from a suspicious IP address.<\/p>\n
\"A<\/a><\/p>\n
Figure 10: Investigating suspicious activity during the initial access stage<\/em><\/p>\n
Persistence<\/h3>\n
To maintain a foothold in the environment, the threat actor then deployed a PowerShell remote access shell known as ThunderShell. As CISA notes<\/a>, this is a tool known to be used by LockBit affiliates, enabling them to maintain persistence if the initial access method is lost. Here, we were able to monitor recurring network connections to identify \u2018beaconing\u2019 behavior, and flag processes and connections deemed suspicious.<\/p>\n
The MITRE \u2018attacker\u2019 established further persistence through the winlogon<\/strong> automatic logon registry key. This action did deviate slightly from what we would expect in a real-world scenario; in our experience, threat actors typically enumerate those keys to potentially identify plaintext credentials.<\/p>\n
Impact<\/h3>\n
MITRE opted to emulate the bespoke LockBit exfiltration tool StealBit<\/a>, which RaaS affiliates use to perform double extortion (a technique used by many other ransomware groups<\/a>) \u2013 allowing them to exfiltrate sensitive data to a remote server before it is encrypted.<\/p>\n
MITRE\u2019s version of StealBit (named connhost.exe<\/strong>), just like the real thing, used a PEB \u201cBeingDebugged\u201d flag to check for attached debuggers, and also performed dynamic API resolution using LoadLibraryExA<\/strong> and GetProcAddress<\/strong> \u2013 with resolved DLLs stored as XOR-obfuscated filenames. This is a very similar approach to the real StealBit malware.<\/p>\n
After exfiltration, the MITRE \u2018threat actor\u2019 deployed an emulated version of the main LockBit executable to encrypt data and self-replicate across the environment.<\/p>\n
As with the real-world version, MITRE\u2019s LockBit sample used several evasive techniques, including dynamic API resolution using an in-memory API hashing algorithm (to keep API names hidden from static analysis), and anti-debugging via NtSetInformationThread<\/strong>. We documented both of these methods in our analysis of LockBit 3.0<\/a> in 2022, although it\u2019s worth noting that MITRE\u2019s implementation used DJB2 hashing<\/a>. This differs from the original LockBit approach (a custom implementation<\/a> using a ROR-based hashing method with a seed key), but the end result is the same, while also preventing the introduction of a known IOC which we and other vendors may have previously detected.<\/p>\n
\"A<\/a><\/p>\n
Figure 11: MITRE\u2019s version of LockBit used an implementation of the DJB2 hashing algorithm. This was a complex implementation, and we noted that MITRE seemed to have gone to great lengths to replicate the functionality of the genuine LockBit binary<\/em><\/p>\n
Sophos detected this activity using CryptoGuard<\/a>, although we should note that as this particular test was running in monitor-only mode, CryptoGuard did not roll back the encryption. In another, separate test, focused on protections, encryption activity resulted in the encrypted files being rolled back to their original state, even during remote encryption<\/a> emulations.<\/p>\n
\"A<\/a><\/p>\n
Figure 12: CryptoGuard thumbprint information showing the detection of ransomware activity and the creation of a ransom note<\/em><\/p>\n
Conclusion<\/h1>\n
2024 marked the fourth year that Sophos has participated in MITRE\u2019s ATT&CK Evaluations: Enterprise. As in previous years, the focus on end-to-end attack chains and realism has made the evaluation an extremely worthwhile exercise in assessing our capabilities and those of other vendors. We also welcome MITRE\u2019s emphasis on transparency.<\/p>\n
Like any kind of emulation, much of the value of these evaluations comes from how accurate and realistic their scenarios are. While we did note that MITRE\u2019s tests deviated from real-world attacks in a few, minor instances \u2013 often due to unavoidable constraints \u2013 the overall resemblance to known campaigns and threat actors was very strong.<\/p>\n
Transparent, realistic evaluations, in which multiple vendors participate, benefit not only vendors themselves, but also customers, and, as a result, wider society. We look forward to continuing to participate in these evaluations in the future, and to reporting our thoughts and findings wherever possible.<\/p>\n<\/p><\/div>\n
http:\/\/feeds.feedburner.com\/sophos\/dgdY<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/p>\n
Credit to Author: Michael Wood| Date: Wed, 11 Dec 2024 15:35:22 +0000<\/strong><\/p>\n
Sophos X-Ops looks at the realism of this year\u2019s MITRE ATT&CK Evaluations<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10378,10377],"tags":[129,20346,25567,3765,27030,16771],"class_list":["post-25559","post","type-post","status-publish","format-standard","hentry","category-security","category-sophos","tag-featured","tag-mitre","tag-mitre-attck","tag-ransomware","tag-sophos-x-ops","tag-threat-research"],"_links":{"self":[{"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/25559","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=25559"}],"version-history":[{"count":0,"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/25559\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=25559"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=25559"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=25559"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}