Goals: Crackmapexec
Goals: Crackmapexec
Zeek, Windows Security, Sysmon and PowerShell logs are available for this lab.
Goals
The learning objective of this lab is increase familiarity of doing a hands-on analysis with Splunk.
Recommended tools
Network Configuration
Splunk: 172.16.84.105
•Username: admin
•Password: eLSHunter
Tasks
Hint: Focus on Zeek logs, sourcetype "zeek_files" and sourcetype "zeek_smb_files", (specifically those with action of "SMB::FILE_OPEN"). For the most
important fields please refer to https://docs.zeek.org/en/current/
SOLUTIONS
Below, you can find solutions for each task. Remember though, that you can follow your own strategy, which may be different from the one explained in
the following lab.
index=zeek sourcetype="zeek_files" SMB | spath "rx_hosts{}" | table rx_hosts{}, tx_hosts{}, filename, md5, sha1
We can further enrich this by looking at Zeek logs with sourcetype of "zeek_smb_files", and specifically those with action of "SMB::FILE_OPEN". We then
construct the following query:
index=zeek sourcetype=zeek_smb_files action="SMB::FILE_OPEN" | table id.resp_h, id.resp_p, id.orig_h, id.orig_p, action, name
Now we can see that those files were accessed remotely. From this we can suspect that 192.168.1.32 is the victim that connects to 192.168.1.34 on port
445.
The 6 character and randomly-named filenames of shares are one of the distinguishing artefacts that is linked to CrackMapExec v4.0 and 5.0.
Task 2. Has the suspected attacker machine connected to the victim?
For this task, we'll use Zeek logs again, specifically those with sourcetype "zeek_ntlm". Simply, we will list all logs in a defined table output format with the
query:
index=zeek sourcetype=zeek_ntlm | table id.resp_h, id.resp_p, id.orig_h, id.orig_p, domainname, success, username
We can see that 192.168.1.34 has connected successfully to 192.168.1.32 with the account "Administrator" (NTLM authentication, which is often
generated by connecting remotely over SMB with plain text password or performing pass the hash).
appears that 192.168.1.34 has created multiple connections to the IPC$ share of 192.168.1.32. This is expected behavior when executing commands over
SMB on a remote machine.
index=* powershell
Once executed, among a list of matched events, we'll see this one:
If
we go forward and decode the obfuscated command, we will indeed note that this matches Empire's stager.
We could also look into PowerShell ScriptBlock logs with Event ID 4104, that will display captured PowerShell activity. A simple query and looking for
those that contain "Warning" in them already provides a wealth of potentially malicious obfuscated commands:
Task 5. Hunt for self-signed certificates
An interesting indicator of compromise is the existence of self-signed SSL certificates in your environment (of course your organization will have to adopt
using certificates signed by trusted entities for this hunting technique to have a meaning)
The below Splunk search can reveal self-signed SSL certificates or certificates with multiple empty fields. Both can be used as an alarm.
index=zeek sourcetype=zeek_ssl |table cipher, curve, client_cert_chain_fuids, client_issuer, client_subject, C, version, subject, validation_status
If you look carefully enough, you will identify that the self-signed certificate is related to the attacking host we found during the previous tasks!
KEY TAKEWAYS
1.Robust detection rules are required to perform high quality hunts
2.Combining network and host-based activity provides greater visibility into the actions performed and helps to identify adversary actions that may be
hard (or impossible) by looking at only one source.