APT41 targets Linux cloud servers with new Winnti backdoor built to steal credentials


APT41 is expanding its Linux toolset again, this time with a backdoor built for cloud workloads. Recent reporting says the group deployed a new Winnti-family ELF implant that targets Linux servers running in AWS, Google Cloud, Microsoft Azure, and Alibaba Cloud environments, with the goal of stealing cloud credentials and maintaining quiet access over time.

The campaign stands out because it does not focus on loud disruption. Instead, it appears designed for stealth, credential harvesting, and long-term control. Reports say the malware collects secrets from cloud metadata services and local credential locations, then sends them out through an unusual SMTP-based command-and-control channel over port 25.

That makes this a cloud identity story as much as a malware story. If an attacker can pull IAM role credentials, service account tokens, or managed identity tokens from a compromised Linux instance, they may gain a direct path into storage, APIs, and other cloud services without cracking a user password. This is an inference based on how cloud metadata credentials work and on the reported harvesting behavior.

What the new backdoor appears to do

Public reporting describes the implant as a Linux ELF backdoor linked to APT41, also known as Winnti, that targets major cloud platforms through a mix of metadata theft and local credential discovery. The reporting says the malware reaches into AWS, GCP, Azure, and Alibaba Cloud environments and tries to collect cloud access material at scale.

One of the most notable details is the command channel. Instead of using the usual HTTPS traffic, the backdoor reportedly communicates over SMTP, which can help it blend into expected outbound traffic in some environments. Reports also say the operation used typosquatted domains themed around Alibaba and related brands to make the infrastructure look less suspicious.

Your sample text captured the main angle correctly: Linux cloud servers have become credential theft targets, and the malware appears built for stealth rather than disruption. I used that text as the starting context for this rewrite.

Why cloud metadata matters so much

Cloud metadata services are useful because they let workloads obtain short-lived credentials and instance details from inside the machine. AWS documents that EC2 instances can access instance metadata locally, while Azure documents that managed identity tokens can be requested from the Instance Metadata Service on a VM. If malware reaches that same local path, it may be able to request or steal those credentials too.

That is why the AWS defensive angle matters here. AWS recommends transitioning instances to IMDSv2 and provides controls to require it, which reduces exposure from weaker metadata access patterns. On Azure, Microsoft documents managed identities as a way to avoid hardcoded secrets, but those identities still need protection at the workload level because the token endpoint is reachable from the instance itself.

The broader lesson is simple. A compromised Linux server in the cloud is no longer just a server problem. It can become an identity problem, a storage problem, and a control-plane problem if the instance holds access to cloud resources. That conclusion follows directly from the reported credential targeting and from how cloud metadata systems issue tokens to workloads.

Why this looks like a serious shift

]APT41 has a long history of mixing espionage and financially motivated operations, and security reporting has repeatedly linked the group to the Winnti malware family. The new Linux focus suggests the group continues to adapt toward modern enterprise infrastructure, where critical applications now run on cloud-hosted Linux instances rather than only on traditional endpoints.

The stealth choices in this campaign reinforce that point. Reports describe low-detection ELF malware, SMTP-based C2, and infrastructure intended to blend into expected regional or provider-themed traffic. That combination suggests the operators care about persistence and quiet data access more than immediate impact.

For defenders, this means endpoint scanning alone is not enough. Teams need visibility into metadata access, unusual outbound SMTP from non-mail workloads, and suspicious token use after a server compromise. That recommendation follows from the reported tradecraft and from the official cloud documentation on metadata services.

Attack summary

ItemReported detail
Threat actorAPT41 / Winnti
Malware typeLinux ELF backdoor
Main goalSteal cloud credentials
Target environmentsAWS, Google Cloud, Azure, Alibaba Cloud
Command channelSMTP-based C2 over port 25
Key defender concernMetadata token and credential theft

These details come from current public reporting on the campaign.

What security teams should do

  • Audit outbound SMTP from Linux workloads that are not supposed to send mail.
  • Require IMDSv2 on AWS where possible and review instance metadata settings.
  • Review which Azure workloads can request managed identity tokens and monitor for unusual token access patterns.
  • Hunt for unexpected access to local cloud credential files on Linux hosts. This step follows from the reported collection behavior.
  • Correlate server compromise alerts with unusual cloud API activity after the fact, especially role use from unfamiliar sources. This is an inference based on the reported credential theft objective.

FAQ

What is new about this APT41 campaign?

The main change is the focus on Linux cloud workloads and cloud credential theft, paired with an SMTP-based backdoor channel instead of more typical web-based C2.

Why are metadata services such a valuable target?

Because they can provide temporary credentials and identity tokens to workloads running on a cloud instance. If malware can access them locally, it may steal those credentials and use them elsewhere.

Does IMDSv2 solve the whole problem on AWS?

No. It improves metadata protection and AWS recommends it, but it does not remove risk from a fully compromised workload that can legitimately access the metadata service from inside the instance. That is an inference from AWS’s documentation and the reported malware behavior.

What should defenders look for first?

Start with unusual outbound SMTP from non-mail servers, suspicious metadata access, and cloud token use that appears after a Linux server compromise.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages