Background
Adversaries frequently utilize scheduled tasks, a legitimate Windows operating system utility to establish/maintain persistence and even execute code in a victim network.
Scheduled tasks allow for persistence on a victim network between reboots as well as code execution when a certain condition is met (time, user logon, etc.).
In this specific example, the adversary does not rely on schtasks.exe for task creation, but on a COM object that loads the Task Scheduler Service.
This means hunting or detecting anomalous use of schtasks.exe won’t provide the defender any tangible information, thus we need to discover other opportunities to find this attack technique.
To Detect or Hunt?
A recent article by Trellix details new activity moderately attributed to the DarkHotel APT group. Please give the Trellix blog a look for additional information on the full attack chain.
The purpose of this post will be to provide some detection or hunting ideas for COM Object-created scheduled tasks.
1 . Block or audit Office applications from creating executable content.
This detection opportunity likely offers the least effort to implement. The full attack chain presented above in Figure 1 courtesy of Microsft Defender for Endpoint (MDE), not only detects the scheduled task, but also a malicious VBS file.
Outright blocking Office applications from executable content may not be feasible in some environments.
Microsoft’s Attack Surface Reduction (ASR) has added a new mode, “warn” along with audit and block. This new ASR mode provides a dialog box notifying the user content was blocked, and allowing them to unblock content for 24 hours.
For additional information on ASR and the newly added mode, please visit:
2 . Image Load event logging with Sysmon
Sysmon’s Event 7, Image Loaded provides defenders visibility and the opportunity to collect events where DLLs are loaded by processes.
In this case, it is unlikely Excel.exe has a legitimate reason to load taskschd.dll. Again, depending on how your environment utilizes VBA macro documents, Sysmon and other SIEM rules may require tuning.
A Sigma rule and example Splunk query are provided below.
The above Sigma rule converts to an easy SPL one-liner:
"source=sysmon" (Image="*\\Excel.exe" OR Image="*\\Winword.exe" OR Image="*\\Powerpnt.exe") (ImageLoaded="*\\taskschd.dll"))
The malicious Excel file also loads wshom.ocx, part of the Windows Scripting Host, or wscript.exe (Figure 3).
This can be added to the above query by searching for ImageLoaded=”*\\wshom.ocx”.
3 . Scheduled Task created without schtasks.exe
The KQL query in Figure 4 represents a very basic (I’m still trying to grasp KQL), a method to discover Scheduled Tasks created without schtasks.exe.
If you look closely at the above, both Tasks are related to running the malware in my lab.
The two Tasks are labeled “MicrosoftOneDriveMgmt”, and “MicrosoftOneDriveSync”.
Again as touched on above, MDE captures and logs the command-line arguments and processes for suspicious wscript.exe use (Figure 6)
4 . Scheduled Tasks with a short shelf life
This specific case offers an opportunity to detect Scheduled Tasks created (Event ID 4698) for a short period of time. In this case, the task would be executed every five minutes for a period of one day.
As we have seen in the above images, every five minutes the Task reaches out to a C2 server. Depending on your environment, this may be a good indicator of beaconing.
Conclusion
While the above technique of utilizing an Office App to create a Scheduled Task via a COM Object is not new, I hope this post provides you with ideas to detect Tasks created without schtasks.exe.
Further Reading
In no specific order,
Cyber&Ramen 
Comments
One response to “Detecting COM Object Tasks Used by DarkHotel”
[…] Mike at Cyber&RamenDetecting COM Object Tasks by DarkHotel […]
LikeLike