Event IDs 7045 and 4698: Spotting Persistence on Windows 11

Why These Two Events

Anything that wants to survive a reboot on Windows has to register itself somewhere the operating system checks at startup. There are dozens of such locations, but two account for the large majority of what you actually encounter: a Windows service and a scheduled task.

Both are logged by default. That is unusual and worth exploiting — most persistence locations require you to have enabled auditing in advance.

• Event 7045, System log — a new service was installed.
• Event 4698, Security log — a scheduled task was registered.

Event 7045: A Service Was Installed

Source Service Control Manager, System log. Written whenever a service is created, and it is on by default with no configuration required.

Fields:

• Service Name — the internal name
• Service File Name — the full command line, which is the field that matters
• Service Type — user mode service, or kernel mode driver for a driver
• Service Start Type — auto start means it runs at every boot

Step 1: Pull every 7045 and read the command lines

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Select-Object TimeCreated, @{n='Msg';e={$_.Message}} |
  Format-List

Read the Service File Name on each. What draws attention:

• A binary in C:\Users\, AppData, Temp, or ProgramData — legitimate services live in Program Files or System32
• powershell.exe, cmd.exe, rundll32.exe or mshta.exe as the service binary, usually with an encoded argument
• A random or machine-generated service name
• kernel mode driver — a new driver is a much higher bar than a user-mode service and deserves immediate attention

Step 2: Establish the baseline before you judge

Every software install creates services. A clean Windows 11 machine plus normal applications generates a steady stream of 7045 events, all legitimate.

The question is never "is there a 7045" — it is "is this 7045 explained". Sort chronologically and match each against something you can account for: a software install, an update, a driver. What remains unexplained is the list to investigate.

Event 4698: A Scheduled Task Was Registered

Security log. Unlike 7045, this one requires audit policy to be enabled, and on a default Windows 11 install it is not.

Step 3: Turn it on — it is off by default

auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enable

Confirm:

auditpol /get /subcategory:"Other Object Access Events"

This is a machine you administer going forward. On a machine you inherited, expect these events to be absent and use the alternative sources in Step 5.

The related IDs:

| ID | Meaning | |---|---| | 4698 | Task created | | 4699 | Task deleted | | 4700 | Task enabled | | 4701 | Task disabled | | 4702 | Task updated |

4702 matters as much as 4698. Modifying an existing legitimate task to point at a different binary is quieter than creating a new one, and it is a technique that shows up regularly.

Step 4: Read the task XML inside the event

Event 4698 embeds the task's full XML definition. The elements to read:

• <Command> and <Arguments> — what actually runs
• <Triggers> — <BootTrigger> and <LogonTrigger> are the persistence-relevant ones
• <Principal> — <UserId>S-1-5-18</UserId> means SYSTEM, which is the highest-value outcome for an attacker
• <Hidden>true</Hidden> — a legitimate application has very little reason to hide its task

The combination that should stop you: a hidden task, running as SYSTEM, triggered at boot, whose command is an interpreter with an encoded argument.

There is also a second, lower-noise source: the Task Scheduler operational log, event ID 106 (task registered). Enable it at Event Viewer → Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational → Enable Log.

Step 5: When the events are missing, read the filesystem and registry

On a machine where auditing was never enabled, scheduled tasks still leave three on-disk records that must agree:

1. C:\Windows\System32\Tasks\<TaskName> — the task XML, as a file. Its creation timestamp dates the task even with no event log.
2. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<TaskName> — the registry entry the Task Scheduler UI enumerates.
3. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID} — the actual definition, keyed by GUID.

When those three disagree, the disagreement is the finding. A task present in TaskCache\Tasks but missing from TaskCache\Tree does not appear in the Task Scheduler UI but still runs — a well-documented hiding technique. Autoruns reads the underlying data rather than the UI's view, which is why it catches tasks the UI does not show.

Step 6: Compare Autoruns against the UI

Run Autoruns elevated, tick Options → Hide Microsoft Entries, and compare its Scheduled Tasks and Services tabs against what Task Scheduler and services.msc display.

Anything Autoruns shows that the UI does not is worth understanding immediately. That gap is the whole reason to run both.

Detection Worth Keeping

For a machine you administer:

• Alert on 7045 where Service File Name contains \Users\, \AppData\, \Temp\, or powershell/cmd/rundll32/mshta
• Alert on 7045 with kernel mode driver, always
• Enable the audit policy above and alert on 4698 and 4702 where the task is hidden, or runs as SYSTEM, or its command is an interpreter
• Baseline for a week first. Software deployment and patching generate all of these legitimately.

Related

• Scheduled task persistence: the attack and its artifacts — the same technique from the offensive side
• 30-minute triage of a suspected-compromised PC
• Consumer guide: removing malicious scheduled tasks and startup persistence

FAQ

Is event 7045 enabled by default on Windows 11?

Yes. Service Control Manager writes 7045 to the System log with no audit policy configuration required. Event 4698 for scheduled tasks is the opposite — it needs the "Other Object Access Events" audit subcategory enabled, which is off on a default install.

How do I see scheduled tasks that Task Scheduler does not show?

Run Autoruns elevated, or read the registry directly. A task whose definition exists under TaskCache\Tasks\{GUID} but has no matching entry under TaskCache\Tree will execute but will not appear in the Task Scheduler UI. Autoruns reads the underlying data, so it surfaces these; the UI does not.

Which is more common, a malicious service or a malicious scheduled task?

Scheduled tasks, by a clear margin, mainly because creating one does not always require administrative rights while creating a service does. Services remain common where the attacker already has SYSTEM and wants something that starts earlier in the boot sequence — and a new kernel mode driver in a 7045 event is always worth immediate attention.

Can I recover a task that was deleted to hide it?

Sometimes. Event 4699 records the deletion if auditing was enabled. The XML file in C:\Windows\System32\Tasks\ may be recoverable from the filesystem, and $UsnJrnl records the deletion with a timestamp even after the file is gone. Absent all of those, the deletion itself is still evidence — an unexplained gap in a task's registry entries is not normal.