Detecting browser data theft using Splunk

Detecting Browser Data theft using splunk

During my daily cyberwatch, I recently found this great article by Will Harris about browser data theft using a Windows Event Log 16385:

I decided to try implementing it in my own Splunk infrastructure and to create detection rules around it. This article will mainly discuss the Splunk aspect; if you want to know the details, I invite you to read the article linked above.

1. Splunk Universal Forwarder Configuration

On my Windows system, I started by activating the EventCode to see it in the Debug Channel using the PowerShell commands provided by Will Harris:

					$log = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Crypto-DPAPI/Debug
$log.IsEnabled = $True

Then, I prepared my Splunk logging on the UF. I placed the following configuration in the inputs.conf file of my application:

index = windows
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5
renderXml = true

2. Splunk Search Head  Configuration

I added some parsing for the relevant data I needed for my PoC in the props.conf file of my search head application.

We need the application field because we want to identify when Chrome data is being accessed, and we need the caller_process_id because we have to correlate it with the process_id from EventCode 4688 to identify the originating process. To achieve this goal, we translated the decimal caller_process_id to the hexadecimal parent_process_id.

EXTRACT-DataDescription = <Data Name='DataDescription'>(?<application>[^<]*)</Data>
EXTRACT-CallerProcessID = <Data Name='CallerProcessID'>(?<caller_process_id>\d+)</Data>
EVAL-parent_process_id = lower(printf("%x", caller_process_id))

3. Splunk Detection Rule

Then, we created a quick Splunk detection rule to identify this behavior, and we observed that it successfully triggered when we ran the Python stealer.

					index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug" application="Google Chrome" 
| bin _time span=5m 
| rename parent_process_id as process_id
| join type=inner process_id [search index=windows source=security_4688]
| table _time src_user parent_process_name process_name process_command

Now we’re pleased that we’ve detected suspicious behavior with a new EventCode. (Time difference is cause of  TZ, my infrastructure is located in FR while I’m in HK :)) This EventCode doesn’t appear to be too verbose in my lab environment, but I’m unsure of its real impact in a production environment. So, proceed carefully and test thoroughly before making any decisions.

Happy Splunking!

Laisser un commentaire