Labeling endpoint actions with Logstash – Threat Hunting

There’s been plenty of instances where I have to go through an investigation after a user has clicked on a phishing email and find out what happened later. After performing this task multiple times I realized that it would be easier to label the actions the user took and create a dashboard that would indicate such events.

A typical example is a user opening a .pdf file with an embedded link, which either contains a phishing site, or might download a word document with a macro. This approach allows the attacker to bypass any type of sandboxing that would detect the macro behavior and reject the email along with the attachment. Once the user downloads, launches the word document, and enables the macro, typically an action will take place. Traditionally this might be Powershell spawning and downloading an additional payload from the internet and the rest is up to your imagination (ransomware, bitcoin miner, RAT, etc).

This is how the endpoint would log such actions:

  1. Outlook opened a .pdf document which launched Adobe Reader, or perhaps they clicked on a link within the email; therefore, Outlook launched Internet Explorer instead.
  2. Adobe Reader (.PDF Document) launched Internet Explorer (or your default web-browser)
  3. Internet Explorer downloaded a Word Document (.doc, .docm)
  4. Word Document spawned Powershell.exe
  5. Powershell.exe ran silently with commands such as (-nop, EncodedCommand, -NonInteractive, downloadstring, etc.. etc..)

Therefore, I wanted to display these actions in plain English to the Analyst reviewing these logs, it makes it much easier to identify abnormal behavior (such as Word.exe launching Powershell.exe)

Here’s how the proposed idea looks like:

This allowed me to know exactly what actions took place in an endpoint rather than having to look at raw logs and apply different filters to get what I wanted to see in the first place. The screenshot below shows the action for “File Created from Web Browser” which relates to Sysmon EventId 15.

This allowed me to easily Identify the file being downloaded and how it got downloaded.

Additionally, I created another filter that labels the file extension based on the file type, this way I can always filter on the file type and see actions related to such file. This helps identify files such as .exe, .hta, .js, etc.. that might stand out and trigger an investigation.

Looking for abnormal behavior

Once you label your use cases, it is easier to identify abnormal behavior and allows us to react faster rather than relying on our endpoint security product to detect a file hash, or malicious IP addresses. Focus on endpoint behavior! If your Word Document opens anything else besides a (.doc,docx,.docm) ensure that you are alerting on such actions. Understand your business applications and take appropriate actions when the attacker manipulates those applications outside of their intended scope.

Logstash Configuration Files

Below are two logstash configurations used.

Configuration 1 – Endpoint Actions

This configuration relies on Sysmon Event ID 1, and 15 which typically contain the source process and destination file which is typically involved in the scenario explained earlier. You can always make it look neater by combining the events with an “or” statement within the Logstash configuration, or create a pattern within the pattern directory to make it cleaner. I’m including basic actions such as web browsers launching executable files, Outlook launching web browsers, etc.. to provide me with a narrative once such actions occur.

Configuration 2 – File Extensions

This configuration is based on a regex pattern to match file extension and adds a field name for those file extension.

Conclusion

As mentioned earlier, focus on Behavior! as this will allow you to see what’s abnormal and rely on your own intelligence rather than an outdated definition from your [insert vendor name here] endpoint solution. Lastly, I called these IOCs which might be misleading, it’s just what I felt like calling it; however, you’re entitled to your own descriptions.

The next article I will include email alerts on abnormal behavior that allows you to react on unexpected endpoint actions.

Thanks for reading.

Special thanks to Mr. Pietri for pointing out a regex correction in my configuration.

 

 

Leave a Reply

Be the First to Comment!

avatar
  Subscribe  
Notify of