Back to posts
Post

How Attackers Breach Companies: Real Attack Scenarios & Vectors

Realistic attack vectors hackers use to breach companies: phishing, exposed RDP, unpatched VPNs, credential stuffing, and supply chain compromises with practical defense tips.

Siber GüvenlikphishingRDP securitycredential stuffingsupply chain attackVPN vulnerabilitiesattack vectors

When people ask me how attackers actually breach companies, I always give the same honest answer: nobody is kicking down your firewall with a zero-day. In my environment, I see the same handful of entry vectors causing incidents over and over. The real attack scenarios that get companies compromised are almost always boring, well-known methods — phishing emails, exposed RDP services, unpatched edge devices, reused credentials, and compromised third-party vendors. If you understand these realistic entry vectors, you can block the majority of attacks without buying expensive threat-hunting tools.

Phishing Still Works Because It Targets People, Not Code

I covered social engineering attacks in a previous post (https://furkanikkan.com/urun/sosyal-muhendislik-saldirilari-insan-faktoru-neden-en-zayif-halka-40), and the situation has only gotten worse. Attackers are not sending sloppy emails with broken Turkish anymore. They are sending localized, context-aware messages that look like they came from your accounting department or your CEO.

The typical phishing-to-breach chain looks like this:

  • Attacker sends a fake invoice email with a .html or .zip attachment
  • User opens it, lands on a fake Microsoft 365 login page
  • Credentials get harvested, MFA prompt gets fatigue-bombed
  • Attacker logs into O365, reads email history, finds internal docs
  • From there, they pivot to VPN or RDP using the same credentials

The pivot step is where it gets dangerous. Once they have a valid O365 session, they do not need malware on the endpoint. They just need to find a VPN endpoint that accepts Azure AD SSO and they are inside your network with a legitimate session token.

Exposed RDP and Brute-Force Attacks on Edge Devices

This one is painful because it is entirely preventable. I still see companies exposing RDP directly to the internet. Not through a VPN, not through a gateway — just 3389/tcp open to the world, sometimes protected by a 12-character password that has not been rotated since the server was built.

Attackers do not manually brute-force these. They use botnets running automated credential stuffing and NLA bypass tools. A typical scan looks like this on the attacker side:

nmap -p 3389 --open -T4 -iL targets.txt

Then they feed discovered hosts into tools that try thousands of credential pairs from leaked databases. If your local admin password is Company2028! and it was reused on three servers, one successful guess compromises all of them.

Here is what I do in my environment:

  • RDP is never exposed directly. Period. Use a VPN or RD Gateway
  • Local admin passwords are randomized per machine using LAPS
  • Account lockout policies are set to 5 attempts / 15-minute reset
  • Failed login monitoring alerts me when a single source hits 10 failures in an hour

If you absolutely must expose a management port, put it behind Cloudflare Access or a zero-trust gateway. There is no excuse for raw RDP on the internet in 2025.

Unpatched VPN Appliances and Edge Infrastructure

This is the vector that makes me lose sleep. Fortinet, Palo Alto, Citrix, Ivanti — every major vendor has had critical CVEs in the past two years, and patching cycles for edge devices are notoriously slow in enterprise environments. You need a maintenance window, you need to test failover, you need sign-off. Meanwhile, attackers are scanning for vulnerable versions within 48 hours of CVE disclosure.

The attack pattern I see most often:

  1. CVE drops on a Tuesday with a public PoC
  2. Attackers mass-scan Shodan / Censys for vulnerable firmware versions
  3. They exploit the vulnerability to read session tokens or write SSH keys
  4. They establish persistence through a rogue admin account
  5. They wait — sometimes weeks — before moving laterally

Warning: Edge device CVEs are not theoretical. If your VPN concentrator is two versions behind and internet-facing, you should assume it is compromised. I treat unpatched edge infrastructure as an active incident until proven otherwise.

Check your exposed services regularly:

# From an external host, verify what you are actually exposing
nmap -sS -Pn -p- your-public-ip-range

If you see management interfaces on that list, you have a problem.

Credential Stuffing and Reused Passwords

Attackers do not need to crack your password if they already have it from another breach. HaveIBeenPwned has billions of credentials, and attackers buy these datasets for pennies. They then run automated tools against your login endpoints — VPN, OWA, RDP web access, admin panels — and try every leaked credential pair.

The math is simple. If you have 500 employees and 15% reuse passwords, that is 75 potential entry points. Automated tools can test all of them in under an hour.

What actually helps here:

  • MFA on everything external. Not SMS — TOTP or hardware keys
  • Password policies that check against breach databases (Entra ID does this natively)
  • Rate limiting and geographic restrictions on login endpoints
  • Regular audits of which accounts have VPN access and whether they still need it

As I mentioned in my ransomware response post (https://furkanikkan.com/urun/ransomware-mudahale-plani-ilk-60-dakika-kontrol-listesi-32), the first 60 minutes after detection matter enormously. But if you prevent the credential stuffing in the first place, you never reach that scenario.

Supply Chain Compromises: The Vendor You Forgot About

This is the hardest vector to defend because it is not your infrastructure. A managed service provider gets compromised, and their tooling — which has access to your environment — becomes the attack path. We saw this with Kaseya in 2021 and SolarWinds before that. It is still happening.

In my environment, I treat third-party access as the highest-risk surface. Here is my checklist:

  • Inventory every vendor with any access to your network
  • Require MFA for all vendor remote sessions
  • Time-box vendor access — enable it only during approved windows
  • Monitor vendor account activity separately from internal users
  • Segment vendor access so a compromised MSP cannot reach production

Note: If a vendor says they need permanent admin access to do their job, ask why. In most cases, they do not. They want it because it is convenient, not because it is necessary.

What Actually Stops These Attacks

You do not need a million-dollar SIEM to block the realistic entry vectors. You need fundamentals executed consistently:

  • Patch edge devices within days of critical CVEs, not months
  • Never expose management ports directly to the internet
  • MFA on every external-facing authentication point
  • Phishing-resistant training that goes beyond "do not click links"
  • Network segmentation so a foothold does not become full domain compromise
  • Monitoring for failed logins, new admin accounts, and unexpected geo-locations

The companies that get breached are not the ones without tools. They are the ones with tools that have not been configured, patches that have not been applied, and policies that exist on paper but are not enforced. Close those gaps and you eliminate the majority of realistic attack paths.

Attackers are lazy in the best way. They go for the easiest target. Do not be the easiest target.


Cover image: CNE CNA C6F · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/94966166@N02/52401640783