Aventura, Florida · serving clients across the United States (305) 404-9404Toll-free (800) 767-8566Emergency? Get a call within 1 hour
Professional services Illustrative engagement

An unpatched on-premises Exchange server was compromised and the attacker reached Active Directory: contained, rebuilt as a redundant DAG and re-tiered

A professional services company of about 250 people in three U.S. offices running its own Exchange and Active Directory.

Scale
~250 mailboxes, 1 Exchange server before and a two-site DAG after, 3 domain controllers, 1 forest
Engagement
9 days from the first call to a trusted domain; the DAG and tiering over the following 10 weeks

The challenge

The company's only Exchange server had been left several cumulative and security updates behind, with its web interface open to the internet. It was exposed to the ProxyShell vulnerability chain (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207), for which patches have existed since 2021. Web shells and unexpected accounts were found, and the service account tied to the backup software showed signs of misuse.

A professional services company ran its own Microsoft Exchange server and Active Directory, and called our team when staff found odd mailbox rules and a backup account signing in at night. The client is not named on this page, and this is an illustrative engagement that describes the kind of work our team does; details are composite. The Exchange server was several updates behind and published to the internet, which made it exposed to ProxyShell, a chain of three vulnerabilities (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207) that Microsoft patched in 2021 and that CISA warned was being exploited.

Containment came first. The server was taken off the internet path, suspect accounts were disabled, and disk, memory and web server logs were preserved before any cleanup, so the evidence survived. Log analysis then showed requests that match public ProxyShell write-ups, a web shell in a web-served directory, and mailbox export requests that told us which mail could have been taken. A server that has run attacker code is rebuilt, not cleaned.

The attacker's next step was Active Directory. Accounts with a Service Principal Name can be Kerberoasted: any domain user can request a service ticket and crack it offline, so a weak service password falls without ever touching the account. One such account was in Domain Admins. We replaced it with group managed service accounts, which use long random passwords that Windows rotates, rotated every privileged credential, and reset the krbtgt account twice, with a wait for replication between resets, to invalidate any forged tickets.

Recovery used a clean build. New Exchange servers on a supported version went into two sites as a database availability group (DAG), with a copy of every database and a file share witness in a third location, so one server or one site can fail without mail stopping. Mail flowed through a temporary path while this was built, and mailbox data moved only after it was checked.

The directory was then re-tiered. Domain controllers, servers and workstations each have their own administrator accounts, privileged users cannot sign in to lower tiers, local administrator passwords are unique per machine, and security updates have a fast path and a staging server. This describes the outcome, not a guarantee against future attacks, and incident work like this runs only under written authorization from the system owner.

What our team delivered

  • Containment first: the server removed from the internet path, suspect accounts disabled, and disk, memory and IIS and Exchange logs preserved before anything was cleaned
  • Scoping from the logs: requests to the Autodiscover and mapi endpoints that match public ProxyShell write-ups, web shells dropped in a web-served folder, and new mailbox export requests, so the team could see what data had been reachable
  • Active Directory attack-path review: service accounts with a Service Principal Name and weak passwords could be Kerberoasted, which means requesting a service ticket and cracking it offline, and one of them was a member of Domain Admins
  • Eviction: privileged and service passwords rotated, the Kerberoastable account replaced by group managed service accounts, and the krbtgt account reset twice with a replication wait between resets to invalidate forged tickets
  • A clean rebuild, not a repair: new Exchange servers on a supported version at two sites, a database availability group with a copy of every database, a file share witness in a third location, mailbox data moved over after being checked
  • A tiered administration model: separate accounts for domain controllers, servers and workstations, Protected Users, Local Administrator Password Solution, no domain admin sign-in on member servers, and a patching calendar with an emergency path for security updates

Result

Mail kept flowing through a temporary path during the rebuild and the attacker lost the directory foothold. The company now loses a server or a site without losing mail, and one stolen service password no longer leads to Domain Admins.

Get this for your company

Related services with fixed prices and a written scope.

Initial assessment of public endpoints

What an attacker can see and reach from the internet: your domains, mail, websites, remote access and cloud exposure.

Report within 5 business days of kickoff

$1,000 per assessment

Details

Insurance-ready bundle

The three things cyber insurers and clients ask for most: an external assessment, a phishing simulation for 25 users and a disaster recovery plan.

Assessment report in 5 business days; plan draft in 15 business days

$5,400 per bundle, phishing simulation for 25 users

Details

Show 2 more

Active Directory health check

Find the misconfigurations that let an attacker go from one stolen password to full control of your domain.

Report within 5 business days

$1,800 per domain

Details

After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.

No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).

Every sign-in, verified

Staff sign in once, but behind the scenes the device, the identity, a phone approval and your access policy are all checked before any app opens, and strangers are turned away.

Every sign-in, verifiedDiagram of user authentication. A user signs in; the device is checked for MDM and Intune compliance; the identity provider, Active Directory or Entra ID, verifies the account; an MFA push is approved on the user's phone; conditional access evaluates the policy; and access is granted to email, ERP and files. On a second pass, a sign-in from an unknown device in a new location is blocked by the conditional access policy. VERIFIED SIGN-INUserSigns inDevice checkMDM · IntuneIdentityAD · Entra IDMFA pushPhone approvalConditionalaccessPolicy checkEmailERPFilesUnknown deviceNew locationApprove?Blocked

Mail that keeps flowing

Incoming mail is authenticated and scanned before it reaches anyone, mailboxes are copied across three regions so a server failure goes unnoticed, and outgoing mail leaves signed and encrypted.

Mail that keeps flowingDiagram of enterprise email flow. Inbound mail from an internet sender reaches the MX edge server running Postfix, where SPF, DKIM and DMARC checks light up in sequence, then passes a spam and malware filter; a spam message is diverted to quarantine. Clean mail is delivered to a mailbox cluster, a database availability group with copies in three regions. On a loop the active server in region A fails and the copy in region B activates automatically, so the next message is still delivered. Outbound mail from the user's mailbox is DKIM-signed and sent over an encrypted TLS connection to the recipient. INBOUNDOUTBOUNDSenderInternetMX edgePostfixSPFDKIMDMARCThreat filterSpam · malwareQuarantineMAILBOX CLUSTER · DAGRegion ARegion BRegion CActiveCopyActiveCopyMailboxUser inboxDKIM signingTLS encryptedRecipientSPFDKIMDMARCSPFDKIMDMARCOffline

Failover in under a second

ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.

Failover in under a secondLine chart over 1.2 seconds. ISP A carries 8 gigabits per second until 300 milliseconds, then drops to zero. ISP B carries nothing until about 650 milliseconds and reaches 8 gigabits per second at 720 milliseconds. Roughly 400 milliseconds of loss in between.Traffic per upstream during a link failureISP A (primary)ISP B (standby)04812Gb/s0200 ms400 ms600 ms800 ms1000 ms1200 msabout 400 ms of loss1 Link to ISP A fails2 BFD: 3 missed hellos (3 × 50 ms), session down3 Routes withdrawn, FIB repointed to ISP BWithout BFD, BGP would wait for the 90 s hold timer (30 s keepalives).

Do you know if your company is safe?

Speak with a security engineer today. The first assessment call is free and confidential.

CallFree assessment