Deepfake attacks are starting to show up in SOC telemetry

Here's a composite scenario built from a pattern I see repeat across onboarding alerts. A laptop ships to a new remote engineer, and within days a second remote-management tool turns up on the host, alongside the corporate one, under an account less than a week old. On its own, that reads as new-hire noise, the kind any detection engineer tunes around. What changes the read is the rest of the host timeline: a first login through a commercial virtual private network (VPN), then an ethernet connection that never hands back to Wi-Fi, then a Universal Serial Bus (USB) human interface device (HID) nobody on the team can name.

In this pattern, the employee has typically cleared several rounds of video interviews. None of that shows up in any log the SOC owns: whatever face and voice tooling ran the calls leaves no artifact in the security information and event management (SIEM) platform. But a synthetic interview doesn't remove the infrastructure an attacker still needs to control an issued endpoint, including remote-access software or keyboard-video-mouse (KVM)-over-IP hardware.

CrowdStrike's 2025 Global Threat Report found that its Falcon Adversary OverWatch team responded to 304 FAMOUS CHOLLIMA incidents in 2024, with roughly 40% involving insider-threat operations, and described North Korean IT-worker schemes using generative AI to build fake LinkedIn profiles.

Most SIEM and EDR deployments don't generate a reliable deepfake-specific alert by default; media-forensics verdicts need a separate product and integration. The indicators instead sit in USB device events, remote monitoring and management (RMM) installs, conferencing metadata, and identity verification verdicts, mostly in fields organizations never wire into the SIEM.

In Brief:

• Ordinary SOC telemetry exposes the hardware and software around a deepfake, including a keyboard-video-mouse (KVM) device on USB, two RMM vendors on one host, and network activity inconsistent with a claimed location after a United States first login.
• When validating video-conferencing telemetry, check whether fields can expose a virtual camera, and whether useful quality and capture-device data follows a different export path from the logs you stream to the SIEM.
• Do not assume that a liveness certification covering presentation attacks also proves protection against injection through a virtual camera or a hooked camera application programming interface (API).
• The correlation worth building this week joins identity verification (IDV) verdicts, multi-factor authentication (MFA) resets, and endpoint device events. The rule nobody can build reliably yet is one on the media stream itself.

The pattern that made me start looking for this in logs

In cases like this, HR terminates the account, the laptop gets imaged, and the attached hardware explains what the interviews didn't. This lines up with documented North Korean IT-worker activity. Mandiant's M-Trends 2025 report describes operators who land jobs under false identities and histories, sometimes backed by laptop-farm infrastructure, and puts insider threat at 5% of identified initial infection vectors in 2024, driven by a surge in this activity. The same report gives a global median dwell time of 11 days for 2024 investigations overall, not specific to insider-threat cases.

Treat KVM hardware as a reason to inspect locally attached input even when the process table shows no obvious remote session. Interview screening should never be the sole control: post-hire identity, endpoint, and access monitoring can catch suspicious activity conducted through legitimately issued credentials and approved-looking tools.

Why a deepfake attack doesn't trip a deepfake alert

SIEM and endpoint detection and response (EDR) platforms ordinarily receive logs, process events, endpoint activity, and network flows. Live media streams stay outside those feeds. The surrounding indicators land in conferencing metadata and liveness telemetry, and endpoint and identity events corroborate both.

Conferencing metadata can expose a virtual camera or an external join

For Teams, verify the fields your Microsoft Graph Call Records integration actually returns before you build a detection on it. The API documents usage and diagnostic data with a 30-day retention window, but it doesn't document a camera-device label or virtual-camera indicator, so don't assume tenant call-quality exports expose one. If your tenant's participant-type or external-user fields distinguish internal members from guests, use that classification as an additional review signal, not proof, for any meeting that ends in a payment approval, payroll change, or credential reset.

Zoom's Dashboard for meetings and webinars can expose device, client, network, and audio/video quality fields for eligible internal participants, but administrators can't view camera, microphone, device, domain, or local IP for external participants, so device data won't cover the join that matters most. Google Meet's documented Conference Records API covers conference, attendance, and participant-session metadata, not camera-driver identification or generic network and video-quality fields, so validate the exact fields before relying on them.

