S0601: Hildegard
Analyst context for executives and security teams
Hildegard matters because it ties Kubernetes misconfiguration to cloud and container business risk: unauthorized access to kubelets can lead to cryptocurrency mining, resource theft, persistence, credential exposure, and degraded service availability. For leaders, the practical question is not whether a malware name is present, but whether Kubernetes nodes, Linux hosts, and IaaS workloads are hardened and monitored well enough to catch miner behavior, suspicious shell activity, credential access, and persistence changes.
Executive priority
Prioritize this as a cloud/container resilience and cost-control issue. The supplied ATT&CK context links Hildegard to misconfigured kubelets, cryptocurrency mining, compute hijacking, credential access, persistence, and stealth techniques. Executives should ask for evidence that kubelet exposure is controlled, cloud metadata access is protected, container and Linux telemetry is retained, and incident responders can quickly determine whether resource abuse also created credentials, accounts, services, or follow-on access.
Technical view
ATT&CK provides no official detection text for Hildegard, so SOC and IR teams should validate behavior-based coverage across Linux, Containers, and IaaS. Focus on the related techniques: Unix shell execution, ingress tool transfer, network service discovery, application-layer or web-service C2, local account creation, systemd service creation/modification, credential and private-key discovery, cloud instance metadata API access, file deletion, command-history clearing, dynamic linker hijacking, rootkit behavior, and compute hijacking. Because the object specifically references misconfigured kubelets, Kubernetes/kubelet exposure and authentication/authorization posture should be part of both detection validation and hardening review.
Likely telemetry
- Kubernetes and kubelet access logs, audit events, and configuration evidence showing authentication, authorization, and network exposure
- Linux process execution telemetry for shells, downloads, service changes, account creation, file deletion, history manipulation, and dynamic linker environment usage
- Container runtime and node telemetry showing unexpected processes, images, mounts, privilege use, and workload-to-node activity
- IaaS network flow, DNS, proxy, and egress logs for application-layer communications, web-service usage, scanning, and tool transfer
- Cloud instance metadata access logs or compensating host/network evidence where direct metadata logging is unavailable
Detection direction
- Build detections around the ATT&CK behaviors rather than the malware name, because no official Hildegard detection guidance is supplied.
- Correlate kubelet access anomalies with Linux shell execution, downloads, new or modified systemd services, new local accounts, and miner-like resource consumption.
- Tune for container and cloud context: service discovery and metadata API access may be legitimate for some workloads, so detections should account for expected namespaces, nodes, roles, and workload identities.
- Look for stealth chains, not single events: software packing or encoded files followed by deobfuscation, file deletion, command-history clearing, masqueraded services, dynamic linker hijacking, or rootkit indicators should raise priority.
- Validate blind spots in ephemeral containers and autoscaled IaaS nodes, where short-lived activity, missing host logs, or incomplete container runtime telemetry can hide the sequence.
Mitigation priorities
- First reduce initial access risk by reviewing kubelet configuration, external exposure, and authentication/authorization controls for Kubernetes environments.
- Harden Linux and container hosts by limiting unnecessary remote services, enforcing least privilege, and controlling who can create services, accounts, privileged containers, and host mounts.
- Protect cloud credentials by reducing insecure secrets in files, restricting access to private keys, and hardening access to the cloud instance metadata API where applicable.
- Limit and monitor outbound network paths needed for tool transfer and command-and-control, especially from container nodes and workloads that should not initiate broad external connections.
- Implement resource and workload controls that make compute hijacking visible and containable, including monitoring for abnormal CPU use and enforcing workload boundaries.
Analyst notes and limits
The supplied object identifies Hildegard as malware targeting misconfigured kubelets for initial access and cryptocurrency mining, first observed in January 2021, with TeamTNT believed to be behind it. The relationship set is useful for defensive planning because it spans access, execution, persistence, credential access, command-and-control, stealth, discovery, privilege escalation, and compute hijacking behaviors across Linux, Containers, and IaaS.
ATT&CK does not provide official detection content for this malware object, and the malware object itself lists no tactics. This take is derived from the official description, external references, platforms, and supplied relationships only. Local architecture, kubelet exposure, logging depth, cloud provider controls, and workload baselines are required to assess actual risk or detection coverage.
Hildegard
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
Groups, software, and campaigns
G0139: TeamTNT
TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | b1323b6bd6d0… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Unit 42 Hildegard Malware
Chen, J. et al. (2021, February 3). Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes. Retrieved April 5, 2021.
Open source URL -
[2]
mitre-attack S0601Open source URL
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.