Fileless

Fileless

DearBytesBlogFileless

vrijdag 10 augustus 2018

blog by Rik van Duijn and Leandro Velasco


It all started a couple of months ago when we realized that there was an increasing use of VBScript, Jscript, and PowerShell to drop & execute payloads. Sometimes even implemented completely in one of those scripting languages. In an effort to protect users against these attacks we were asked to research the ability to detect these threats. But what characterize these threats? In simple words, they attempt to use system utilities already installed on the target system to bypass whitelisting and anti-virus detection. These threats are often called “Fileless” or “Living off the Land”.

Threats like Dridex, Locky and GhostMiner are not fully fileless but they do use PowerShell and VBScript to either infect the system or gain persistence without being detected by the anti-virus. Looking into these threats showed us that we needed more logging information than the standard windows event logging. That is why, during the past three months, we have been designing, implementing and perfecting an open source implementation of endpoint monitoring. This has resulted in four things, this blog, a paper discussing our approach, a GitHub full of our configs and POC’s, and a presentation at the DefCon Blue Team Village. 😀

So, what is this open source endpoint monitoring thing we speak of? Well, it combines various open source projects together with free tools in order to monitor endpoint activity. Some of the open source software we use include:

Sysmon: this free tool allows the logging and filtering of various system events. Several people have been doing great work configuring this tool to detect different threats. (@SwiftOnSecurity, @olafhartong)

Elastic Stack: if you want to parse and search through a lot of data, you want something like Elastic. Its highly scalable nature and full-text search capabilities makes Elastic ideal for our solution.

ElastAlert: we don’t want to look at Kibana the entire time, might be nice to get a heads up. That is why we used this simple and flexible framework to alert when anomalies, spikes, or other patterns of interest are detected in an Elasticsearch instance.

Sigma: gives us a standardized rule format which allows us to describe queries. These can later be exported to various backend suchs as Splunk, ArcSight or ElastAlert. In addition, there has been a great community effort to create signatures that detect a multitude of attacks. Some based on Mitre ATT&CK.

Red Team Automation: we were changing a lot without knowing if our detections broke. The tool gives us the ability to perform unit tests.

Combining it all gives us something like:

We are combining Sysmon and PowerShell script block logging in a central location where most system activity can be monitored. It turns out that having such high visibility into what your endpoints are doing can be a whole lot of fun. We have been building some Sigma rules in order to discover the extent of everything being logged. It is also good practice, however writing rules with low false positives can be difficult. The following rules are examples of some of the rules we have implemented or optimized:

  • Office applications spawning specific binaries (PowerShell, cscript, regsrv32, rundll32 etc)
  • Windows utilities being run as SYSTEM (for example whoami or nslookup run as SYSTEM)
  • Detecting TrustedSec’s Unicorn.py from the command line (version specific)
  • Detecting PowerShell-based Code/DLL injection based on Script Block Logging (for example detecting any version of unicorn.py)
  • Detecting the use of SquiblyFoo
  • Detecting mining malware based on command line arguments (for example XMRig)
  • Detecting the creation of WMI eventFilters and eventConsumers (persistence via WMI)
  • Detecting the loading of powershell DLL’s outside of powershell.exe binaries (for example p0wnedShell)
  • The execution of suspicious processes from WMI

It’s obviously not enough, in order to detect a wide range of threats we need to have more. That’s where the community effort comes in, many have contributed to the Sigma repository such as:

  • squiblytwo detections
  • Detects various anomalies in relation to regsvr32.exe
  • CMSTP UAC Bypass
  • Detects usage of bitsadmin downloading a file
  • Detects the creation of a schtask via PowerSploit Default Configuration
  • Detects a Powershell process that contains download commands in its command line string
  • Detects a Windows command line executable started from MSHTA

The most powerful use of the implementation stems from detecting specific techniques rather than specific IOCs. For example, we have implemented two rules that could detect the use of Unicorn.py. The first one is version specific, it identifies the threat by focusing on the use of specific arguments in the process tree. The second one, detects the use of memory injection techniques. This was accomplished by focusing on the use of specific Windows functions such as VirtualAlloc, memset and CreateThread. These functions could be used to inject payloads into memory. Searching and alerting for the use of them within PowerShell allows us to detect the use of the technique regardless of the tool that implements it[1].

Another use case for the open source endpoint monitoring system could be mining malware. Since the past year could be named as the year of mining malware, being able to detect and prevent this seems to be more and more important. Some malware researches have complained that most of the mining malware isn’t that advanced. This is because they are employing XMRig or XMR-Stak in some form. So, in order to detect this threat, we could look for specific connections to mining pools. This would require a comprehensive list of all mining pool IP’s and domains. Another way would be to detect the command line arguments passed to the mining binary. Looking at public samples shows various miners passing diverse arguments such as the mining pool URI and mining algorithm.

<randomname.exe> -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4AUwCvi1ySzCsVrmmMQp9BEsSDMv2sRL6bRFy5UmwkEyXwVNwRUqi3nS94kNxGbVNn6Yg3aposmb3eWbFwGAZzvVQKmgpmX -p x -t 1

An easy way to detect miners that pass the arguments via the command line would be looking for “stratum+tcp://” and “cryptonight”. Just filtering on these arguments will allow the system to catch any non-sophisticated mining malware or mining activity by employees. Putting this into a Sigma rule would result in the following:

 

As the example above shows, there is a lot to be gained by getting more insight into what is happening on your endpoints. The fact that multiple red teamers have been investing time in stopping Sysmon, bypassing Script Block logging, and using obfuscation in PowerShell and command line arguments is a clear indication this approach is working. There are, however, some important steps to take in order to make this solution more robust. For those interested in our setup, and an in-depth view of this subject and its limitations read our paper or visit our presentation at the DefCon Blue Team Village. Many people have been committing to the Sigma project, we hope many more will follow. We will try to continue our research and hope to improve upon the current configuration and design.

For those of you who want to know more, please read our paper, and review the GitHub repository.


[1] Tricks like James Forshaw’s DotNetToJScript launching an embedded PowerShell host would be harder to detect. Once the binary is launched we would lose script block logging and any interesting command line arguments.