Remote Access: How Most Ransomware Gets Into Egyptian Companies

In nearly every ransomware incident we have handled, the entry point was one of three: an email attachment, an unpatched vulnerability in an exposed service, or — most commonly — a remote access service left open to the internet.

The story repeats with the same details. The port was opened one afternoon so an employee could work from home, or so the accounting software vendor could log in for maintenance. It was temporary. It was never closed. Two years later nobody remembers it is open — but automated scanners do.

Why exposed RDP is this dangerous

Port 3389 open on a public address is discovered within hours. The attacker does not need to know your company or target it; there are operations continuously scanning the entire address space looking for exactly this.

Then the password guessing starts — thousands of attempts a day, and they do not all need to succeed. One account with a weak password, or an old vendor account nobody disabled, is enough. Once in, the attacker is inside the network as a real user. The firewall is not in their way, because they came through the door.

Three levels, weakest to strongest

Level one: changing the port — an illusion, not a fix

Moving RDP off 3389 stops only the crudest scanners. Any modern one sweeps ports and identifies the service from its response, not its number. This buys you weeks and gives you a false sense of security for years.

Level two: a VPN in front of everything

The base rule: never publish an administrative service directly to the internet. Remote access goes through a VPN tunnel that terminates at the firewall.

That changes the equation. The only thing exposed is a VPN service designed to be exposed and patched accordingly, rather than a desktop service that was never designed for it. And every attempt is logged in one place.

The FortiGate and Sophos appliances we supply include this capability in the device itself — no extra server needed. But turning it on requires real configuration: a certificate, a user group, and an access policy limited by destination.

Level three: multi-factor authentication — the decisive item

A VPN with only a password postpones the problem rather than solving it: passwords leak, get guessed, and get reused elsewhere. A second factor is what makes a stolen password worthless.

This is the highest impact-per-cost step on the entire list. If you implement only one thing from this article, make it this one.

Four measures that complete the picture

• Restrict the source. If the vendor connects from a fixed address, allow that address only. The simplest and most effective control there is.
• Restrict the destination. A VPN user should not reach the whole network — only the servers they need. This is what stops ransomware spreading laterally if an account is compromised.
• Time-bound access. A vendor account is enabled when needed and disabled afterwards. Permanent vendor accounts are the single most common forgotten door we find.
• A monthly rule review. Five minutes a month on the firewall rule list: what is this rule, who asked for it, is it still needed?

How to know where you stand

Three questions. If the answers are not immediately available, something is worth checking:

1. What services are published from your network to the internet right now? (The NAT or port-forwarding list on the firewall answers this in a minute.)
2. Does any of them require a second factor?
3. When did anyone last review that list?

Companies that get hit are rarely the ones that neglected security on purpose. They are the ones that opened a door for a good reason and forgot it was still open. A periodic review is far cheaper than incident response.