T1098.005 Okta Verify Enrollment from a Hypervisor Guest

Enrollment or activation of an Okta MFA authenticator from a virtual-machine guest, the persistence step of the ShinyHunters "The Com" claims campaign. Once the operator has relayed a live session, a captured session is transient, so they bind their own Okta Verify device to the account: access that is independent of the victim's phone and survives a password reset. In the activation reversed for the companion research, that enrollment came from a Windows QEMU guest and the Okta Verify user-agent named the hypervisor outright (OktaVerify/… Windows/… QEMU/Standard_PC_i440FX_+_PIIX_1996), while the enrolled device object carried the tells of a throwaway guest rather than a managed endpoint: no SMBIOS serial (serialNumber Unknown), no TPM (tpmPresent false), and unmanaged (managed false). This rule matches an enrollment or factor-activation event carrying either a hypervisor user-agent or that serial-less, TPM-less, unmanaged device profile. A real user does not enroll Okta Verify from a serial-less QEMU guest; the combination is high-fidelity for attacker persistence.

Intel context

The technique this rule covers is in use. This is the evidence for it as of November 7, 2026.

Technique	KEV CVEs	Research, 90d	Active families
T1098.005 Device Registration	0	3	—

Research citing this technique

2026-10-28 · ReliaQuest Residential Proxies Mask Social-Engineering Attacks
2026-10-22 · Huntress M365 Token Spray and Replay Campaign Compromises Business Email Accounts
2026-09-02 · Huntress Inside Knight Office, a New M365 AiTM Phishing Kit

Rule ID: 834d527b-6789-4251-9702-bbe6b76eb4fe
Status: experimental
Level: high
Log source: product: okta
Date: 2026-09-12
Modified: 2026-09-12
ATT&CK: T1098.005 (signal rollup)
Canonical YAML: t1098-005-hypervisor-mfa-device-enrollment.yml

References

False positives

Organizations that legitimately run Okta Verify inside managed virtual desktops (VDI). Those enrollments are typically managed=true and carry a real serial or TPM from the VDI platform, so they will not match selection_throwaway_device; if they match selection_hypervisor_ua on the VM user-agent, allowlist the sanctioned VDI platform and image.
Developers and testers enrolling authenticators from local virtual machines for legitimate QA. Rare and usually on non-privileged test accounts; baseline before promoting past experimental.
Some device-management platforms report serialNumber as Unknown for genuinely managed but non-standard hardware. Require the full serial-less plus TPM-absent plus unmanaged conjunction, as this rule does, rather than the serial alone.

Rule YAML

title: 'T1098.005 Okta Verify Enrollment from a Hypervisor Guest'
id: '834d527b-6789-4251-9702-bbe6b76eb4fe'
status: 'experimental'
description: 'Enrollment or activation of an Okta MFA authenticator from a virtual-machine guest, the persistence step of the ShinyHunters "The Com" claims campaign. Once the operator has relayed a live session, a captured session is transient, so they bind their own Okta Verify device to the account: access that is independent of the victim''s phone and survives a password reset. In the activation reversed for the companion research, that enrollment came from a Windows QEMU guest and the Okta Verify user-agent named the hypervisor outright (OktaVerify/… Windows/… QEMU/Standard_PC_i440FX_+_PIIX_1996), while the enrolled device object carried the tells of a throwaway guest rather than a managed endpoint: no SMBIOS serial (serialNumber Unknown), no TPM (tpmPresent false), and unmanaged (managed false). This rule matches an enrollment or factor-activation event carrying either a hypervisor user-agent or that serial-less, TPM-less, unmanaged device profile. A real user does not enroll Okta Verify from a serial-less QEMU guest; the combination is high-fidelity for attacker persistence.'
references:
    - 'https://thrunt.me/research/2026-09-12-claims-kit-recaptcha-turnstile-xor-exfil/'
    - 'https://attack.mitre.org/techniques/T1098/005/'
author: 'Applied Cybernetics Group (via thrunt.me)'
date: '2026-09-12'
modified: '2026-09-12'
tags:
    - 'attack.persistence'
    - 'attack.t1098.005'
    - 'tlp.clear'
logsource:
    product: 'okta'
detection:
    selection_enroll:
        eventType:
            - 'user.mfa.factor.activate'
            - 'device.enrollment.create'
            - 'user.mfa.factor.update'
    selection_hypervisor_ua:
        client.userAgent.rawUserAgent|contains:
            - 'QEMU'
            - 'VMware'
            - 'VirtualBox'
            - 'Standard_PC_i440FX'
            - 'Virtual Machine'
    selection_throwaway_device:
        device.detailEntry.serialNumber|contains: 'Unknown'
        device.detailEntry.tpmPresent: false
        device.detailEntry.managed: false
    condition: 'selection_enroll and (selection_hypervisor_ua or selection_throwaway_device)'
falsepositives:
    - 'Organizations that legitimately run Okta Verify inside managed virtual desktops (VDI). Those enrollments are typically managed=true and carry a real serial or TPM from the VDI platform, so they will not match selection_throwaway_device; if they match selection_hypervisor_ua on the VM user-agent, allowlist the sanctioned VDI platform and image.'
    - 'Developers and testers enrolling authenticators from local virtual machines for legitimate QA. Rare and usually on non-privileged test accounts; baseline before promoting past experimental.'
    - 'Some device-management platforms report serialNumber as Unknown for genuinely managed but non-standard hardware. Require the full serial-less plus TPM-absent plus unmanaged conjunction, as this rule does, rather than the serial alone.'
level: 'high'

The YAML file is the rule, and this page displays it. Scripts should read /sigma/manifest.json and fetch t1098-005-hypervisor-mfa-device-enrollment.yml directly. The intel context for every rule is in /sigma/evidence.json, keyed by slug.