Remote Access Tool Detection: T1219 AnyDesk

Remote access tools like AnyDesk and TeamViewer are legitimate software. Attackers use them after gaining access because they're trusted by antivirus and blend into normal network traffic. This is T1219 — Remote Access Software. The detection challenge: the tool itself is legitimate. The context of its use is what makes it suspicious.

Default coverage check

sudo grep -ri "anydesk\|teamviewer\|T1219" /var/ossec/ruleset/rules/

Empty — no default coverage.

The detection strategy

Three rules at escalating severity:

1. AnyDesk downloaded — suspicious but not urgent. Could be accidental or authorised.
2. AnyDesk executed — more serious. The tool is running.
3. Downloaded then executed within 5 minutes — critical. A fresh download immediately run is the fingerprint of deliberate deployment.

Reading the raw events

AnyDesk was downloaded to the endpoint. Sysmon Event ID 11 (file creation) and Event ID 1 (process creation) were inspected in Event Viewer. Key fields from the execution event:

Image:            C:\Users\...\Downloads\AnyDesk.exe
CommandLine:      "AnyDesk.exe" --local-control
Company:          AnyDesk Software GmbH
IntegrityLevel:   Medium
CurrentDirectory: C:\Users\...\Downloads\

Running from Downloads rather than Program Files is itself a signal — IT-deployed software lives in Program Files.

The rules

<rule id="100015" level="10">
  <if_group>sysmon_event_11</if_group>
  <field name="win.eventdata.targetFilename" type="pcre2">(?i)AnyDesk\.exe</field>
  <description>Sysmon: AnyDesk downloaded to endpoint</description>
  <group>sysmon,remote_access_tool,T1219,anydesk_activity,</group>
  <mitre><id>T1219</id></mitre>
</rule>

<rule id="100016" level="12">
  <if_group>sysmon_event1</if_group>
  <field name="win.eventdata.image" type="pcre2">(?i)AnyDesk\.exe</field>
  <description>Sysmon: AnyDesk executed on endpoint</description>
  <group>sysmon,remote_access_tool,T1219,anydesk_activity,</group>
  <mitre><id>T1219</id></mitre>
</rule>

<rule id="100017" level="14" frequency="2" timeframe="300" ignore="300">
  <if_matched_group>anydesk_activity</if_matched_group>
  <same_location />
  <description>Sysmon: AnyDesk downloaded AND executed — confirmed deployment</description>
  <group>sysmon,remote_access_tool,T1219,confirmed,</group>
  <mitre><id>T1219</id></mitre>
</rule>

Rules 100015 and 100016 both tag anydesk_activity. Rule 100017 fires when that group accumulates 2 events within 300 seconds on the same endpoint. ignore="300" prevents the alert from firing repeatedly when AnyDesk spawns multiple processes.

The Event ID 11 problem

Rule 100015 wasn't firing. Investigation showed Event ID 11 wasn't reaching Wazuh at all.

# Check if Event ID 11 is in Wazuh alerts
sudo grep '"eventID": "11"' /var/ossec/logs/alerts/alerts.log | tail -5

# Check which Event IDs ARE reaching Wazuh
sudo grep '"eventID"' /var/ossec/logs/alerts/alerts.log | grep -o '"eventID": "[0-9]*"' | sort | uniq -c | sort -rn | head -10

The built-in Sysmon rule for Event ID 11 uses group tag sysmon_event_11 (with underscore before 11). The rule was using sysmon_event11 (without underscore). One character. The rule was listening to a group that didn't exist.

Fixing the group tag resolved it immediately.

The diagnostic principle

If other events from the same Sysmon channel are reaching Wazuh, the infrastructure is fine. The problem is always the rule — wrong group tag, wrong field name, wrong prefix, wrong syntax. The event is arriving. The rule is just not hearing it.