How can organisations defend against APT40 (Leviathan)?

Why APT40 Defence Starts With Exposure Reduction and Detection Depth

APT40 is best defended against as a long-horizon intrusion set that blends reconnaissance, credential theft and post-compromise activity. The practical objective is to shrink exposed entry points, make stolen access less useful, and raise the chance that unusual administrative or cloud activity is detected before staging or exfiltration can mature.

That means prioritising internet-facing services, remote administration paths, and any environment where a compromise can quickly pivot into servers or cloud control planes. Public-facing systems are not just initial-access targets, they are often the place where adversaries return to blend in, extend access, or move laterally after the first foothold.

Defenders should treat alerting as incomplete if it only covers malware or endpoint events. For this threat pattern, the higher-value signals are abnormal account use, unusual web requests to exposed services, and remote access patterns that do not match normal administrative behaviour.

For a broader map of threat actor naming, aliases and campaign intelligence, the Threat Actor Groups Guide is the most useful starting point because it helps teams connect Leviathan naming to other vendor or community labels without confusing the group with a single tooling set or campaign.

What to Harden First When APT40 Is a Concern

The first control move is to close the most common access paths that support this style of intrusion: patch exposed systems quickly, enforce MFA on remote and privileged access, and reduce standing privilege so compromised accounts do less damage. If the environment still relies on broad admin entitlements or stale access paths, detection alone will usually be too late.

Credential hygiene matters because stolen passwords, session material, or delegated access can be more useful than an exploit in the hands of a persistent operator. Review privileged accounts, service accounts, and cloud roles for excess permission, weak separation of duties, and credential reuse across systems or environments.

Telemetry should be rich enough to show not only that an account logged in, but what it did next. Administrative changes, unusual remote logins, new persistence mechanisms, and off-hours access to cloud or server resources are the kinds of events that turn a suspected intrusion into a confirmed compromise.

Use NIST Cybersecurity Framework 2.0 to organise the work across govern, identify, protect and detect, and use NIST AI Risk Management Framework only where AI-enabled detection or triage is part of the defence workflow.

How to Spot Post-Compromise Activity Before Exfiltration

Once a foothold exists, the adversary’s value lies in persistence, discovery and data movement. That is why defenders should look for staging patterns, abnormal use of administrative interfaces, and outbound traffic that does not fit the service’s normal profile, especially from public-facing hosts or managed devices that should not behave like interactive admin workstations.

Cloud services deserve the same suspicion as servers. A compromise that lands in one identity domain can quickly spread into storage, mail, code, or management APIs if access is overly broad or poorly monitored, so account activity and API use need to be reviewed as part of the same incident picture.

If the pattern involves authentication abuse or object access through APIs, OWASP API Security Top 10 helps teams focus on broken authorisation and sensitive-flow abuse, while MITRE ATT&CK Enterprise Matrix helps map observed behaviour to credential access, lateral movement and exfiltration techniques.

Risk and Threat Considerations

APT40-style activity is risky because the same access path used for initial compromise can become a durable control point for persistence, privilege escalation and quiet data theft. If organisations underinvest in logging or let public-facing systems keep broad trust relationships, they may not notice the intrusion until the attacker has already established repeatable access.

Failure mechanism: Exposed systems, weak authentication and excessive privilege let a single compromised account or host become a launch point for deeper server and cloud access, while sparse logging hides the transition from access to staging and exfiltration.

Impact: The likely outcome is prolonged compromise, loss of sensitive data, and a harder containment effort because the attacker can operate through legitimate tools and trusted paths rather than obvious malware alone.

Practitioner Guidance

What to prioritise: Start with the systems and accounts that can touch the most sensitive data or control planes, especially internet-facing services, remote admin paths and cloud identities with write access. If those are not tightly scoped, everything else becomes a detection problem instead of a prevention problem.

What to verify: Confirm that privileged access is logged with enough fidelity to answer who accessed what, from where, and what changed afterwards. If you cannot reconstruct that chain for server and cloud administration, your readiness against this threat class is incomplete.

Practitioner takeaway: The most effective defence is not a single signature or block rule, but a tighter combination of exposure control, strong authentication, privilege minimisation and high-quality telemetry that can survive legitimate-looking abuse.

Related resources from NHI Mgmt Group

• How can organisations defend against Leviathan Australian intrusions?
• How can organisations defend against Leviathan?
• How should organisations defend against attack-as-a-service identity fraud?
• How should organisations defend biometric authentication against spoofing attacks?