What They Thought Went Right
The firewall project had been planned for months. The old equipment was end-of-life, support was expiring, and the vendor had given them a competitive quote on a newer model.
The migration happened Thursday afternoon. Connectivity tests passed. The IT team celebrated. The director went home.
They thought the problem was solved.
What they didn't verify: whether the security policies from the old firewall had been fully translated to the new one.
What Actually Happened
The old firewall had one rule that mattered: RDP access was restricted to a small list of known management IP addresses.
When the new firewall was configured, that rule was missed.
By 10 PM Thursday — 8 hours after the upgrade — their RDP port was exposed to the entire internet.
At 2:15 AM Friday, automated scanning found it.
At 2:16 AM Friday, the brute-force attack started.
By 4 AM, an attacker had administrator access.
By 7 AM, when staff started arriving, the encryption was complete.
What Was Actually at Stake
An insurance company doesn't just hold its own data. It holds:
- Policyholder personal information — addresses, ID numbers, medical history
- Claims records — including accident details, investigation notes
- Financial documents — contracts with reinsurers, broker agreements
- Active litigation materials — disputes, regulatory inquiries
A breach of this data isn't just operational. It's regulatory. It's reputational. It's years of customer trust, gone in one night.
The Recovery
Friday morning: They called us first — not their IT vendor. This was the right call. A breach at this scale requires forensic expertise, not just IT support.
Friday afternoon: We confirmed the entry vector, isolated the compromised systems, and verified backup status. Two of their three file servers had clean backups — offline copies that hadn't been touched during the migration.
Saturday: Restored the two clean servers. Assessed the third — no clean backup available. Initiated forensic recovery: the ransomware had encrypted sequentially, and files in later-encrypted directories still had recoverable fragments in slack space. We deployed data carving tools to extract from unallocated clusters.
Sunday: Forensics on the third server showed it was partially compromised during the initial access — the attacker had been on the system for 90 minutes before deploying ransomware. During that window, the attacker had browsed directories but hadn't exfiltrated data — the encryption was their primary objective. We extracted what we could from slack space, identified the ransomware variant, and confirmed that the damage was contained.
Monday: Core operations restored. Client communications resumed.
The Numbers
| Systems affected | 3 servers |
| Data recovered | 98% |
| Customer data lost | Zero |
| Recovery time | 72 hours |
| Direct incident cost | USD 38,000 |
| Estimated avoided regulatory exposure | Millions (varies by jurisdiction) |
What Made This Case Common
The mistake wasn't unique. We've seen this exact scenario — firewall migration, missed security rule, automated exploitation — in at least a dozen companies across the region.
The pattern is consistent:
- Old firewall has a security rule nobody fully understood why it existed
- New firewall is configured by checklist, not by understanding
- The rule gets dropped because nobody documented the "why"
- Automated scanning finds the gap within hours
The fix isn't to be more careful during migrations. The fix is to verify the security outcome — not just the connectivity outcome.
What They Changed
Immediately:
- All RDP access restricted behind MFA
- VPN installed for legitimate remote access
- Verification protocol added to all firewall changes
Within a month:
- Penetration test conducted by an external firm — to find the gaps before someone else does
- Change management process updated — security rules now require explicit documentation of purpose before removal
- Backup system redesigned — the third server had a backup, but it was connected to the network. Now it's not.
The Honest Takeaway
This wasn't an IT failure. The IT team was competent. They were working under time pressure, following a process that had worked before.
The failure was systemic: security rules weren't treated as critical infrastructure. They were treated as configuration items. When the configuration changed, the reasoning behind it didn't travel with it.
If you manage IT infrastructure, ask yourself one question about every security rule on your firewall:
"Do I know why this rule exists, and would someone installing new equipment know?"
If the answer is no, write it down before you need it.
For the full emergency checklist, see our ransomware emergency: 5 steps to take right now.
If you're managing IT infrastructure and you're not sure about your current security posture:
We offer security assessments for organizations across the region. We find the gaps — including the ones you don't know are there. Free initial consultation.
- WhatsApp: +852 4666 4940
- Email: IR@ransomrestore.com
- Website: ransomrestore.com
In most emergency cases, we respond within 3 hours.