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 quiet in the corpus this week — no current KEV, OSINT, or active-family signal. The detection stands ready; there is simply nothing exercising it right now. (Checked September 18, 2026.)

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 above is the canonical artifact — machine consumers should subscribe via /sigma/manifest.json and fetch t1098-005-hypervisor-mfa-device-enrollment.yml directly. Each rule's live intel context is in /sigma/evidence.json keyed by slug. This page is a rendered view, regenerated daily.