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