1 The Challenge
This is an anonymized account of an incident response engagement, kept accurate to the mechanics involved. The setup will be familiar to a lot of small businesses, which is exactly why it’s worth walking through in detail.
How the machine was set up
The client ran a single physical server for day-to-day business software, and needed to reach it remotely on occasion. Rather than setting up a VPN, port-forwarding had been configured on the router at some point to send RDP traffic straight through to the machine, reachable on the business’s static IP from anywhere on the internet. It had worked without issue for a long time, which is usually how this specific mistake survives as long as it does.
The same machine also held the client’s business-essential data backups, not a second, independent copy elsewhere, but the working backup living on the one machine that was directly reachable from the public internet.
What happened
A publicly reachable RDP port is actively scanned and targeted continuously, this isn’t a targeted attack on this specific business so much as an opportunistic one finding an easy way in. The attacker gained administrative access, most likely through a weak or previously exposed credential, and once inside had no need for any further exploit; RDP access with admin rights is close to full control on its own.
The client discovered the compromise when the machine was no longer accessible and business software stopped functioning. By the time we were engaged, the machine had been wiped, file systems cleared in a way consistent with either deliberate destruction or a failed ransomware deployment, and the attacker still had active access to the machine.
2 Our Assessment
First steps: containment
The first action was taking the machine offline entirely, disconnecting it from the network and the internet, to cut off the attacker’s access immediately and stop any further damage, before touching anything else. Only after the machine was isolated did we move to assessing what had actually happened.
The two mistakes underneath this incident
Strip away the specifics and this comes down to two decisions, both extremely common and both fixable without much disruption: exposing remote access directly to the internet instead of through a VPN or gateway, and keeping the only copy of essential data on the same machine that was doing the exposing. Neither decision was unreasonable at the time it was made, direct port-forwarding is simple to set up, and backing up locally is the default most software does out of the box. They’re just decisions that don’t hold up against a determined or even opportunistic attacker.
3 The Solution
Regaining control
With the machine offline, we worked to regain legitimate administrative access, confirmed there was no remaining attacker foothold (no scheduled tasks, backdoor accounts, or persistence mechanisms left behind), and removed the exposed RDP configuration from the router entirely before the machine went back on any network.
Recovering the data
This was the most delicate part of the engagement. Because the wipe hadn’t fully destroyed every trace of the file system, we were able to recover the business-essential data through disk-level recovery work rather than restoring from a separate backup, there wasn’t one. This is not a guaranteed outcome; a more thorough wipe or a longer window of undetected access often means data genuinely isn’t recoverable. The client was fortunate here in a way that shouldn’t be counted on.
Closing the actual entry point
Recovering the data doesn’t fix what let the attacker in, and reconnecting the machine with the same setup would have simply invited a repeat. We removed the public port-forwarding entirely and replaced it with a properly configured VPN for remote access, enforced MFA on the new access path, and set up logging so any future login attempt, successful or not, is visible rather than silent. See our Remote Access Security service for what this setup actually involves.
We also addressed the backup problem directly: business-essential data is now backed up to a separate, offsite location, independent of the machine it’s protecting, and those backups are tested on a schedule, not just running unverified in the background the way the original setup had been.
4 The Result
The business-essential data was recovered without paying a ransom or losing the working history on the machine, the attacker’s access was fully removed before the server went back online, and the client’s remote access now runs through a VPN with MFA and visible login logging instead of a directly forwarded port. Backups are offsite, independent of the server, and tested on a schedule.
5 Business Impact
For a business running on a single server, losing that machine’s data isn’t a technical inconvenience, it can mean an inability to invoice, ship, or operate at all until it’s resolved. Recovering the data here avoided that outcome, but the client’s exposure to it in the first place (a single point of failure holding both operations and backups) is the more important lesson for any business running similar infrastructure.
If you have RDP, a NAS admin panel, or any other remote-access tool directly forwarded through your router right now, treat that as something to fix immediately, not eventually, it’s one of the most actively scanned-for configurations on the internet. And if your only backup lives on the machine it’s backing up, that’s worth fixing at the same time; see our 3-2-1 backup rule write-up for what a real backup strategy looks like. If you’re dealing with something similar right now, our incident response team is reachable 24/7.