Endpoint Attacks & Detections

WMI Subscription Event

The Attack Simulation

for this simulation I will be using Managed Object Format (MOF) and mofcomp.exe to compile it but there are so many other ways to do this as well.

MOF file content:

#pragma namespace ("\\.\root\subscription") instance of __EventFilter as $Filter { Name = "Process Start Test Filter"; EventNamespace = "root\cimv2"; Query = "SELECT * FROM __InstanceCreationEvent WITHIN 2 WHERE TargetInstance ISA "Win32_Process""; QueryLanguage = "WQL"; }; instance of CommandLineEventConsumer as $Consumer { Name = "Process Start Test Consumer"; CommandLineTemplate = "C:\Windows\System32\cmd.exe /c echo testing the mof file>> C:\Windows\Temp\ test.txt"; }; instance of __FilterToConsumerBinding { Filter = $Filter; Consumer = $Consumer; };

in this file you can put any conditions you want under __EventFilter and any command you want to run under CommandLineEventConsumer, but you do not have to use these conditions or even classes for this test I just went with this logic "when any windows process runs create the test.txt file in C\Windows\Temp dir containing testing the mof file".

_for this attack you need Admin privileges. _

then I started cmd as admin and compiled the file using mofcomp.exe

then after running a windows process like notepad.exe the command is executed and creates the file.

---

DSJ Detections

some custom findings the actual searches are in the app local/savedsearches.conf

1. Suspicious WMI Event Content

usage of shells/suspicious classes/objects in the wmi event

2. spicious WMI Namespace

root\subscription is mostly used for permanent WMI event subscriptions, root\cimv2 used in most tutorials\tests

3. Suspicious MOF Compilation via mofcomp.exe

granted this is like Windows MOF Event Triggered Execution via WMI but this covers much more and still no noise

4. Unusual Process with MOF File Activity

my file system logging and datamodels are not in perfect conditions right now but this is the log that would be matched

5. *bonus WMI SCM Consumer Masquerading

index=windows 'wmi' EventCode=5861 | xmlkv | fillnull value="-" | stats min(_time) as firstTime max(_time) as lastTime count by host CONSUMER Namespace ESS PossibleCause | search (CONSUMER = "NTEventLogEventConsumer=\"SCM Event Log Consumer\"" OR ESS = "SCM Event Log Filter" OR PossibleCause = "*Name = \"SCM Event Log Consumer\"*") NOT (PossibleCause = "*instance of NTEventLogEventConsumer*" , PossibleCause = "*instance of NTEventLogEventConsumer*")

---

Splunk Detections

these are some of the ESCU 6.1.0 findings that was related to this attack specifically.

1. ESCU - Detect WMI Event Subscription Persistence - Rule

caught the attack using Sysmon EventCode 20 (a wmi event consumer is registered), no noise

2. ESCU - WMI Permanent Event Subscription - Sysmon - Rule

caught the attack using Sysmon EventCode 21 (The consumer is associated/bound to the filter), no noise

3. ESCU - Windows MOF Event Triggered Execution via WMI – Rule

caught the attack using Process creation "mofcomp.exe spawned by cmd.exe or powershell.exe or process of mofcomp compiling from suspicious user writable locations.", no noise

4. ESCU - Process Execution via WMI - Rule

caught the attack using Process creation "execution of a process by WmiPrvSE.exe", low noise but as you can see it creates a log each time the event happens so if you don't have throttling on it might fill up your mission control.

now these ones use a regex that does not match with XML data it matches with plain text (input.conf => renderxml=0), also they were very noisy when they matched and the Splunk site itself is not happy about it which you can see in the detection setting part, so keep that in mind.

5. ESCU - WMI Permanent Event Subscription - Rule

bassically matches with every wmi event of 5861 with the word binding in it which is a given, can be affective in lab environment not in the real world.

6. ESCU - WMI Temporary Event Subscription - Rule

bassically matches with every wmi event of 5860 with the word Temporary in it which is a given, can be affective in lab environment not in the real world.

COM abuse

this will be three section each section with different attacks and detections (1.Persistence — COM Hijacking T1546.015, 2.Execution — LOLBin T1218.010, 3.DCOM abuse). some may have overlapping detections. but they most need the same log sources to detect registry changes and process creation logs(either from windows or sysmon preferably in datamodel Registry and Process )

COM scriptlet The Attack Simulation

for this simulation I used sciptlet file to create a COM component.you can execute anything you want in it I just used it to create a file with a timestamp in it.

then we register InprocServer32 (in HKCU\Software\Classes\CLSID) a GUID pointing to scrobj.dll

then we register ScriptletURL as a subkey with a full path to our scriptlet file (it's worth noting that if the .sct file is deleted or moved this COM will become orphaned and will no longer work)

then you need to trigger it in a real world example it would be something more sophisticated like a scheduled task but I did it manually.

---

Splunk Detections

these are some of the ESCU 6.6.0 findings that was related to this attack specifically(I did not use the ones that have been removed).

1. ESCU - Detect Regsvr32 Application Control Bypass - Rule

2. ESCU - Windows COM Hijacking InprocServer32 Modification - Rule

3.ESCU - Windows New InProcServer32 Added - Rule

!! this rule did not match on it's own because it looked for "\InProcServer32\" while the registry that we added the subkey ended with "\InProcServer32"

bonus. ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule

this command was not part of the necessary operation it was kind of a sanity check but still it did catch it.

---

DSJ Detections

also to evade the ESCU rules I did one version where I used a .reg file instead of the command lines.

the scriptlet was the same and I just r-clicked it and merged it, no commandlines involved that used inprocserver32 or scrobj.