Mahesh Harripaul
Home Experience Blog Services Contact
← Back to blog
SysmonMITRE T1053.005MITRE T1071.001Scheduled tasksC2 detection

Persistence and Command & Control: T1053.005 Scheduled Task Abuse and T1071.001 C2 over HTTP/S

July 5, 2026 · Mahesh Harripaul

2
Techniques detected
12
Alert level
2
Rules confirmed firing

T1053.005 · T1071.001 · Sysmon · Scheduled Tasks · C2

Part of my ongoing Wazuh detection engineering lab series

Detecting Scheduled Task Abuse — MITRE T1053.005

Windows has a built-in feature called Task Scheduler. It lets the OS and applications run programs automatically at set times. Legitimate uses include Windows Update, antivirus scans, backup jobs. Attackers abuse it to stay on a machine — they schedule their malicious program to run every time the system starts or a user logs in.

The challenge with detecting this is that Windows creates scheduled tasks constantly in the background. You can't just alert on every task creation — you'd be drowning in noise.

The approach here was an allowlist. Instead of trying to list every suspicious thing that could create a task, I listed the legitimate processes that should be creating tasks — svchost.exe, taskeng.exe, taskhostw.exe, mmc.exe, explorer.exe — and negated them. Anything outside that list triggers the alert.

The detection uses Sysmon Event ID 1 (process creation), matching on schtasks.exe being launched, then checking the parent process against the allowlist. If the parent isn't on the list, something unexpected is interacting with the task scheduler and that's worth knowing about.

Tested by running schtasks /create from PowerShell — alert fired. Opened Task Scheduler through the GUI — no alert. The negate is working as expected.

Detecting C2 Communication over HTTP/S — MITRE T1071.001

Once an attacker is on a machine, they need a way to communicate back to their server — to receive instructions and send data out. HTTP and HTTPS are the preferred channel because they blend in with normal web traffic. A firewall sees what looks like regular browsing. It's actually the attacker's malware checking in.

Wazuh has default coverage for PowerShell making network connections, but nothing specifically targeting ports 80 and 443. That's the gap.

The rule chains off Wazuh's own default rule for PowerShell TCP connections, then adds two conditions — destination port must be 80 or 443, and the connection must be outbound (initiated=true). This way we're building on what already exists rather than starting from scratch.

Tested on port 80 using a web request to a public site — alert fired. Tested on port 443 using my own personal website over HTTPS — alert fired. Both confirmed working at level 12, MITRE T1071.001 mapped correctly with Command and Control tactic.

That's two more detections done.

Previous: Process Discovery All posts →