Hackers Don't Need to Breach Your Firewall: When Attackers Log In With Your Employees' Own Accounts

Quick answers

• Modern attackers often never breach the firewall at all — in many intrusions they simply log straight into the internal network with a compromised legitimate account: a VPN account, a Microsoft 365 account, or an admin account.
• A firewall controls traffic according to policy; it cannot verify the human behind an allowed connection is really the employee.
• One compromised account is a starting point, not the end point: from a login session stolen through phishing, an attacker can escalate privileges and move laterally if access rights are too broad and the internal network is not segmented.
• Five things every business should review now: control privileged accounts; use phishing-resistant MFA (FIDO2/passkeys); implement real network segmentation; manage service accounts; monitor behavior after sign-in.
• The core principles are Defense in Depth and Zero Trust: design the system so a single mistake — one employee clicking a bad link, one leaked account — cannot bring down the whole infrastructure.

What is identity security?

Identity security is the set of measures that protect the accounts, passwords, login sessions and access rights of users, applications and services in an IT system. As infrastructure opens up — remote work over VPN, email and applications moving to cloud services such as Microsoft 365 — identity becomes the "new security perimeter": whoever can prove they hold a legitimate account is let through by the system, no matter where they are sitting.

Why don't hackers need to get past the firewall?

Picture a company that has invested properly in its network edge: a next-generation firewall, full licensing, IPS, antivirus, web filtering and application control all switched on. The dashboard is green, thousands of suspicious access attempts are blocked every day, leadership is reassured, and so is the IT team.

Then one day, the attacker appears inside the internal network. There is no attack alert from the Internet, nobody "breaks" the firewall, and there is no headline DDoS. There is just a VPN account logging in successfully at 2 a.m. — valid username, correct password, MFA confirmed. The system opens the door, because as far as the firewall is concerned, that is a permitted connection.

This illustrative story exposes an assumption that used to be common in traditional network design: the outside is untrusted, the inside is safe. That assumption no longer holds. When a VPN account is taken over, or an internal computer is infected with malware, the attacker starts operating from a position the system has already authorized. They do not need to defeat the firewall from outside — they pass through the very connections the firewall is configured to allow.

Can a firewall protect a business against a compromised account?

Only partly. A firewall remains an essential layer at the network edge — filtering traffic, blocking unauthorized connections, keeping logs. But its limits must be understood:

A firewall controls traffic according to policy. It cannot, by itself, guarantee that every action passing through an allowed connection is performed by a legitimate user.

In other words, the firewall is like a gate guard checking documents: valid papers, and you are waved through. If the attacker is holding the real "papers" — an employee's actual account and login session — the guard has no basis to refuse. The remaining work belongs to the layers behind the gate: identity management, authorization, network segmentation and behavior monitoring.

How dangerous can one compromised employee account be?

Consider a fairly typical company of about 500 employees: Active Directory manages all accounts, staff work remotely over VPN, departments share a file server, the ERP software connects to a database, and application servers sit in their own VLANs.

One day, an accounting employee receives a phishing email asking them to "re-confirm your Microsoft 365 account". They click the link, sign in, approve the MFA prompt — but the login page is fake, part of a phishing attack able to steal the authentication session. The attacker obtains a valid logged-in session without ever learning where the real password leaked.

One technical point deserves emphasis: taking over a Microsoft 365 account does not automatically mean being able to log into the VPN or the internal Active Directory. That depends on the identity architecture, account synchronization, single sign-on (SSO), access rights and the protective layers in place. But wherever weak links exist — passwords reused across systems, overly broad access rights, poorly controlled privileged accounts — one compromised account becomes a springboard for widening the intrusion. A compromised account can be the starting point of an attack, not necessarily its end point.

What are the risks of Domain Admin and service accounts?

If an employee account is an "ordinary key", a Windows/Active Directory environment holds two far more dangerous kinds of keys:

Domain Admin — the master key. In many environments, technicians once used a Domain Admin account for everything: installing software, joining domains, remoting into workstations, configuring servers, even logging into a user's PC just to fix a printer. Convenient — one account that can do almost anything. But if those privileged credentials leak, the consequences can be company-wide: changing Group Policy, creating new privileged accounts, affecting every computer in the domain or destroying critical services. A misused admin account can turn one workstation's incident into a crisis for the entire system.

Service accounts — the forgotten spare keys. These are the accounts that run SQL services, power ERP applications, execute automated tasks or integrate systems with each other. Many were created years ago: passwords that almost never change, no clear owner, rights far beyond what the service actually needs, sometimes one account shared by several services. When a review finally happens, nobody dares change the password — because nobody knows which application will "die" if they do. Identity management is therefore not only about employee accounts: machines, applications and services also have identities, rights and lifecycles that must be managed.

