How to Spot DCSync and Mailbox Harvesting After a Web Server Is Breached

The joint advisory AA26-281A, published in October 2026, is unusually detailed about what the China-linked actors it describes did after they got in. The initial access came from exploiting old vulnerabilities picked up by an industrial scanning pipeline, but the damage came from two quieter techniques: dumping Active Directory credentials with DCSyncDCSync🛡️A credential-theft technique in which an attacker impersonates a domain controller and asks a real one to replicate account data, including password hashes, over the normal Active Directory replication protocol., and harvesting mailboxes through legitimate email APIs. Both are designed to look like normal administrative activity. This guide explains how to detect each one.

Why these two techniques matter

An attacker who compromises one internet-facing web server has a foothold, not a breach. The foothold becomes a breach when they can move laterally and read the organisation's data. DCSync delivers the first by handing over credentials for the entire domain. Mailbox harvesting delivers the second by copying the content that most organisations care about most: email.

Both techniques share a property that makes them dangerous and detectable at the same time. They abuse legitimate, authorised mechanisms rather than exploiting a bug. DCSync uses the same replication protocol that domain controllers use to synchronise with each other. Mailbox collection in the advisory used Microsoft's Exchange Web Services and Microsoft 365Microsoft 365🌐Microsoft's subscription-based cloud productivity suite including Office applications, Exchange Online, SharePoint, and Teams. APIs, the same interfaces a mail client uses. That is why they evade signature-based tools. It is also why, once you know the normal shape of that activity, the abuse stands out.

Detecting DCSync

DCSync is a credential-access technique, catalogued as MITRE ATT&CK T1003.006, in which an attacker asks a domain controller to replicate account data, including password hashes, by impersonating another domain controller. The advisory names a tool, DC.exe, that performs it. The key insight for detection is that only domain controllers should ever make a replication request. A workstation or an ordinary member server doing so is almost always malicious.

The authoritative signal lives in domain controller security logs: a directory service replication event showing a replication request whose source account is not a domain controller computer account. In Windows terms this is event ID 4662 referencing the replication control-access rights, specifically the extended-right GUIDs for directory changes, from a principal that is not DC$. If you have a SIEM collecting domain controller logs, the detection is a rule that fires when a replication-rights access is granted to any account outside the small, known set of domain controllers and legitimate directory-sync services.

Practical steps to stand this up:

1. **Establish the baseline.** List every account that legitimately replicates: your domain controller computer accounts and any directory-synchronisation service accountService Account🛡️A non-human operating system or application account under which a service runs. Its permissions define the blast radius of any exploit against that service, since attacker code executes with the service account's access to files, secrets, and the network., such as the one used by Entra Connect. This set is small and changes rarely.
2. **Alert on anything outside it.** Any replication request sourced from a user account, a workstation, or an unexpected server is the detection. There is no benign reason for a laptop to ask a domain controller to replicate the directory.
3. **Enrich with context.** Correlate the source host against your inventory of recently-exposed or recently-compromised servers. A replication request from a host that answered an internet scan last week is a high-confidence incident.

Because the advisory's actors reached Active Directory after compromising an internet-facing service, the hosts flagged by an external exposure review are the ones to watch first. How to Find Which of Your Admin Consoles Are Reachable From the Internet helps build that list of candidate pivot points.

Detecting mailbox harvesting

The advisory describes two mail-collection tools. One, a PHP script called curlc4.txt, drives the Exchange Web Services API on-premises. The other, office-cli, reaches Microsoft 365 using a stored client ID, tenant ID and secret. Both map to ATT&CK T1114.002, remote email collection. The detection problem is that a legitimate mail client also talks to these APIs constantly, so you are hunting for abnormal patterns, not forbidden actions.

The patterns that separate harvesting from normal use:

• **Volume and breadth.** A user reads their own mailbox. A harvesting tool downloads many mailboxes, or the entire contents of one, in a short window. Look for a single credential or application identity accessing an unusual number of mailboxes, or exporting an unusual volume, compared to its own history.
• **Application versus interactive access.** The Microsoft 365 tool authenticates as an application using a client secret, not as a person. Audit which registered applications hold mail-read permissions across the tenant, and alert when a new application is granted them or an existing one suddenly starts reading mail it never touched before. Reviewing connected applications with mail access is one of the advisory's explicit mitigations.
• **Staging and exfiltration.** On-premises, the advisory's tooling archived collected mail to local paths and encrypted it before sending it out. High outbound or upload volume from a mail or web server, especially to an unfamiliar destination, is the exfiltration signal the advisory asks defenders to watch for.
• **Impossible travel and odd hours.** The advisory flags logons outside normal working hours and from unusual geographies. Mailbox access from a location the user has never signed in from, or at a time they never work, is a classic account-compromise indicator.

Tying the signals together

Neither technique is a single alert. DCSync from a non-domain-controller is close to a definitive one, but mailbox harvesting is a weight of evidence: an application identity reading many mailboxes, at an odd hour, followed by a large outbound transfer. The reason to instrument both is that they sit at different stages of the same intrusion. DCSync is how the attacker expands from one host to the domain; mailbox harvesting is how they monetise or exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. the access. Catching either one gives you a chance to contain before the other happens.

The broader point connects back to how these actors operate. As How a Contractor's Scanning Platform Turns a BotnetBotnet🛡️A network of internet-connected devices compromised and controlled by an operator, used for denial-of-service attacks, proxying malicious traffic, credential stuffing or spam. Edge routers are prized botnet hosts because they are numerous, always on, directly reachable and rarely inspected by their owners. Into a Target List explains, the initial compromise is cheap, automated and high-volume. The hands-on-keyboard stage that follows, the DCSync and the mailbox sweep, is where a human operator finally touches your environment and where detection has the most leverage. The deadlines CISA attaches to these vulnerabilities, discussed in Why 'We Patched That in 2015' Is Not an Answer to a KEV Deadline, exist because that first compromise is so easy to achieve against a forgotten host.