Hlawulekani Maluleke

the setup

Billion Group needed to move off an ageing on-premises Exchange 2012 server and onto Microsoft 365. On the surface, that's a routine cutover. Underneath, it was anything but: 55 mailboxes, several of them large, adding up to roughly 3TB of mail in total — and licensing that was split between Microsoft 365 Business Standard and Office 365 E3, so provisioning had to be mapped correctly per user before any data could land. The client's brief was firm on one point: they wanted their full mail history intact, not a fresh start.

the complication

When the outgoing IT provider handed the environment over, the Exchange server came with an expired Exchange Server license. That one detail ruled out the standard migration toolkit. With Exchange no longer licensed to run its full services, there was no supported way to connect Exchange Management Shell or the Exchange Admin Center to it, and no live mailbox database to run a cutover or staged migration batch against — the usual New-MigrationBatch / New-MoveRequest route simply wasn't available. What we did still have was the raw data: the Exchange database (.edb) file itself, sitting on disk with three years of history inside it and no active service left to serve it.

the approach

1. 01Assess the source offline. With the store unmountable through Exchange, we treated this as an offline data-recovery exercise rather than a live migration — working directly against the .edb file rather than a running mailbox server.
2. 02Extract with EDBMails. Native Exchange migration tools all assume a functioning Exchange organisation behind them, so we brought in EDBMails, a third-party EDB recovery tool, to open, scan, and read mailbox data straight from the database file — no active Exchange services required.
3. 03Convert EDB to PST, mailbox by mailbox. Extracted each of the 55 mailboxes individually and converted them to PST, preserving folder structure and item counts rather than flattening everything into a single dump.
4. 04Provision Microsoft 365 ahead of import. Assigned licences per user — Business Standard or E3, matched to what each user was actually sold — so every mailbox existed with the correct feature set before any historical mail landed in it.
5. 05Import into Exchange Online. Uploaded the converted PSTs into each user's new Microsoft 365 mailbox in a controlled order, so the largest mailboxes didn't stall the batch behind them.
6. 06Verify. Spot-checked folder structure and item counts per mailbox against the source PST to confirm nothing was silently dropped in the EDB-to-PST conversion.
7. 07Manage the client relationship throughout. An EDB → PST → Microsoft 365 path takes longer than a same-day cutover. We kept Billion Group updated mailbox-by-mailbox as the migration progressed, rather than leaving them waiting on one final "it's done" message.

the outcome

All 55 mailboxes landed on Microsoft 365 with their historical mail intact, correctly split across Business Standard and E3 licensing — delivered from a source environment that, on paper, no longer had a working Exchange license to migrate from. Billion Group kept the years of email history they asked for, and the constraint that would normally stall a migration became a detour rather than a dead end.

the incident

It started with a single phishing email. The client's CEO received a message with a link, clicked it, and unknowingly installed a credential-scraping tool that quietly captured login details as they were typed. The attackers — operating under the name Dragonfly — used those harvested credentials to reach the client's primary domain controller and deploy ransomware, encrypting the files stored on it. The client ran two servers: the domain controller, which held the bulk of the company's critical files, and a separate application server. Only the domain controller was hit — the application server was never touched, and that distinction turned out to matter a great deal.

the response

As soon as the intrusion was reported, the affected system was isolated immediately — disconnected from the network to stop the ransomware spreading further and to cut off any live access the attackers still had. The attackers left a ransom note demanding $2 million for a decryption key, with an email address for "negotiation." The stance from the outset was firm: paying was never on the table. Ransom payments fund further attacks, there's no guarantee a decryption key even works, and paying marks an organisation as a target for repeat extortion.

the investigation

With payment ruled out, the priority became scoping the breach rather than negotiating with it. Working on the assumption that any credentials exposed to the scraper were compromised, we traced exactly how far the attackers had gotten. The blast radius was confirmed as contained to the domain controller — the application server was clean. The investigation also surfaced the attackers' second move: they had logged into Azure Backup and deleted the client's cloud backups, a deliberate step to remove any recovery path that didn't involve paying. Fortunately, some of those backups were also being mirrored onto the untouched application server — giving us a clean, verified recovery point the attackers didn't know existed.

the recovery

1. 01Clean environment. Rebuilt on a clean footing rather than trusting anything on the compromised domain controller, on the assumption that persistence mechanisms could be hiding anywhere on it.
2. 02Patch. Identified and closed the vulnerability that let the phishing payload succeed in the first place, before reconnecting anything to the network.
3. 03Reset credentials. Reset every credential that could plausibly have been exposed to the scraper, not just the CEO's account.
4. 04Rebuild systems. Rebuilt the domain controller from clean media rather than restoring the compromised image, to avoid carrying over any dormant malware.
5. 05Verify backups. Confirmed the integrity of the mirrored backup copies on the application server before relying on them for restoration.
6. 06Restore data. Restored the client's company files from the verified mirrored backups onto the rebuilt environment.
7. 07Monitor. Watched authentication logs and network activity closely after recovery to catch any sign the attackers still had a foothold.

hardening after recovery

Recovery on its own wasn't the finish line — the environment was hardened to close the exact path the attackers used and reduce the blast radius of anything similar in future:

• Reset privileged credentials
• Enabled MFA everywhere possible
• Removed unnecessary administrator accounts
• Disabled obsolete VPN/RDP access
• Patched the vulnerability that was exploited
• Deployed and verified EDR / endpoint protection
• Segmented servers and workstations
• Separated backup credentials from normal domain credentials
• Kept at least one offline / immutable backup
• Set up close monitoring of authentication and network activity

the outcome

Despite a $2 million extortion demand and a deliberate attempt to destroy the client's cloud backups, the organisation recovered its systems and data without paying — the result of isolating fast, refusing to negotiate, and a mirrored backup copy the attackers didn't know was there. The incident also reshaped the client's security posture going forward, from MFA enforcement to separated backup credentials, directly addressing how the attackers got in.