Anatomy of a Data Breach: How DNS Hijacking Led to a Sophisticated MITM Attack

14 Votes

2025-04-20 Published, 2025-04-20 Updated
1159 Words, 6 Minute Read

Richard (Senior Partner)

Richard has been with the firm since 1992 and was one of the founding partners

The majority of data breaches start with social engineering, then system access then data extraction, a fairly simple yet predictable scenario. Today however was something a little different & technically interesting.

Today, a moderately sized engineering company in England found their cloud hosted CRM was down, their IT guy in trying to diagnose the issue, discovered that the IP Address connected with their CRMs domain name was not the correct address. He corrected it, flushed DNS and everything started working again. Problem solved then?

Literally minutes later, an email was sent to everyone in the company, purporting to be from the IT guy, demanding 2BTC to prevent the release of their data, and an excerpt of the data was provided as proof. At this point they raised a ticket at the HelpDesk, which we picked up and handled a few minutes later. I was notified shortly after and have been following the investigation as it progressed.

Email Compromise

The email account of the IT guy was compromised some time ago (at least 6 months ago) and with that the bad actors had access to approximately 3TB of email going back about a decade. Because their DNS provider (The same as their Registrar) uses an email address to login, and the fact that 2FA was setup to that same email, made access simple.

Now in the DNS control panel, it was easy for the bad actors to change the A record for the CRM hostname.domainname to an alternative server.

The IP address they changed it to, was a server setup to be a 'man in the middle' reverse proxy.

Man in the Middle (MITM)

When you access a website, like www.gen.uk, the connection is encrypted so that your ISP can only see the www.gen.uk, but they don't know what you accessed at that site, or any of the data sent back and forth. This is good, and serves to protect things like credentials in transit.

The ONLY way to bypass this security is:

To compromise the client machine's browser
To compromise the server
To intercept it en-route

Intercepting SSL traffic is hard because the secure connection setup validates that the certificate presented matches the website URL. That is, the certificate presented when you visit www.gen.uk matches www.gen.uk. This validation used to provide strong server validation because obtaining an SSL certificate required money and the supplying of business documents and evidence. This has long since been replaced with 'FREE' certificates that require nothing more than a reachable domain name, so 'validating' that you're at the right domain name is no longer useful.

Once the DNS had been updated to point to the 'new' server, requesting and installing an appropriate SSL certificate was easy.

Next a reverse proxy was leveraged (Apache, Nginx, Express, etc) to 'forward' traffic on to the company's original server, whilst capturing the request (GET/POST) data. That is, everything sent to the server from the user's browser is captured before it's forwarded on. The response from the company's actual server is then received, saved and returned to the user's browser.

This is a near perfect man-in-the-middle attack, capturing data to and from the company's actual server without giving any adverse indications. We know that the DNS was changed 9 weeks ago, we have logs to evidence that, so for 9 weeks, every user's credentials, every request and every response was being logged and analysed.

The Server Compromise

Once the IT guy logged into the cloud hosted CRM, their username (which was confirmed as their email address) and their password was captured at the MITM server. Using this, the bad actors were able to also login to the server, and once in they found a rudimentary 'file manager'. Using the file manager it was quickly determined that the SQLServer was using Windows Authentication - any ASP.net core or aspx code (Yes, ASP.NET was registered with IIS and enabled) has full access to the database.

The bad actors uploaded a file, which loosely translated as 'idiots'.aspx which they left behind for us to find, that when executed with a table name passed, would export that table returning all rows as a text/csv. When passing "список" a list of all tables was returned.

The scope

Using this malicious code, every useful table was exported in full from the database, which is 21k customers, names, addresses, emails, phone numbers, passwords, together with everything ever purchased, the cost of that, agreements, contracts, and lots of other data.

Conclusion

Obviously the company will not be paying the bad actors, and are now in the process of contacting all their customers past and present via email to let them know and to ensure they don't fall foul of secondary attacks (payment redirection, social engineering etc).

Breaches happen all the time, but this was quite interesting, and of course this MITM server could very easily handle the interception of a large number of sites at the same time, and probably does.

Takeaways

This breach, like most could have been prevented but many organisations fail to put in place the policy and processes to do so. Here's a few key takeaways from this specific scenario:

Separate admin email accounts - Never use the same email account for both regular communication and critical administrative access to services like DNS management
Proper 2FA implementation - Use hardware security keys or authenticator apps rather than SMS or email-based 2FA, especially for critical services
DNS monitoring - Implement monitoring that alerts when critical DNS records are changed
Audit Log Analysis - Regularly check email access logs as well as server logs which would have identified both the email and MITM server
Regular email archiving - Don't keep 3TB of email accessible in a single account; archive older messages offline or in a secure repository
Secure development practices - The CRM should never have allowed file uploads with executable extensions like .aspx
Certificate Transparency monitoring - ALL Certificate authorities provide an easy method to list certificates issues for a given domain name

This attack was sophisticated but relied on several basic security oversights. Main-in-the-middle attacks can only be perpetrated by first gaining access to DNS or Domain Registrar (from which DNS can be changed), so protecting this should be high priority.

Comments (1)

Robbie Fuller · 2025-04-27 09:21 UTC
So I asked our IT guy if our DNS was protected with 2fa that doesnt use the same email, and he said they dont even support 2fa!

Informative as always and now we have a job to do. Thank you