Introduction
FortiGuard Global Threat Landscape Report release earlier this year highlighted a 10.7x increase in the volume of ransomware detected in customer environments in 2020. This is not surprising given the hundreds of thousands of new malware variants are detected by security vendors all over the world every day. Research highlighted that 74% of threats detected during the first quarter of 2021 were unknown malware samples or samples with no known signature.
The FortiGuard Managed Detection and Response (MDR) Team monitors customer networks all over the world through FortiEDR. Many of the events generated by FortiEDR are related to behavior associated with some of these unknown samples. The purpose of this article is to demonstrate with unknown samples taken from a customer environment how FortiEDR has effectively employed machine learning, online sandboxing and behavioral detection capabilities to mitigate some of these new samples, how you can use FortiEDR to analyze the context of ‘Unconfirmed Executable’ alerts in your environment and how to best configure FortiEDR to detect this activity.
The samples analyzed in this article were dropped as part of a larger intrusion following a successful compromise of a Microsoft Exchange 2016 server. The end state of the intrusion is the execution of a custom variant of popular Monero (cryptocurrency) mining software XMRig. The XMRig application itself is not malicious but a part of this executable is manually configured to mine cryptocurrency on behalf of a malicious actor. In the affected MDR customer environment, this resulted in up to 100% CPU usage on the targeted endpoint and degraded performance for the normal end users whilst it operated.
Analyzing Unknown Samples
To get a better understanding of the behavior detected by FortiEDR it is useful to look at what the two samples analyzed in this article are. Both the ‘service_update.exe’ and ‘FileSyncConfig.exe’ executables are unsigned .NET executables with very similar features (see Figure 1). The main functions of the executables are not obfuscated but both contain four embedded resources; DATA1, DATA2, DLL1 and DLL2. These resources are encrypted with hard coded AES keys and identical internal decryption methods that are executed on the embedded resources as the files are executed. This type of software design is rarely benign and indicates an attempt to mitigate the effectiveness of static signature based analysis.
Figure 1. View of ‘FileSyncConfig.exe’ features in dnSpy. Note the embedded resources on the left hand panel and the way the DATA1 and DATA2 resources are decrypted and executed as part of the main method.
It is important to note here that at the time of detection both analyzed files and the embedded executables they contain were entirely unknown i.e. hashes and filenames were not flagged as malicious amongst FortiGuard Labs threat intel sources or in Virus Total. Fortunately, FortiEDR cloud services employs a dynamic sandbox to assist in analyzing anomalous files. Both files on file read were flagged by FortiEDR’s ‘Execution Prevention Policy’ as an ‘Unconfirmed Executable’. This can be seen in events 7 and 9 in Figure 2 below. Executables that are classified as unconfirmed contain additional fields not used by the operating system that are often present in malware to complicate execution and reduce the effectiveness of automated analysis.
Analyzing Events with FortiEDR
This event was originally detected by FortiGuard Responder team along with a customer notification about high CPU usage on some hosts within their environment. Looking at the forensics tab the event graph depicts a standard, linear process tree as shown below in Figure 2.
Figure 2. Event graph associated with ‘Unconfirmed Executable’ events caused by the ‘service_update.exe’ and ‘FileSyncConfig.exe’ executables.
The dynamic decryption of the embedded resources can be observed in the events with FortiEDR identifying the file DLL1.dll being unpacked in memory (event 9 in Figure 2) by the ‘FileSyncConfig.exe’ executable. Using the ‘Retrieve’ function available in the Forensics tab an analyst could pull a dump of the memory containing this dll for further analysis.
Figure 3. The ‘Retrieve’ function which is accessible from the Forensics tab can be used to pull memory from a collector which is useful to support analysis of file less malware.
Through the Stacks view in the Forensics tab we can see the file path, command line arguments and file hash for each file. Interestingly the metadata associated with this ‘FileSyncConfig.exe’ executable has been populated with metadata similar to that of the legitimate file of the same name. This demonstrates a clear, albeit unsuccessful attempt at masquerading as a legitimate file.
Figure 4. Metadata fields of the ‘FileSyncConfig.exe’ executable have been populated with metadata to make the file appear more legitimate. The description for the actual FileSyncConfig file should be ‘Microsoft OneDrive Configuration Application’ and the product should be ‘Microsoft OneDrive’.
Working back along the process chain we can see that the FileSyncConfig executable was called from ‘schtasks.exe’ (event 8 in Figure 2). This is a signed executable from Microsoft and is a binary used to interact with Windows Scheduled Tasks. Looking at the FortiEDR stacks view we can see the command line arguments used to execute the process. In this instance the command ‘/Run /I /TN “\Microsoft\Windows\SyncCenter\SyncConfigTask”’ was used. A quick look through the help file for the schtasks executable identifies that this command would immediately (/I switch) run (/Run) the task ‘SyncConfigTask’ (/TN <taskname>). The path to that scheduled task (\Microsoft\Windows\SyncCenter) is interesting as it is a default task path in Windows 10 that is created for Microsoft OneDrive tasks. This is a further demonstration of attempts to masquerade as a legitimate application.
Moving along the chain to event 7 in Figure 2 we can see that a ‘service_update.exe’ process (the other Unconfirmed Executable) launched the schtasks process discussed above. Moving further along, in event 6 we can see that an svchost process with command line ‘-k netsvcs -p -s Schedule’ spawned the ‘service_update.exe’ process. This command line indicates that this activity was the result of a scheduled task given that it references the ‘Schedule’ service after the ‘-s’ switch, which is the ‘Task Scheduler’ service and the reference to the ‘netsvcs’ service group which hosts this service by default.
Figure 5. Stacks view of event 6 from Figure 2 demonstrating svchost executing the ‘service_update.exe’ executable. Command line arguments indicate it is part of a scheduled task due to references to ‘Task Scheduler’ service.
In the final step of the analysis we can look at event 5 in Figure 2 through stacks view to identify the root cause of this execution. As shown in Figure 6 the source process is another svchost process however this on has the command line arguments ‘-k netsvcs -p -s gpsvc’. These command line arguments are similar to the previous svchost but has ‘gpsvc’ after the -s switch. This references the ‘Group Policy Service’ which indicates that this process chain was originally started from a group policy change pushed to the affected host.
Figure 6. Stacks view of event 5 from Figure 2 demonstrating svchost executing the previously analyzed (Figure 5) svchost hosting the ‘Task Scheduler’ service. This process references the ‘Group Policy Service’.
As outlined in the above analysis we can see that FortiEDR is an effective tool at supporting quick analysis of suspicious events and empowers system administrators to mitigate identified threats. In the context of the wider intrusion, the above activity was caused by a group policy change that was rolled out to the entire compromised network and the information gained through FortiEDR was used by the MDR team to effectively contain and remove the threat in the customers environment.
Configuring FortiEDR to detect and mitigate Unconfirmed Executables
In the case of the samples analyzed in this article, FortiEDR was set to ‘Simulation’ mode. In simulation mode events that were detected and would be mitigates are reported by mitigations are not applied. This means that the activity associated with ‘FileSyncConfig.exe’ and ‘service_update.exe’ was detected but not mitigated by FortiEDR. Figure 7-10 below demonstrate how the corresponding rules in the Execution, Exfiltration and Ransomware security policies should have their state set to ‘Enabled’ and the action set to ‘Block’ to ensure anomalous executables like this can be blocked. There are very limited legitimate reasons for a benign file to possess the characteristics that trigger these rules so it is highly recommended to enable to ‘Unconfirmed Executable’ and ‘Unconfirmed File’ rules to maximize detection capability.
Figure 7. Ensure action is set to 'Block' and state is set to 'Enabled' for the 'Unconfirmed File Detected' rule in the Execution Prevention policy(s).
Figure 8. Ensure action is set to 'Block' and state is set to 'Enabled' for the 'Unconfirmed Executable - Executable File Failed Verification Test' rule in the Exfiltration Prevention policy(s).
Figure 9. Ensure action is set to 'Block' and state is set to 'Enabled' for the 'Unconfirmed Executable - Executable File Failed Verification Test' rule in the Ransomware Prevention policy(s).
Figure 10. Change Execution, Exfiltration and Ransomware Prevention policies from 'Simulation' to 'Prevention mode. This will ensure that enabled rules are enforced.
Further information
A more complete analysis, related FortiEDR Threat Hunting queries, IOC list, TTP list and mitigation recommendations for the whole intrusion these samples were taken from can be found in the ‘New ProxyShell Post-Exploitation Activity’ Incident Analysis report which can be found here: https://www.fortinet.com/content/dam/maindam/PUBLIC/02_MARKETING/02_Collateral/incident-analysis/inc...
You can also find a collated list of other analysis articles by the FortiGuard Responder team here: https://www.fortinet.com/fortiguard/threat-and-incident-notifications .
