C2 Incident — Revoked AnyDesk Certificate (17 Endpoints)
Isolated Defender for Endpoint alerts occurring at varying times prompted a proactive network-wide hunt, uncovering 17 managed endpoints running AnyDesk v7.0.0 — signed with a certificate revoked in AnyDesk's January 2024 infrastructure incident. A non-standard process name (AnyDesk-f45eSaf2.exe) required investigation to confirm legitimate vendor provenance. No external C2 connections observed. Advisory issued to update all 17 installations.
In January 2024, AnyDesk GmbH disclosed a compromise of their production systems and revoked all existing code-signing certificates as part of their incident response. All versions of AnyDesk signed before this date — including v7.0.0 — now carry a revoked certificate. Microsoft Defender for Endpoint classifies executables with revoked certificates as untrusted, and AnyDesk's persistent relay connection behaviour (which is structurally similar to C2 communication) causes the alert classification to surface as "C2 behaviour blocked."
This was a widely publicised incident in the security community in Q1 2024. The client's failure to update across 17 managed endpoints indicates either a gap in software update management processes or an oversight in applying the vendor's remediation advisory — a systemic certificate hygiene failure rather than a malware incident.
The non-standard process name (AnyDesk-f45eSaf2.exe) introduced an additional analytical layer. RATs and remote access malware are frequently renamed to evade process-name-based detection rules. This name deviation could not be dismissed without verification — file metadata analysis was required to establish legitimate vendor provenance before the investigation could be scoped as a hygiene issue rather than a genuine malware incident.
A network-wide KQL hunt on the process name returned 17 distinct endpoints executing the same binary. File version metadata pulled from all 17 confirmed consistent "AnyDesk Software GmbH" as the CompanyName and "7.0.14" as the FileVersion — providing strong evidence of legitimate vendor provenance across the entire affected fleet. The custom naming convention (AnyDesk-f45eSaf2.exe) was subsequently confirmed as originating from the client's RMM deployment tool, which appends a unique identifier to managed software deployments.
Certificate verification confirmed the signing certificate was issued to AnyDesk Software GmbH and was revoked during their January 2024 infrastructure incident. The certificate serial number and revocation date are documented in AnyDesk's public disclosure. The version in use (v7.0.0, build 7.0.14, signed 2023-09-25) predates the certificate rotation — meaning every installation of this version on any endpoint will generate the same Defender alert.
Network connection review across all 17 endpoints confirmed exclusively internal LAN traffic — no external connections to AnyDesk relay infrastructure were observed. This indicates the application was installed but not actively being used for remote sessions at the time of detection. Defender blocked the process before any relay connections could be established.
The detection pattern — isolated alerts appearing at varying times across the estate — is explained by the fact that Defender performs certificate validation checks asynchronously and not always at the same point in the process lifecycle. The alerts were not correlated by the SIEM before the analyst's proactive hunt connected them as a single systemic issue.
| Type | Indicator | Notes |
|---|---|---|
| File | AnyDesk-f45eSaf2.exe | Non-standard process name — confirmed legitimate vendor binary via file metadata |
| Version | AnyDesk v7.0.0 (build 7.0.14) | Signed 2023-09-25 — certificate subsequently revoked January 2024 |
| Certificate | AnyDesk Software GmbH (revoked) | Revoked following AnyDesk infrastructure incident, January 2024 |
| File Hash | 1667221e86d40770dcf[REDACTED]35fb8aaaee3dcb8 | RF Score: Indeterminate — detection is certificate-based, not hash-based |
| Network | Internal LAN only | No external C2 connections — application not in active remote use at time of scan |
| Scale | 17 endpoints affected | Centralised RMM deployment — systemic version issue, not individual installs |
| Tactic | Technique | ID | Observed |
|---|---|---|---|
| Defense Evasion | Subvert Trust Controls: Code Signing | T1553.002 | Revoked certificate — Defender classifies binary as untrusted executable |
| Command & Control | Remote Access Software | T1219 | AnyDesk classified as RAT-category tool — blocked due to revoked certificate posture |
| Initial Access (Theoretical) | External Remote Services | T1133 | AnyDesk could enable persistent external remote access — policy risk if unmanaged or outdated |
// Identify all 17 affected endpoints and confirm file metadata
DeviceFileEvents
| where FileName == "AnyDesk-f45eSaf2.exe"
| summarize Devices=make_set(DeviceName), Count=count() by SHA1, FolderPath
| order by Count desc
// Verify no external connections from the blocked process
DeviceNetworkEvents
| where InitiatingProcessFileName == "AnyDesk-f45eSaf2.exe"
| where RemoteIPType != "Private"
| project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl
// Confirm C2 block events across all endpoints
DeviceEvents
| where ActionType == "AntivirusDetection"
| where FileName == "AnyDesk-f45eSaf2.exe"
| summarize count() by DeviceName, ActionType, ThreatName
// Confirm file metadata and certificate provenance
DeviceFileCertificateInfo
| where FileName == "AnyDesk-f45eSaf2.exe"
| project DeviceName, FileName, Signer, IsTrusted, CertificateExpirationTime, CertificateSerialNumberClassic certificate hygiene failure at scale. The AnyDesk January 2024 incident was widely publicised — this should have triggered an update across the estate in Q1 2024. 13+ months of exposure to a known revoked certificate is the primary finding here.
The non-standard exe name (AnyDesk-f45eSaf2.exe) was the most analytically interesting element — metadata verification was the correct step before any dismissal of the anomalous name.
Tuning candidate: if the client confirms the naming convention originates from their RMM tool, a detection exclusion scoped to the updated, valid hash can prevent repeat alerts post-update. Filename-based exclusions are never appropriate.