S9035: LAMEHUG
MITRE ATT&CK S9035: LAMEHUG Malware details for Windows, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
LAMEHUG matters because it represents an information-stealing malware pattern where command generation is tied to large language models rather than only static attacker-written logic. In practical terms, defenders should expect reconnaissance, collection, and system manipulation activity to vary more than with fixed scripts. The ATT&CK record identifies it as Windows malware, first reported in phishing emails targeting Ukrainian government officials, with relationships to discovery, collection, command execution, web-based command-and-control, staging, archiving, encoding, and exfiltration behaviors.
Executive priority
Treat LAMEHUG as a planning case for resilience against adaptive malware and phishing-led intrusion, not just as a single malware name. Leaders should ask whether the organization can prove visibility across Windows endpoint execution, Python activity, command shell use, WMI, domain discovery, local data staging, archive creation, and outbound web service traffic. The business decision value is in validating whether SOC and incident response teams can reconstruct data-access and exfiltration paths when malware dynamically changes commands. Because ATT&CK provides no official detection text for this object, coverage should be evidenced through behavior-based controls and telemetry rather than signature-only assurances.
Technical view
For SOC, detection engineering, and IR teams, the relationship set points to a Windows-focused behavior chain: user execution of a malicious file, Python and Windows command shell execution, WMI abuse, extensive host/domain discovery, local file and directory enumeration, automated collection, local staging, archive creation, encoded C2/exfiltration over web protocols, and bidirectional communication through legitimate external web services. Validate correlations across process creation, command-line arguments, parent-child process relationships, WMI events, file/archive activity, domain enumeration commands, and outbound HTTP/S connections. Give special attention to unusual Python execution on endpoints where Python is not expected, command shells spawned from user-opened files, and discovery commands followed by staging or outbound web traffic.
Likely telemetry
- Windows endpoint process creation and command-line telemetry
- Python interpreter or packaged Python executable execution evidence
- Windows Command Shell activity
- WMI execution and management events
- File and directory enumeration activity
Detection direction
- Build behavior chains rather than relying on the LAMEHUG name, since the official ATT&CK object provides no detection guidance.
- Prioritize detections that join user-executed files with Python, cmd.exe, or WMI activity, followed by discovery commands and outbound web traffic.
- Tune for legitimate administration: WMI, domain discovery, service discovery, and command shell use can be normal for IT operations, so baselines by role, host group, and administrative toolset are important.
- Validate whether web service and HTTP/S monitoring can distinguish expected business traffic from suspicious bidirectional command/output patterns without assuming all external web services are malicious.
- Look for collection progression: file discovery or local system data access followed by local staging, archive creation, encoding, and exfiltration over the same or related communications channel.
Mitigation priorities
- Strengthen phishing resistance and malicious file handling controls, because the object description identifies phishing emails and malicious-file execution as relevant context.
- Restrict and monitor unnecessary Python execution on Windows endpoints, especially where Python is not part of the approved software baseline.
- Apply least privilege and administrative segmentation to reduce the value of domain account, group, and trust discovery.
- Harden and monitor WMI and command shell usage, focusing on unauthorized execution paths and unusual parent processes.
- Ensure sensitive data locations are access-controlled and monitored so local collection and staging are harder to perform unnoticed.
Additional notes and limits
The ATT&CK object attributes LAMEHUG to APT28 and describes it as Python-based information stealer malware that queries LLMs hosted on Hugging Face to dynamically generate commands. The relationship context gives the most useful defensive map: discovery, execution, collection, staging, archiving, C2, encoding, and exfiltration. For Glexia-style prioritization, the key question is whether the organization has evidence continuity from initial user execution through data access and outbound communications.
Official detection content is not provided. The malware platform is listed as Windows; some related ATT&CK techniques list additional platforms, but those should not be interpreted as confirmed LAMEHUG platforms without local or additional source evidence. The supplied fields do not provide indicators, hashes, command examples, infrastructure, impact details, or confirmed exposure for any specific organization.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
LAMEHUG
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.