Defence against APT35 starts with reducing account takeover and phishing exposure. Organisations should harden identity controls with MFA, conditional access, passwordless options where possible, and alerting for impossible travel, suspicious inbox rules, and unusual OAuth consent. Patch internet-facing systems quickly, restrict admin privileges, and monitor for credential theft, persistence, and cloud account abuse.
What APT35 defenders should focus on first
APT35 is best approached as an identity-led intrusion problem, not just a malware problem. The group’s most reliable entry paths are usually phishing, credential theft, mailbox abuse, and cloud account misuse, so defensive effort should concentrate on reducing the chance that stolen credentials or a captured session can turn into durable access. That means hardening the login path, tightening admin exposure, and making suspicious authentication behaviour visible quickly.
For organisations that need a practical starting point, the first question is whether an attacker can get from one compromised account to broader access. Controls that reduce account takeover, privilege abuse, and cloud token misuse matter more than broad perimeter hardening when the adversary is operating through legitimate services and user workflows.
When identity is a key entry path, use NIST SP 800-63 Digital Identity Guidelines to prioritise phishing-resistant authentication and stronger authenticator choices for exposed users and administrators.
How to reduce phishing, mailbox, and cloud-account abuse
The most valuable control set is the one that breaks the attacker’s ability to reuse stolen credentials and tokens. MFA should be enforced everywhere it is feasible, but the stronger outcome comes from combining MFA with conditional access, device and location checks, and passwordless methods where the environment can support them. That reduces the odds that a replayed password or stolen session can be used quietly from a new system or region.
Mailbox hardening also matters because attackers often live off the mail platform after the first compromise. Alert on suspicious inbox rules, forwarding changes, consent grants, and OAuth application activity, because those are common ways to preserve access without repeatedly logging in. If the organisation already has good phishing awareness but still sees account misuse, the gap is often not awareness, it is session control and delegated app consent.
For the identity and privilege layer, Threat Actor Groups Guide helps practitioners connect APT naming to the wider threat-informable defence process, which is useful when correlating mailbox abuse, credential theft, and persistence patterns.
To align those controls with a recognised baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to identification, authentication, auditability, and access restriction requirements for exposed accounts.
What persistence and compromise checks matter after initial access
Defence is incomplete if you only stop the login attempt. APT35-style activity often persists by stealing mail, planting forwarding rules, abusing OAuth consent, or moving into cloud services where the compromise looks like normal user activity. The detection problem is therefore to spot abnormal use of a real account, not just a failed password sequence.
Investigators should look for impossible travel, anomalous session timing, unusual inbox rule creation, new device registrations, unexpected admin role changes, and signs that a mailbox or cloud identity is being used to stage further access. On internet-facing systems, timely patching still matters because initial footholds can be paired with credential theft or web-facing exploitation to widen access and improve persistence. The common mistake is treating the account alert and the server patch as separate workstreams when they are often part of the same intrusion chain.
MITRE ATT&CK Enterprise Matrix is useful for organising those checks around credential access, persistence, privilege escalation, and lateral movement rather than around product-specific alerts.
Risk and Threat Considerations
APT35 is dangerous because it can operate through ordinary identity flows, making compromise look like routine user activity until access has already been expanded. The main risk is not a single stolen password, but the combination of mailbox persistence, cloud session abuse, and excessive privilege that turns one foothold into repeated access.
Failure mechanism: Phishing or credential theft yields a valid account, then inbox rules, OAuth consent, or cloud sessions preserve access after the original password is changed or the user is warned.
Impact: Attackers can quietly read mail, reset passwords, harvest tokens, and use trusted business systems to move toward broader compromise without triggering obvious perimeter defences.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | APT35 defense depends on phishing-resistant authentication and strong authenticator choices. |
| Recommendation — Adopt phishing-resistant authenticators for high-risk users and administrators. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Defending against account takeover requires strong org-user authentication controls. |
| AU-6 — Audit Review, Analysis, and Reporting | Mailbox abuse and suspicious sign-ins need log review and alerting. | |
| Recommendation — Enforce strong authentication for organizational users and admins. Review authentication and mailbox activity logs for anomalous access. | ||
| MITRE ATT&CK | Enterprise Matrix | APT35 tradecraft is best hunted using credential access, persistence, and lateral movement techniques. |
| Recommendation — Map detections to credential access and persistence techniques. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Cloud and app token abuse can hinge on weak authentication paths. |
| Recommendation — Harden authentication paths and token handling for exposed APIs. | ||
Practitioner Guidance
What to prioritise: Treat privileged users, helpdesk accounts, and any mailbox with cloud admin reach as the highest-value protection tier. If those identities are not phishing-resistant and tightly monitored, the rest of the programme is likely to be reactive rather than preventive.
What to verify: Confirm that conditional access rules actually block risky sign-ins, that inbox rule alerts are being reviewed, and that OAuth consent is restricted or monitored. A policy that exists only on paper is not meaningful defence against this threat pattern.
Practitioner takeaway: The most effective APT35 defence is to make credential theft less useful, persistence more visible, and privilege much harder to abuse once a single account is touched.
Related resources from NHI Mgmt Group
- How should organisations defend against attack-as-a-service identity fraud?
- How should organisations defend biometric authentication against spoofing attacks?
- How should organisations defend against business email compromise when attackers use real conversations?
- How can organisations defend against AI-generated phishing and impersonation?