Account type	Typical risk	Controls to apply
Employee account	Phishing steals the password or the login session	Phishing-resistant MFA, training to spot fake email, device and session control
VPN account	Taken over and used to enter the internal network directly, often off-hours	Strong MFA, limit which systems are reachable after VPN sign-in, alert on unusual logins
Domain Admin	A single leak hands over control of the whole domain	Separate admin accounts from daily accounts, PAM, Just-in-Time access, least privilege
Service account	Static passwords for years, no owner, excessive rights	Inventory and assign owners, review rights, prefer gMSA or a secrets vault, remove unused accounts

What should a business do to stop an attacker from going further after sign-in?

Instead of only thinking about buying more security appliances, a business should start by reviewing five issues:

First — control privileged accounts. Separate admin accounts from everyday work accounts, restrict privileged sign-ins on untrusted workstations, and apply privileged access management (PAM), Just-in-Time access and the principle of least privilege where appropriate.

Second — make MFA strong enough. MFA via SMS or ordinary push notifications can still be abused by some forms of phishing, notably attacks that steal the login session. For important accounts, prefer phishing-resistant methods such as FIDO2 security keys or passkeys, and control login sessions, devices and unusual authentication signals.

Third — segment the network for real. Splitting VLANs is not the same as safe network segmentation: if the VLANs still route freely to each other under overly permissive policies, the split is only organizational. The connection flows between user, server, management, backup and other sensitive zones must be explicitly controlled.

Fourth — manage service accounts. Inventory every service account, assign an owner, review its rights, remove accounts that are no longer used, and prefer gMSA or a proper secrets-management mechanism instead of letting static passwords live for years.

Fifth — monitor behavior after sign-in. An account logging in successfully at 2 a.m. is not, by itself, proof of an attack. But if that account suddenly accesses a long list of servers, changes privileged group membership or does things it has never done before, the system must detect and alert. Security should not end at the login screen.

What do Zero Trust and Defense in Depth mean in practice?

The biggest lesson from the story above: security cannot rest on the carefulness of individual employees alone. You cannot demand that hundreds of people never, ever click the wrong link; you cannot expect every technician to never make a mistake; and you cannot trust that every account will stay safe forever.

Instead, the system must be designed so that a single error does not easily drag the whole infrastructure down with it:

• One phished employee should not mean the attacker controls the entire domain.
• One malware-infected computer should not automatically reach the backup system.
• One compromised VPN account should not be able to roam the whole internal network.
• One leaked admin account should not be the end of every protective layer.

That is the practical meaning of Defense in Depth and Zero Trust (never trust by default): not buying more and more appliances, but building multiple independent layers of control, so that when one layer fails, the others still have a chance to stop or limit the damage. Every IT team should be able to answer one question: if tomorrow a hacker signs in successfully with a legitimate account in your company, what protective layers remain to stop them from going further? If the answer is only "we already have a firewall", it is time to re-examine the security architecture — because sometimes the hacker does not need to break down the door; they only need a key that we ourselves accidentally let slip. And the scariest part is not that they got in — it is that, once inside, so few doors are left to make them stop.

Frequently asked questions

We already have a strong firewall — do we still need to care about account security? Yes. A firewall blocks unauthorized connections at the network edge, but it cannot tell a real user from an attacker using a compromised legitimate account. Identity security is a mandatory additional layer, not an optional extra.

Is MFA by SMS or push notification safe enough? Not completely. Some modern phishing attacks can steal the entire login session even after the user has approved MFA. For important accounts, use phishing-resistant methods such as FIDO2 keys or passkeys, combined with device and session controls.

Does splitting VLANs already count as secure network segmentation? Not necessarily. If traffic between VLANs is still broadly allowed, the segmentation is only organizational. Real segmentation comes with a specific policy controlling each connection flow between user, server, management and backup zones.

What is a service account, and why is it a forgotten risk? A service account runs services, applications or automated tasks. They are dangerous because their passwords often go unchanged for years, they have no clear owner, and they hold more rights than needed — a "spare key" that attackers are eager to find.

How can you detect an attacker using a legitimate account? Through monitoring behavior after sign-in: unusual off-hours logins, access to many unfamiliar systems, changes to privileged groups, actions that never appeared in the account's history. These signals need to be recorded and alerted on in time.

---

Source: the article "When security is no longer IT's business alone — #03: Hackers don't need to get past the firewall; sometimes they log in with your employees' own accounts" by Dũng Nguyễn, posted in the Digital SArch Community group on Facebook on November 3, 2026. The scenarios in the original article are illustrative of identity and access management risks.