Skip to content 
Introduction
If you use AWS, remember that attackers frequently do not break in by hacking software. Instead, they usually log in with valid credentials. TruffleNet shows this clearly. Rather than using a single exploit, it works by using stolen AWS keys to test whether they work, then abusing cloud services, especially email, to make money fast.
In this blog, we will show what TruffleNet looks like from inside an AWS account. We will cover the likely steps an attacker takes, the AWS API calls you might see, and the controls that really help reduce risk. The goal is to be practical. If your team uses AWS every day, you should leave with a clear idea of what to watch for, what to secure, and what to do if you spot this pattern.
Who this is for
This is for clients who run AWS in production and deal with real-world complexity, like multiple accounts, regions, CI/CD pipelines, third-party tools, and developers who need quick access to ship features. It is also important to note that if you use Amazon SES for transactional or marketing email, TruffleNet research shows that SES is a primary target for large-scale cloud abuse, including BEC-style fraud.
Even if you do not use SES now, this still matters. TruffleNet reminds us that unused services, old keys, and open IAM policies can quietly become risks the moment a credential leaks.
What TruffleNet is, in plain terms
Fortinet’s research describes TruffleNet as an extensive system that automates the checking and use of stolen cloud credentials. They saw it running on many different hosts and networks. Attackers benefit from speed and scale—they do not need to break into one company deeply if they can test thousands of keys and find a few that work. Reporting is that TruffleNet was built around TruffleHog, a well-known secret-scanning tool that can verify whether discovered credentials are actually valid. In other words, TruffleNet weaponizes the same concept defenders like—verification—to turn leaked credentials into instant operational access.
The attacker’s technical flow inside AWS
Getting keys is the “exploit”
In the TruffleNet model, the attacker already has AWS access keys and secrets. These might come from a leaked code repository, a CI log, a hacked developer computer, a stolen .aws/authentication file, or an exposed environment variable in a build system. TruffleNet works because many organizations still have long-lived credentials.
This is consistent with the general tendency covered elsewhere: attackers blend into trusted platforms and normal workflows to steal credentials. For example, Dark Reading reported that cloud file services are abused in BEC campaigns because the delivery channel seems authentic and familiar to employees. The first “win” for the attacker is not code execution; it is trust.
Credential validation with STS
Once the attacker has a candidate key pair, they need to know whether it works and to which key it belongs. The fastest path is sts:GetCallerIdentity. This call is low-cost, widely supported, and provides immediate context, such as the AWS account and identity ARN. Fortinet describes this kind of validation behavior as part of the credential testing workflow.
According to AWS’s documentation, GetCallerIdentity is the standard way to return details about the identity used to make the request. That is exactly why attackers like it.
Here is what that looks like in practice:
Figure 1: STS call response on AWS CLI
Figure 2: Event record of STS lookup
If you see this call from an unusual IP range, a location your teams never use, or a user agent you do not recognize, treat it as a sign that a key was just tested.
SES probing to determine monetization potential
In the TruffleNet reporting, a major objective is abusing email sending at scale, and SES shows up as a meaningful target. A common early SES action is retrieving sending quotas, because it indicates whether the account can be used to push significant volume.
AWS says SES quotas are set per region, and you can get them with ses get-send-quota. If your team only sends mail from one region, a quota check in another region is an early warning sign to investigate.The sequence often looks like this:
aws ses get-send-quota –region us–east-1 aws ses list-identities —-region us-east-1aws sesv2 get-account --region us-east-1 aws sesv2 list-email-identities --region us-east-1The list-identities operation lists the domains and email addresses that are already verified in SES for that region. The sesv2 get-account operation returns account-level SES status and capabilities for the region. If you think like an operator, that is, reconnaissance that tells them how quickly they can start sending mail that will actually deliver.
IAM persistence attempts and privilege expansion
Fortinet notes activity consistent with attackers attempting to create or modify identities, including creating new users and updating login profiles, alongside other reconnaissance activities. This part matters because it is where a “single leaked key” becomes durable access.
In a well-managed AWS setup, a sudden iam:CreateUser event is unusual. Most organizations use SSO, federation, and roles instead of manually creating console users. That is why IAM changes are a strong signal, especially if they happen soon after STS validation and SES checks.
Turning SES into BEC infrastructure
The report also describes activity associated with BEC-style operations and highlights how attackers can establish or leverage sending identities, including DKIM-related behavior sourced from already-compromised infrastructure. At that point, the attacker is not simply “in your AWS.” They are using your AWS account as a fraud platform.
This is also when business impact rises fast. Even if you disable the stolen access key, problems such as email reputation damage, domain trust issues, and additional incident response work can persist.
Most TruffleNet IPs did not have a bad reputation or show up in antivirus checks. Usually, cloud attacks originate from IPs associated with VPNs, TOR, or other suspicious activity, but that was not the case here. Only the GetSendQuota and GetCallerIdentity calls were observed on these hosts, with no further activities or privilege escalation. This suggests a tiered setup, where some nodes do reconnaissance, and others handle later attack steps.
Figure 3: TruffleNet Reconnaissance Topology
What you will actually see in CloudTrail
The AWS control plane is where this story becomes visible. CloudTrail records management API calls, which is exactly what TruffleNet-style workflows rely on. A key point from the TruffleNet coverage is that much of the early activity uses legitimate API calls that do not look inherently malicious in isolation. The trick is correlation: the sequence, timing, identity, source network, and region.
A suspicious pattern often includes STS validation calls, SES quota checks, SES identity listing, service quota checks, and IAM changes like creating users or updating login profiles. Fortinet lists call patterns such as ListIdentities, ListServiceQuotas, UpdateLoginProfile, CreateUser, and SES account or identity actions.
If you use CloudTrail Lake, you can run SQL queries across extensive data collections, and AWS lets you start these queries from the CLI. This is very helpful during triage because you can quickly find out what an access key did without digging through logs by hand.
Here is an example query you can adapt for hunting:
aws cloudtrail start-query --query-statement ' SELECT eventTime, eventSource, eventName, userIdentity.arn, userIdentity.accessKeyId, sourceIPAddress, userAgent, awsRegion FROM EVENT_DATA_STORE_ID WHERE eventName IN ("GetCallerIdentity", "GetSendQuota", "ListIdentities", "ListServiceQuotas", "CreateUser", "UpdateLoginProfile", "CreateEmailIdentity", "GetAccount") AND eventTime > "2025-11-01 00:00:00" AND eventTime < "2025-12-01 00:00:00" ORDER BY eventTime ASC;'This query is much more useful if you add filters for unexpected regions, strange user agents, and bursts of activity from source IPs that do not match your usual company traffic.
What attackers run, and what defenders should run
The attacker’s side of this is not just theory. It only takes a few AWS CLI calls that anyone can automate.
On defense, your main job is to clear up uncertainty fast. You need to identify the compromised user, review the actions they took, and check whether they changed IAM or SES settings.
The IAM credential report is particularly useful because it provides a single snapshot of which users have access keys, when keys were last rotated, and whether MFA is present. AWS supports generating and retrieving it directly via CLI, which makes it easy to automate into incident playbooks:
aws iam generate-credential-report aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csvWhy “this looks normal” is the real danger
A TruffleNet-style attack is risky because its initial steps appear to be normal admin actions. For example, a developer might use GetCallerIdentity to debug credentials, or a platform engineer might check SES quotas while fixing email issues. This is why simple alerts can create too much noise, and noisy alerts often get ignored. That means you care about who did it, where they did it from, whether this principal has ever done it before, and whether the action is immediately followed by IAM mutations or SES configuration changes. When those signals align, you are no longer looking at “maybe normal.” You are looking at an attacker validating, scoping, and preparing for abuse.
Dark Reading’s coverage of campaigns abusing AWS services for stealth reinforces this theme. Attackers increasingly use legitimate cloud endpoints and features as part of their kill chain precisely because they hide in plain sight.
How to harden AWS specifically against TruffleNet-style credential abuse
Treat long-lived access keys as a controlled exception
The simplest way to stop TruffleNet is to have fewer long-lived keys. Every permanent access key can be copied, sold, tested, or abused. Whenever possible, have developers and automation use short-lived credentials with roles, federation, or SSO. Even if an attacker steals a token, they have less time to use it, and the damage is easier to control. To keep access keys, the operational rule should be that no key exists without an owner, a rotation expectation, and monitoring coverage. In practice, the best environments treat access keys like production certificates: issued intentionally, rotated regularly, and revoked aggressively when not needed.
Put SES behind clear permission boundaries
If you do not use SES, the best step is to ensure no identities in your AWS organization can use it, whether by mistake or on purpose. In well-managed setups, this is done by setting an explicit deny at the organization level for accounts that should never send email.
If you do use SES, treat its permissions as highly sensitive, since SES is an external channel and a reputational risk. Monitor quota checks, identity listings, and account changes as sensitive events, especially if they originate from unknown networks or occur at odd times. AWS notes that quotas are region-specific, so region anomalies are a useful detection signal.
Make IAM mutations loudly visible and hard to misuse
TruffleNet reports show attackers creating users and updating login profiles to gain more access. You should assume that any stolen credentials may result in persistent access if IAM write permissions are available. This is why separation of duties is important. Application roles should almost never be able to create users, manage credentials, or change authentication settings.
When you cannot avoid IAM write permissions in certain automation contexts, you should isolate those permissions behind strong constraints, such as tightly scoped roles, clear session duration, strict conditions, and monitoring that triggers immediate investigation when IAM mutation events occur outside known automation paths.
Improve your ability to detect “credential testing”
Attackers check keys quickly to find the ones that work. Fortinet shows that TruffleNet does credential testing and reconnaissance at scale. To keep up, you need detection that looks for both STS validation and follow-up reconnaissance, not just one action.
In practice, you should tune detections around patterns like “first time this principal called STS from this ASN,” “sudden burst of STS calls across many source IPs,” and “STS validation immediately followed by SES quota checks or IAM changes.” These are the kinds of correlations that separate benign usage from an automated exploitation pipeline.
Using TruffleHog defensively without fooling yourself
TruffleNet is built around TruffleHog, and the public TruffleHog project focuses on finding and checking leaked credentials. Attackers like this feature, but defenders should use it too.
The key is where you run it. You get the most value when you run secret scanning in places that prevent exposure from ever becoming a leaked credential. Running TruffleHog in CI, scanning repositories before merges, and scanning shared storage locations that developers know they use are all sensible approaches. TruffleHog’s own documentation shows CI-focused usage patterns, including failing builds when verified or unknown secrets are detected.
A simple CI-friendly example looks like this:
trufflehog git file://. --results=verified,unknown --failThat does not solve credential theft on its own, but it greatly reduces accidental leakage, which is one of the main ways TruffleNet gets access fuel.
What to do the moment you suspect TruffleNet-like activity
When teams first notice stolen-key activity, the first reaction is often to rotate the key and move on. That is needed, but not enough. TruffleNet-style attacks can also include IAM persistence and SES abuse, and Fortinet saw cases where IAM and SES actions were part of fraud.
Your containment should focus on stopping the active credential and then validating whether anything durable changed. That means you should confirm no new IAM users were created, no access keys were added, no login profiles were updated, and no SES identities or account settings were modified. Your scoping should come from CloudTrail, ideally via CloudTrail Lake queries for speed and completeness.
If SES abuse is suspected, treat it as a business-impact incident, not just a cloud incident. Fraudulent email sending can create reputational and deliverability problems that outlast the technical compromise and trigger downstream buyer faith issues.
Closing thoughts
TruffleNet is not scary because it uses advanced exploits. It is scary because it is mature and efficient. It can quickly turn one leaked key into real fraud by using normal AWS APIs that look harmless unless you connect the dots.
References
- https://www.fortinet.com/blog/threat-research/cloud-abuse-at-scale
- https://www.darkreading.com/vulnerabilities-threats/trufflenet-attack-stolen-credentials-aws
- https://www.darkreading.com/cyberattacks-data-breaches/microsoft-creative-abuse-cloud-files-bec-attacks
- https://github.com/trufflesecurity/trufflehog
- https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html
- https://docs.aws.amazon.com/cli/latest/reference/ses/list-identities.html
- https://docs.aws.amazon.com/cli/latest/reference/guardduty/list-findings.html