Showing posts with label WLS. Show all posts
Showing posts with label WLS. Show all posts

Wednesday, October 21, 2015

Automating Forensic Artifact Collection with Splunk and GRR


Recently I had the need for GRR to collect forensic artifacts when a Splunk alert was triggered. The point of this is to collect the forensics data when a incident ticket is generated to save IR staff time and eliminate redundant redundant tasks.

Example Scenario
When a pre-defined malicious event is seen, Splunk will send an email with event details to the ticketing system and IR folks will investigate. One of the first step in the example below is to acquire the files in question with GRR. To save time we will want to automate the collection of evidence.

AV does a horrible job of detecting malicious scripts like JS.Proslikefan.B (and anything malicious in general). However, with the help of WLS this is simple to detect and alert on. Splunk search:
`wlslogs` (EventID=4688 OR EventID=592) InternalName=wscript.exe BaseFileName!=wscript.exe
To briefly explain this alert, JS.Proslikefan maintains persistent by executing a 'random filename.lnk' file in the startup folder. The LNK file executes a randomly named copy of 'wscript.exe' in the appdata folder along with the malicious script. When a person logs on to an infected machine it would generate a WLS event like this (snippet):

BaseFileName="udpbat.exe" InternalName="wscript.exe" CommandLine="C:\Users\tupac\AppData\Roaming\avseda\udpbat.exe  C:\Users\tupac\AppData\Roaming\avseda\vnyqxluw.js"

Process Overview 
1. Splunk alert finds execution of 'wscript.exe' when BaseFileName is not 'wscript.exe'.
2. Splunk alert launches 'wrapper.py' which then launches 'grrRemoteGetFile.py'. 
3. 'grrRemoteGetFile.py' sends GRR an API request to acquire files in question.
4. Profit.


Splunk uses its own python version which doesn't have modules like 'requests'. Rather than installing modules into Splunk's python, we can just use a wrapper which will use the system default version of python. 

Creating the Splunk Alert
Run the search and when you're satisfied your search has minimal false positives, save it as an Alert.
When going through the alert wizard check the 'enable' box under Run a script and enter wrapper.py


wrapper.py (Mashed together from a few examples on the Splunk forums):
 #!/usr/bin/python   
 import gzip, os, sys, csv   
 from subprocess import call   
   
 python_executable = "/usr/bin/python"   
 real_script = "/opt/splunk/bin/scripts/grrRemoteGetFile.py"   
   
 for envvar in ("PYTHONPATH", "LD_LIBRARY_PATH"):   
  if envvar in os.environ:   
   del os.environ[envvar]   
   
 def openany(p):   
  if p.endswith(".gz"):   
   return gzip.open(p)   
  else:   
   return open(p)   
   
 results_file = sys.argv[8]  
   
 for row in csv.DictReader(openany(results_file)):   
  my_command = [ python_executable, real_script, row["host"], ]   
  call(my_command)   

The wrapper script does the following: 
  • Remove environment path and LD_LIBRARY_PATH
  • Opens the splunk search results (unzip's and reads csv for host value) .
  • Execute 'grrRemoteGetFile.py' with the systems default python along with the hostname that triggered the alert.

Splunk will pass 9 variables to the script when it executes. Variable 8 contains the path to the gzip'd search results in csv format. The other variables are documented here.


grrRemoteGetFile.py 
 #!/usr/bin/python    
 import sys, json, urllib2, base64, requests   
 from requests.auth import HTTPBasicAuth   
   
 hostname = sys.argv[2]  
   
 grrserver = 'https://grrserver:8000'   
 username = 'Tupac'   
 password = 'isAlive'   
   
 base64string = base64.encodestring('%s:%s' % (username, password)).replace('\n', '')   
 authheader = "Basic %s" % base64string   
   
 index_response = requests.get(grrserver, auth=HTTPBasicAuth(username, password))   
 csrf_token = index_response.cookies.get("csrftoken")   
   
 headers = {   
  "Authorization": authheader,   
  "x-csrftoken": csrf_token,   
  "x-requested-with": "XMLHttpRequest"   
  }   
   
 data = {   
  "hostname": hostname,   
  "paths": ["%%users.appdata%%\Roaming\*\*.{js,exe}",   
            "%%users.appdata%%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\*.lnk"],    
  "pathtype": "OS"    
  }   
   
 response = requests.post(grrserver + "/api/clients/" + hostname + "/flows/remotegetfile",   
        headers=headers, data=json.dumps(data),   
        cookies=cookies, auth=HTTPBasicAuth(username, password))   


'grrRemoteGetFile.py' will start a FileFinder flow on the 'hostname' variable passed to it by the 'wrapper.py' script. When IR staff is able to review the ticket, the files will be available in GRR to download and review.

In Summary...
This is just a basic example to demonstrate how all the pieces fit together. There are some really cool things you can do with these tools to automate stuff. Some things I've been playing with:

Automatically launch Incident Response Collector ($MFT, Registry, Browser History, etc.) and full memory image when a known bad MD5 or static indicator is seen in Splunk.

Utilize WLS's hash tracking to automatically submit new binaries to internal malware analysis tools. Splunk alert would be:
`wlslogs` (EventID=4688 OR EventID=592) NewHash=True
In the wrapper.py, you would add row["NewProcessName"] and pass it to grrRemoteGetFile.py to download (instead of the static path in the example above).

Get any executable downloaded from the internet and send it to internal malware analysis tools.
`wlslogs` (EventID=4688 OR EventID=592) Zone=3
Get any compressed file attachment opened from Outlook email and send to internal malware analysis tools.
`wlslogs` (EventID=4688 OR EventID=592) CreatorProcessName=OUTLOOK BaseFileName=winzip*

If you have any examples/suggestions on automation with GRR and WLS/Splunk, share them on the GRR user group, I'm really interested to hear what other folks have done.

Sunday, August 23, 2015

DFIR with Windows Logging Service (WLS)

WLS is logging service built with forensics and incident response in mind. The best way to explain what WLS is to show an example:

Here is what you get from a process creation event from Windows:
2014 Nov 21 21:39:28 10.10.10.10 WINTETST.domain.com MSWinEventLog 0 Security 2099 nov 21 16:39:28 2014 4688 Microsoft-Windows-Security-Auditing domain\WINTETST$ N/A Success Audit WINTETST.domain.com Process Creation A new process has been created.    Subject:   Security ID:  S-1-5-18   Account Name:  WINTETST$   Account Domain:  DOMAIN   Logon ID:  0x3e7    Process Information:   New Process ID:  0xf0c   New Process Name: C:\Windows\System32\dllhost.exe   Token Elevation Type: TokenElevationTypeLimited (3)   Creator Process ID: 0x2d4    Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy.    Type 1 is a full token with no privileges removed or groups disabled.  A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.    Type 2 is an elevated token with no privileges removed or groups disabled.  An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator.  An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.    Type 3 is a limited token with administrative privileges removed and administrative groups disabled.  The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

Here is what WLS logs:
Aug 23 12:57:57 win-1ujak6s06vk. Security: LogType="WLS", BaseFileName="notepad.exe", Channel="Security", CommandLine="'C:\Windows\system32\notepad.exe'", CompanyName="Microsoft Corporation", Computer="WIN-1UJAK6S06VK", CreatorProcessName="explorer", Entropy="6.95893575618574", EventID="4688", EventRecordID="72208", ExecutionProcessID="4", ExecutionThreadID="56", FileDescription="Notepad", FileVersion="6.1.7600.16385 (win7_rtm.090713-1255)", InternalName="Notepad", Keywords="0x8020000000000000", Language="English (United States)", Length="193536", Level="0", MD5="F2C7BB8ACC97F92E987A2D4087D021B1", NewProcessId="0x8a8", NewProcessName="C:\Windows\System32\notepad.exe", Opcode="0",ProcessId="0x8ec",ProductVersion="6.1.7600.16385",ProviderGuid="{54849625-5478-4994-A5BA-3E3B0328C30D}", ProviderName="Microsoft-Windows-Security-Auditing", SessionId="2",SESSIONNAME="Console",SHA1="7EB0139D2175739B3CCB0D1110067820BE6ABD29",Signed="Catalog",SSDeep="3072:QOrerAgXWMI6vKoTN6p0frxJLgf7nDVF6PUp1Yo3ICgx:QWDcRgNpex5gfzDVlVXg",SubjectDomainName="WIN-1UJAK6S06VK",SubjectLogonId="0x1fc0a2",SubjectUserName="testuser",SubjectUserSid="S-1-5-21-874994001-2474262622-3605836291-1008", Task="13312", TokenElevationType="TokenElevationTypeDefault (1)",ValidSignatureDate="False", Version="1", WindowStation="Winsta0\Default", Zone="0"

All the useless information is replaced with useful information. More details on WLS can be found here http://digirati82.com/. I’m writing this blogpost to share some methods for detecting malicious behavior and malware using WLS and Splunk.  



Sticky Keys Authentication Bypass
Using sticky keys to bypass authentication is a favorite since it doesn’t involve malicious binaries. This method relies on replacing sethc.exe, utilman.exe, osk.exe, magnify.exe or narrator.exe with cmd.exe in the windows\system32\ directory. Since we are capturing the file metadata on execution, detecting this malicious behavior is simple. Create a schedule Splunk job to email you when event count is >0 for this search:

index=main (EventID=4688 OR EventID=592) FileDescription="Windows Command Processor" BaseFileName!=cmd.exe

A legitimate execution of the command prompt will contain the file description of “Windows Command Processor" with the BaseFileName of “cmd.exe”


Webshell / Compromised Web Server Detection
In some web server compromises attackers will add a webshell allowing them command line access for lateral movement among other things. Since we know that the IIS service account shouldn’t normally be running ‘cmd.exe’ or commands like whoami, netstat, “net localgroup administrators pwnu /add” or even “net user guest /active:yes” we can create a splunk alert to notify us when this behavior does occur.

Here is an example WLS event snippet of a compromised IIS webserver executing the command prompt through a webshell:
BaseFileName="cmd.exe", Channel="Security", CompanyName="Microsoft Corporation", Computer="WIN-1UJAK6S06VK", CreatorProcessName="w3wp", EventID="4688", SubjectUserSid="S-1-5-82-3006700770-424185619-1745488364-794895919-40
04696415", NewProcessName="C:\Windows\System32\cmd.exe", SubjectUserName="Defaul
tAppPool"

An example Splunk search to alert on this activity:
index=main (EventID=4688 OR EventID=592) CreatorProcessName=”w3wp”
NewProcessName="C:\Windows\System32\cmd.exe"

Maybe it’s a good idea to see ALL command line activity by the IIS user:
index=main WLS_CommandMonitor User=”IIS APPPOOL\\DefaultAppPool"

In any case we know what an IIS server shouldn’t do, creating alerts on known bad behavior is a simple way to increase your odds of finding a compromised server.


Svchost.exe Injection
Some malware will start a legitimate copy of svchost.exe and inject code into it. This method used to hide on a system is easy to alert on. Since services.exe should execute svchost we can create a Splunk alert anytime svchost.exe is executed when the Creator Process Name is not services.exe. Here is a snippet of what a malicious execution would look like:

BaseFileName="svchost.exe", Channel="Security", CommandLine="'c:\Windows\System32\svchost.exe", CompanyName="Microsoft Corporation", Computer="WIN-1UJAK6S06VK", CreatorProcessName="mspswls.tmp",  EventID="4688",

Our Splunk search to alert on this behavior would look like this:
index=main (EventID=4688 OR EventID=592) BaseFileName=svchost.exe CreatorProcessName!=”services.exe”

Alerting on Attacker Behavior
Some attackers follow a pattern after gaining access; gather system information, escalate privileges, lateral movement, persistence, collect & exfil data.  Their tools are constantly changing to evade detection but their behaviors and the tools behaviors don’t evolve so quickly. A great example is the staging of data for exfil. Attackers will sometime use a custom version of rar to password protect a file, in several version found on Virustotal they all use the standard command flags of ‘a -ph’ to create an archive and to password protect the data.
SomeExecutable.exe a -hpSomePassword RandomFlename RandomFilePath

Based on this we can add a scheduled search in Splunk for the following:
index=main WLS_CommandMonitor Command=”*a -hp*”

Example WLS CommandMonitor Log
Aug 23 13:39:09 win-1ujak6s06vk. WLS_CommandMonitor: LogType="WLS",
Command="a.exe a -hpqwerty123 data1.rar supersecret.doc", ProcessId="0x11c", ProcessName="cmd", Type="Added", User="WIN-1UJAK6S06VK\testuser", WLSKey="122"

Some attackers use the “makecab.exe” for compressing data before exfil. It’s on all windows systems and not many people use it so alerting on its execution might be a good idea.

Other APT groups are also using powershell as a method for persistence as indicated by this FireEye article. Using the same method above we create a scheduled Splunk search on the “-enc” parameter passed to powershell.

"C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe –NonInteractive –enc SQBuAHYAbwBrAGUALQBDAG8AbQBtAGEAbgBkACAALQBDAG8AbQBwAHUAdABl..."

Example Splunk alert
index=main WLS_CommandMonitor Command=”powershell –NonInteractive –enc *”

The other popular method of persistence is by scheduling “at” jobs. Since this data is logged and not too many people use this, results should be low:
index=main WLS_CommandMonitor: LogType="WLS", Command="at *”

Or you could alert on the execution of “at.exe”:
index=main (EventID=4688 OR EventID=592) BaseFileName=”at.exe”


Malicious Microsoft Office Documents
Word documents embedded with malicious macros to download & execute malware is still common. WLS logs the creator process name so it’s pretty simple to search for any event where Microsoft Word creates a new process:

index=main (EventID=4688 OR EventID=592) CreatorProcessName=WINWORD

For Excel, Powerpoint or Access you would just substitute the appropriate “CreatorProcessName”.


Entropy
In many cases attackers use packed binaries which result in high entropy. While this is not a candidate for an alert it can certainly be used for malware hunting. An example from WLS event would report it as Entropy="4.61108706992542". In splunk you could search for unsigned binaries executed with entropy greater than 7:
index=main (EventID=4688 OR EventID=592) Signed=False Entropy>=7




I will be updating this post with additional searches when time allows. Hopefully this information is helpful, if you have any questions or comments hit me up on twitter.