Where these fields exist, treat an external join, an unexpected client or device, or a mismatched network path as a low- to medium-confidence signal that needs corroboration, not attribution. Treat codec changes as a weaker hunting target unless the exported data carries useful switching events.

Liveness certification does not prove injection resistance

NIST IR 8491 treats physical presentation attacks and digital injection attacks, including virtual-camera substitution, as separate test categories, and your evaluation should follow that split. Don't infer injection resistance from a presentation-attack or liveness result unless the test scope explicitly covers digital injection paths such as virtual cameras, emulators, or a hooked camera API.

In threat modeling, include face swaps and synthetic media delivered through those paths, plus modified capture devices. When available, a vendor-specific spoof score, injection verdict, device-integrity signal, or reason code gives a security operations center (SOC) more triage context than a binary liveness result alone.

Machine-readable fields can exist without reaching the SOC automatically. If an IDV API or webhook provides spoof-risk scores, device-integrity indicators, or structured reasons, confirm those fields exist in the integration version you run, and write detection logic against payloads you actually observe, not a legacy schema.

Check whether your identity provider (IdP) records that a verification was allowed or denied and, where available, why. Then confirm whether the raw IDV injection signal reaches the IdP log or stays locked in the vendor's API, because when those fields stay separate, the SOC has to poll two sources to build one evidence chain.

Endpoint and identity telemetry produce the most actionable evidence

Endpoint and identity telemetry often produce the most actionable evidence, though it's worth correlating it against HR, conferencing, and fraud-system signals where those exist too. In Defender or another EDR, start with USB-connection events and check manufacturer and serial-number values for unexpected KVM hardware, using strings tied to PiKVM or TinyPilot as hunting terms you test against real device telemetry before hard-coding a rule.

Another pattern worth prioritizing: multiple RMM vendors on one host. Aggregate process starts by host over a short lookback and alert when two or more vendor families appear, especially on a newly issued laptop, but tune against known support hosts, since a technician machine may legitimately run an approved agent plus a remote-support tool.

A few more patterns round this out:

• ARP and asset data: treat unfamiliar single-board computers or KVM appliances as preliminary leads when ARP or asset data expose hardware-vendor identifiers, and weight remote-control executables installed right after shipment more heavily. Microsoft's 2025 Digital Defense Report found 79% of ransomware cases in its Incident Response engagements involved at least one RMM tool: a scoped finding, but still a reason RMM software deserves strong inventory and correlation beyond this threat model.
• MDM profile installs: for a GoldPickaxe-style scenario, treat unexpected profile installation as a lead for social-engineering-driven device enrollment. On Apple-managed endpoints, investigate profile-add telemetry when the initiating process doesn't match the expected mobile device management (MDM) path; on Windows, investigate enrollment events on devices absent from the asset inventory.
• ITDR events: an identity threat detection and response (ITDR) stack should already surface bulk MFA-factor resets, authenticator changes, password resets, and administrator-initiated recovery actions. The sequence matters more than any single event: help-desk impersonation followed by a password reset and new authenticator enrollment is worth investigating whether the caller used a deepfake, a voice actor, or nothing synthetic at all.

What I've built myself, and where the tooling still fails

After incidents like this one, I built our onboarding detections as three correlations in the detection-as-code repo, using T1219 as a tagging framework rather than a literal event type:

1. Ship-date join: the asset system's ship date to installation events for unapproved remote-access software on the same host within seven days, weighted higher when a second RMM vendor appears.
2. USB watchlist: validated USB vendor, product, serial, and description fields against an allowlist and KVM watchlist, alerting because our documented asset inventory contains no approved PiKVM devices.
3. IDV-to-reset join: a denied IDV event carrying a failure reason correlated with a password or MFA reset on the same identity inside a locally tuned 24-hour window.

In a retrospective review, the first two would have surfaced this pattern for analyst investigation early.

I distrust media-layer vendor claims until I test them against real-call conditions. Detector performance can shift once clean benchmark media picks up the compression, resampling, background noise, and post-processing of a real call, and the size of that shift depends on the detector, so validate it against your own test set.

