Windows EventLog Persistence? The Windows can help us

The talk walks through three stages of a Windows red team operation: getting past restrictions, escalating privileges, and staying on the host. The speaker starts with PowerShell Constrained Language Mode, which limits what scripts can do, and shows that enabling it through an AppLocker rule or a registry setting still leaves a way around it. Running code through a custom runspace, built from a C# helper, is presented as the route past the restriction.

The second stage is privilege escalation. Recon finds an elevated installer configuration, and the speaker builds a malicious MSI from a WiX XML source that opens a new PowerShell session as a local administrator. The third stage is persistence. A new Application event log is created, with shellcode stored in hex inside its event data. A loader reads that data back and runs it through standard Windows APIs, and a scheduled task re-launches the loader on a short interval to keep a command channel open. In the live demo the chain produced an administrator session while Microsoft Defender was still enabled.

For practitioners, the main point is that these techniques chain legitimate Windows features, which makes them harder to spot. Defenders can look for newly created event logs, unusually large binary blobs in event records, scheduled tasks that launch loaders, and changes to AppLocker or constrained mode settings. During Q&A, the speaker was asked about event logs being overwritten once full; the answer was that a differently named log can be created to hold another payload.