Resolving some trigger GUIDs

My last post here on triggers as a Windows persistence mechanism, see http://trustedsignal.blogspot.com/2014/02/triggers-as-windows-persistence.html, gave an example of a Windows Scheduled Task that would run a script when a specific event id appeared in the Microsoft-Windows-Security-Auditing log (i.e. the Security event log).

I added a collector for Windows Service triggers to Mal-Seine, a script for collecting host artifacts during "breach hunts," (https://github.com/davehull/Mal-Seine). Breach hunts are undertaken by security teams who proactively look for evidence of adversaries in their systems and networks, rather than merely waiting for monitoring systems to fire alerts. Breach hunt activities may lead to new detections for those monitoring systems, but I digress.

When I wrote the new collector for Service triggers, I found the collected data pretty opaque. Here's an example:

If you're wanting to analyze this data across many systems, say to identify outliers, this presentation leaves something to be desired. Mal-Seine includes a post-collection script to convert this output to separated values (https://github.com/davehull/Mal-Seine/blob/master/Convert-SvcTrigToSV.ps1) suitable for stack ranking or loading into Excel or other tools for further analysis, yielding something like the following:

Even in a separated values format, I still find the values in the "Condition" field leave something to be desired. Fortunately, some of the GUIDs can be replaced with human-readable values. Each of the entries that end with "[ETW PROVIDER UUDI]" corresponds to a Windows Event Log Provider, so we can at least get the provider name and the script above will perform this for us, if run with the -NameProviders flag, giving us:

Replacing the GUIDs makes the data a little more approachable. Searching for the remaining GUIDs online will reveal some information for the ones that are followed by information in brackets, but I've not found much on the ones that are not followed by information in brackets.

How would I use this data in a breach hunt? I would begin by stack-ranking the data from many similar systems and looking for outliers that I would mark for follow up investigation.

Triggers as a Windows persistence mechanism -- an example

@keydet89 posed the following question on Twitter:

 

 

The SANS ISC post discussing triggers as a persistence mechanism is at the following URL:

 

https://isc.sans.edu/diary/Wipe+the+drive+Stealthy+Malware+Persistence+-+Part+3/15448

 

@z4ns4tsu responded that he'd seen it and gave some information about the scenario.

 

I replied that I'd encountered it as well and that it also works for Scheduled Tasks, which is actually where I've seen it used. So technically, I guess I should have answered that I hadn't seen it, because I've yet to encounter it on Services, but the mechanism is largely the same for Scheduled Tasks.

 

@keydet89 asked if I could provide more details.

 

Twitter is not the ideal medium, so here's an example:

PS C:\> Get-ScheduledTask | ? { $_.TaskName -match "lochemoot" } | fl *

State                 : Ready
Actions               : {MSFT_TaskExecAction}
Author                : Ridley\Scott
Date                  : 2019-11-07T07:07:07.031337
Description           :
Documentation         :
Principal             : MSFT_TaskPrincipal2
SecurityDescriptor    :
Settings              : MSFT_TaskSettings3
Source                :
TaskName              : lochemoot
TaskPath              : \Microsoft\
Triggers              : {MSFT_TaskEventTrigger}
URI                   :
Version               :
PSComputerName        :
CimClass              : Root/Microsoft/Windows/TaskScheduler:MSFT_ScheduledTask
CimInstanceProperties : {Actions, Author, Date, Description...}
CimSystemProperties   : Microsoft.Management.Infrastructure.CimSystemProperties


PS C:\> Get-ScheduledTask -TaskName lochemoot | % { $_.Triggers }

Enabled            : True
EndBoundary        :
ExecutionTimeLimit :
Id                 :
Repetition         : MSFT_TaskRepetitionPattern
StartBoundary      :
Delay              :
Subscription       : <QueryList><Query Id="0" Path="Security"><Select Path="Security">*[System[EventID=4732]]</Select><Query><QueryList>
ValueQueries       :
PSComputerName     :

What does this do? This Scheduled Task is set to run a script based on the appearance of Microsoft-Windows-Security-Auditing Event Id 4732.

 

What does that event correspond to? 

PS C:\> (Get-WinEvent -ListProvider Microsoft-Windows-Security-Auditing).Events | ? { $_.Id -eq 4732 }

Id          : 4732
Version     : 0
LogLink     : System.Diagnostics.Eventing.Reader.EventLogLink
Level       : System.Diagnostics.Eventing.Reader.EventLevel
Opcode      : System.Diagnostics.Eventing.Reader.EventOpcode
Task        : System.Diagnostics.Eventing.Reader.EventTask
Keywords    : {}
Template    : <template xmlns="http://schemas.microsoft.com/win/2004/08/events">
                <data name="MemberName" inType="win:UnicodeString" outType="xs:string"/>
                <data name="MemberSid" inType="win:SID" outType="xs:string"/>
                <data name="TargetUserName" inType="win:UnicodeString" outType="xs:string"/>
                <data name="TargetDomainName" inType="win:UnicodeString" outType="xs:string"/>
                <data name="TargetSid" inType="win:SID" outType="xs:string"/>
                <data name="SubjectUserSid" inType="win:SID" outType="xs:string"/>
                <data name="SubjectUserName" inType="win:UnicodeString" outType="xs:string"/>
                <data name="SubjectDomainName" inType="win:UnicodeString" outType="xs:string"/>
                <data name="SubjectLogonId" inType="win:HexInt64" outType="win:HexInt64"/>
                <data name="PrivilegeList" inType="win:UnicodeString" outType="xs:string"/>
              </template>

Description : A member was added to a security-enabled local group.

              Subject:
                  Security ID:        %6
                  Account Name:        %7
                  Account Domain:        %8
                  Logon ID:        %9

              Member:
                  Security ID:        %2
                  Account Name:        %1

              Group:
                  Security ID:        %5
                  Group Name:        %3
                  Group Domain:        %4

              Additional Information:
                  Privileges:        %10

So we have a script that runs any time a member was added to a security-enabled local group.