Test video detectors against generators unlike those in their training set, and test them after the conferencing path has processed the media, not just against clean source. Separate a vendor's API, software development kit (SDK), and conferencing integration from an operational SIEM integration: no cross-vendor connector pattern I've reviewed forwards normalized verdicts, participant identity, timestamps, confidence, modality, and evidence the same way twice, so validate each one's event model directly.

Even when a verdict arrives, an analyst should still review the media and confirm the response before acting on it.

What to instrument before your next call goes sideways

The five use cases below are practical starting points where the required sources are already ingested and normalized; actual build time will vary by platform, licensing, and change-control process. They focus on the infrastructure and identity changes around the media. Start with the rule that best matches your current telemetry coverage.

• A USB device-connected rule keyed on unexpected KVM manufacturer strings, plus relevant TinyPilot and Raspberry Pi hardware identifiers in your ARP or network inventory.
• A new-hire correlation: laptop ship date joined to any RMM process start within seven days, with a second vendor on the same host as a hard page, and ethernet-only behavior and newly attached KVM hardware weighted as added evidence.
• An external-participant flag on any meeting where a payment, payroll change, or credential reset gets approved, using the tenant-validated guest, partner, domain, or external-participant fields your conferencing platform exposes.
• An identity join: a denied identity verification or an IDV spoof score indicating elevated risk, followed within 24 hours by an MFA-factor reset or administrator-initiated password reset.
• MDM profile installs whose initiating process does not match your MDM agent, plus Windows enrollment events on devices absent from your asset inventory.

I still can't reliably catch a live audio deepfake on a Teams or Zoom call from the media itself. The platform fields that might identify a virtual camera don't always follow the same export path as the audit logs I stream to the SIEM. Until both catch up, the alert that saved me was a second RMM install on a newly issued laptop, and that's the rule I'd write first.

Frequently asked questions about deepfake detection

How do SOC teams actually detect deepfake attacks?

In a SOC context, deepfake investigations usually correlate identity, endpoint, conferencing, and IDV evidence around an alleged impersonation: KVM hardware on USB, remote-management installs after a laptop ships, IDV spoof verdicts, external meeting joins, and the MFA resets that follow. These indicators raise risk, but none of them alone proves synthetic media was used. SIEM and EDR inputs cover the supporting telemetry; media-forensics verdicts, where a product is deployed, arrive through a dedicated API or webhook.

Can SIEM or EDR tools detect deepfakes directly?

SIEM and EDR tools detect the indicators around the fake, not the fake itself: USB KVM devices, multiple RMM vendors on one host, inconsistent VPN egress, and rogue MDM profiles. Their inputs are logs, process activity, endpoint events, and network flows. Detecting the synthetic media itself requires a separate media-analysis layer whose verdict can then be forwarded to the SIEM.

What telemetry sources carry deepfake attack indicators?

Start with conferencing metadata, IDV vendor scores, identity-verification outcomes, EDR USB and process events, MDM profile-install logs, and IdP password and MFA-reset events. Depending on the platform and export path, useful conferencing data may include capture-device information, participant device and Internet Protocol (IP) context, external-participant status, and quality measurements. Validate conferencing quality data carefully, because dashboards may expose one subset of fields while APIs and SIEM connectors expose others.

How is this different from vishing or BEC detection?

BEC investigations draw on message headers, trace data, mailbox-rule changes, and sign-in logs, while vishing investigations draw on call and chat metadata, subsequent RMM activity, and MFA events, though the call itself may still leave a recording, transcript, or carrier log depending on the telephony platform's retention policy. A deepfake-enabled video impersonation can add conferencing-session metadata and, where liveness checks are used, related decision records, but the video stream itself is media evidence, not an endpoint, identity, or network indicator of compromise. In current MITRE ATT&CK Enterprise, impersonation maps to T1684.001, Social Engineering: Impersonation, voice phishing maps to T1566.004, and remote-access tools or hardware map to T1219. The evidence chain differs by channel: email and mailbox artifacts for BEC, call and identity activity for vishing, conferencing plus IDV telemetry for deepfake-enabled impersonation.