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:
@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}
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="">
<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"/>

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

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

Security ID: %2
Account Name: %1

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.

*** This is a Security Bloggers Network syndicated blog from trustedsignal -- blog authored by davehull. Read the original post at: