# Event IDs 7045 and 4698: Spotting Persistence on Windows 11 URL: https://www.mytechnician.tech/labs/event-ids-7045-4698-service-scheduled-task-persistence/ Published: 2026-08-08 | Author: Ankit Kumar Track: Attack and detection | Difficulty: Intermediate | Authorization: defensive Time required: 30 min Verified on: Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch MITRE ATT&CK: T1543.003, T1053.005 Tags: Persistence, Services, Scheduled Tasks, Event Log, Detection Summary: A new service and a new scheduled task are the two most common ways malware survives a reboot on Windows. Both are logged. Here is how to read those events and separate them from normal software installs. ## 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: - **`` and ``** — what actually runs - **``** — `` and `` are the persistence-relevant ones - **``** — `S-1-5-18` means SYSTEM, which is the highest-value outcome for an attacker - **`true`** — 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\`** — 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\`** — 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](https://www.mytechnician.tech/labs/detect-scheduled-task-persistence-windows-11/) — the same technique from the offensive side - [30-minute triage of a suspected-compromised PC](https://www.mytechnician.tech/labs/triage-compromised-windows-11-pc-30-minutes/) - Consumer guide: [removing malicious scheduled tasks and startup persistence](https://www.mytechnician.tech/tips/remove-malicious-scheduled-tasks-startup-persistence-windows-11/) ## 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. --- Source: https://www.mytechnician.tech/labs/event-ids-7045-4698-service-scheduled-task-persistence/ — My Technician Security Labs. Authorization: defensive. This write-up is published for defensive and educational use on systems you own or are authorized to test. More labs: https://www.mytechnician.tech/labs/