If you landed here without reading the first blog post of the series, perhaps it’s a good idea to check it out before proceeding, otherwise, happy reading!
Next question, please!
Using Splunk’s event order functions, what is the first seen signature ID of the coin miner threat according to Frothly’s Symantec Endpoint Protection (SEP) data?Q212, 100 points
First we need to locate the Symantec events which is easily done by listing sourcetypes containing traces of Symantec or SEP (Endpoint Protection) related data:
Next, assuming the signature info is following the CIM, Splunk’s suggested normalization standard, we query against those sourcetypes for the first occurrence of either signature or signature_id fields – following the event order (not the time or chronological order):
The stats first() function returns the field from the first event seen. That differs from other stats functions such as earliest() which considers _time and returns the field from first event seen from a time sorted list of events.
Note that I simply assumed strings “coin”or “mine” would be present in the signature value. Also, signature_id is missing. And that’s what the question is about, the ID of the signature.
Obvious next move is to check the events matching that signature a bit closer:
index=botsv3 earliest=0 sourcetype=symantec:* signature="Web Attack: JSCoinminer Download 8"
Turns out it’s part of sourcetype = “symantec:ep:security:file”, here’s a sample raw event:
And there it is! Answer is 30358 from SID or Signature ID value.
What is the short hostname of the only Frothly endpoint to show evidence of defeating the cryptocurrency threat? (Example: ahamilton instead of ahamilton.mycompany.com)Q214, 100 points
That one was a gift? From the last raw event screenshot above, we can see the action field value = “blocked”, meaning the threat was somehow defeated. Below is the expanded view on the event where we can spot the hostname of the affected endpoint:
What is the full user agent string that uploaded the malicious link file to OneDrive?Q300, 100 points
That’s another question we don’t need much context to quickly answer.
First, we need to assume our key strings will hit the bloom filters (speedy queries lies here); Secondly, we need to assume “onedrive” string is part of the website or internet resource used to upload the file to; and lastly, we assume link file as a file with .lnk extension, defining our last key.
Below’s the initial exploratory query looking for obvious traces and listing potential sourcetypes for further exploration:
index=botsv3 earliest=0 onedrive lnk
| stats c, latest(_raw) by index, sourcetype
So we seem to be lucky here! Only 3 sourcetypes matching the query.
Next obvious move is to look for “agent” related fields from those events. If you look closely, the first hit indicates there must be agent related information at sourcetype = “ms:o365:management”:
The following query returns multiple events from the targeted sourcetype, using the same key strings:
If we check the number of occurrences by distinct user agent strings, here’s what we get:
That means, one of those 3 values is the answer. Now, reviewing the question:
“What is the full user agent string that uploaded the malicious link file to OneDrive?”
After inspecting the previous results, we see there’s a Operation field:
What if we narrow the search down to Operation = “FileUpload”?
index=botsv3 earliest=0 sourcetype="ms:o365:management" onedrive lnk Operation=FileUploaded
Bingo! Queries yields one, single event, therefore UserAgent’s value is the answer.
Happy Splunking and until next question!