Task Scheduler: Poisoning and Tampering with Event Logs

The Windows Task Scheduler logs the creation of every task, notably through Event Log 4698 ("Task Created"), a signal many detection teams rely on to spot suspicious persistence. This research documents two distinct Defense Evasion techniques that attack the reliability of that log directly.

The first technique lets an attacker, by creating a task from an XML file, poison the "Author" field of the task's metadata with an arbitrary value, corrupting both the task metadata and Event Log 4698.

The second exploits an unbounded buffer in that same "Author" field: the injected value overwrites the entire description of the Windows Event Log entry that later processes it. Exploitation can also be triggered remotely, by patching the Author field in the XML file sent over RPC (notably via impacket-atexec).

Why it matters

An attacker who controls the content of the audit log no longer needs to delete it to obstruct an investigation: falsifying an entry, or overflowing a field until it overwrites the useful data (the executed command and its arguments), is enough to make the log unusable for an incident response team, without triggering the alerts normally tied to log deletion.

Responsible disclosure

These vulnerabilities were documented as part of security research, for educational and awareness purposes.

Full technical resource (GitHub repository)

Source: github.com/rubenformation/TaskScheduler-Logs-Tampering.

Description

Two new Defense Evasion techniques have been discovered.

The first vulnerability affects Task metadata and Event Log 4698 ("Task Created"), allowing an attacker to create a task from an XML file and poison the "Author" entry with arbitrary data.

The second vulnerability leverages an unlimited allocated buffer in the "Author" task metadata field, which is later handled by the Windows Event Log, overwriting the entire log description. The exploit can also be triggered remotely by patching the Author entry in the XML file sent over RPC via impacket-atexec.

Requirements

• Batch Logon rights on the task principal for the task to actually run (otherwise the metadata / event log is still poisoned or overwritten, but the task itself won't run).
• The password of the task principal, if the user creating the task is not an admin or doesn't hold SeImpersonate privileges.
• The security policy "Audit Other Object Access Events" enabled.

Commands

Remote

# Replace the original impacket-atexec script with the modified version, and run it with the original arguments.
# To poison the log with a fake Author entry, change the buffer in the XML file to the desired data, e.g. "Microsoft Corporation".
impacket-atexec [[domain/]username[:password]@]<targetName or address> command

Task poisoning (metadata / event log)

# Run this to check whether the INJECTED-DATA author name has been set in the task description.
schtasks /create /tn poc /xml poc-poisoning.xml /ru <username> /rp <password> /f

# Check whether the data was injected by querying the task. If the author name is INJECTED-DATA, the target is vulnerable.
schtasks /query /tn poc /xml | findstr /i author

Task event log overflow

# Run this to check whether the 3500+ byte payload was injected into Event Log 4698.
# If this log type isn't enabled on your machine and you still want to test it, enable it under:
# Local Security Policy -> Advanced Audit Policy Configuration -> System Audit Policies - Local Group Policy Object -> Object Access -> Audit Other Object Access Events -> Success
schtasks /create /tn poc /xml poc-overflow.xml /ru <username> /rp <password> /f

Log check

# Check the task log with the following PowerShell command. If the <RegistrationInfo> tag contains a 3500-byte buffer instead of the executed command and its arguments, the target is vulnerable.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4698} | Where-Object { $_.Message -like '*poc*' } | Select-Object -First 1 | Format-List TimeCreated, Message

Notes

This code is for educational and research purposes only. The author takes no responsibility for any misuse of this code.

Key takeaways

• An event log is only as trustworthy as its fields: an unvalidated metadata field (like "Author") is an attack surface in its own right.
• Detection that relies only on a log's presence, rather than its content, can be defeated without ever deleting or disabling auditing.
• Monitoring scheduled task creation is still useful, but not sufficient if the log's own content can be manipulated.

Want to assess how resilient your audit logs are against this kind of tampering? Let's talk.