Compromised Admin Account Scenario: Detecting and Stopping Lateral Movement

TL;DR

Compromised admin accounts are often only discovered after weeks because attackers operate within normal business hours and use legitimate tools.
The key detection signals are: logins at unusual times, access to atypical systems, bulk enumeration of directory services, and unusual remote connections.
During containment, the account must not merely be disabled — all associated sessions, tokens, and Kerberos tickets must be invalidated. A simple password reset is not enough.
The credential reset must be comprehensive: not only the compromised account, but all accounts the attacker had access to, and especially the krbtgt account in Active Directory.
Lessons learned focuses on three areas: Why was the account compromised (missing MFA, weak password), why was the compromise not detected earlier (lack of monitoring), and how will lateral movement be restricted going forward (Privileged Access Management, network segmentation).

Thursday, 06:42 AM: A Login Nobody Notices

Weber Logistik GmbH operates three warehouses in Northern Germany, employs 180 people, and runs a typical Windows infrastructure: Active Directory, Exchange On-Premises, an ERP system for warehouse management, a terminal server for dispatchers, and a VPN connection for IT administration at remote sites.

The IT department consists of six people. IT manager Markus Vogt has three domain admin accounts in the company — a situation that a well-designed Privileged Access Management approach should prevent: his own, one for his deputy, and a generic "admin-srv" account used for automated tasks such as software deployment and monitoring. This generic account has the password "Weber2024!", which was set 14 months ago and has not been changed since. The account has no multi-factor authentication because it is used for automated processes and MFA would disrupt the workflow.

On Thursday morning at 06:42 AM, this account logs in to the domain controller via the VPN connection. Markus Vogt is still having breakfast at this time. The automated tasks that normally use the account run between 02:00 and 04:00 AM. The 06:42 AM login goes unnoticed because the security monitoring writes logs but has no real-time alerts configured for admin logins.

The attacker is in.

How the Account Was Compromised

Three weeks before the incident, an employee at Weber Logistik opened a phishing email and entered their credentials on a fake Microsoft 365 login page. Their regular user account was compromised, but that alone would not have caused significant damage. The attacker used this entry point to look around the network.

Using the compromised user account, the attacker logged into the terminal server where all dispatchers work. There, the attacker found what attackers almost always find in Active Directory environments: cached credentials. In this case, the generic admin account "admin-srv" had opened a Remote Desktop session on the terminal server months earlier. The credentials were sitting in the server's credential cache — a known issue that can be trivially exploited with tools like Mimikatz.

The attacker now had a domain admin account. And with it, de facto control over the entire IT infrastructure.

Thursday to Wednesday: Seven Days Undetected

The attacker behaves remarkably disciplined over the following week. They only log in at times that are not entirely unusual for the admin account (early morning, late evening). They use no conspicuous hacking tools, only the tools already present on every Windows server: PowerShell, Remote Desktop, WMI (Windows Management Instrumentation), and PsExec. This technique is called "Living off the Land" and is extremely difficult to detect because the programs used are legitimate system tools.

What the Attacker Does

Days 1 to 2: Reconnaissance. The attacker maps the network. They query Active Directory for all computer objects, user accounts, group memberships, and network shares. They identify the servers, the ERP system, the Exchange server, and the backup server. They discover which users are in which groups and who has access to what.

Days 3 to 4: Establishing persistence. The attacker creates an additional domain admin account ("svc-monitoring") that looks like a legitimate service account. They set up a scheduled task on the domain controller that opens a reverse shell on every reboot. Even if the compromised "admin-srv" account is disabled, the attacker still has a way back into the network.

Days 5 to 6: Identifying data. The attacker searches network shares for valuable data: contracts, customer lists, financial reports, engineering drawings. For a logistics company, customer contracts and freight data are particularly interesting because they reveal business relationships and supply chains.

Day 7: Data exfiltration. The attacker begins transferring selected data to an external server via encrypted HTTPS connections. They use a cloud storage service that is not blocked by the firewall because employees also use it.

Wednesday, 03:30 PM: The Anomaly Becomes Visible

The breakthrough comes through a coincidence that should not have been one. Julia Meier, the deputy IT manager, routinely checks Active Directory group memberships — a task she performs manually every two weeks because there is no automated tool for it. She finds an account named "svc-monitoring" in the "Domain Admins" group.

Julia is puzzled. She knows all the company's service accounts, and "svc-monitoring" is not one of them. She asks Markus Vogt, who does not recognize the account either. She asks the other IT colleagues. Nobody created this account.

This is the moment a routine check turns into a security incident.

The Warning Signs That Were Already There

In hindsight, there were warning signals that would have been caught with active monitoring:

Unusual login times: The "admin-srv" account had been logging in at times that deviated from its normal pattern for a week. Anomaly-based monitoring would have caught this.
Unusual source IPs: The logins came through the VPN connection but from an IP address not assigned to any known IT employee.
LDAP enumeration: Bulk LDAP queries against Active Directory in a short period are a classic sign of reconnaissance activity.
New account in a privileged group: The creation of a new domain admin account should have triggered an immediate alert.
Unusual outbound data flows: The data exfiltration through the cloud storage service was unusual in terms of volume.

None of these signals were detected in real time because Weber Logistik operates no SIEM system (Security Information and Event Management) and has no automated alerts configured for privileged account activity.

Wednesday, 03:45 PM: Containment Begins

Julia and Markus now follow the incident response plan. The situation is delicate because they must assume the attacker may currently be active in the network and could observe their actions — especially if the attacker has compromised the Exchange server and is reading emails.

Communication via Secure Channel

First rule: No communication through the company's internal infrastructure. Julia and Markus switch to their personal mobile phones and an encrypted messenger app. All further coordination runs through this channel.

Immediate Measure 1: Disable Compromised Accounts

Markus disables both suspicious accounts: "admin-srv" and "svc-monitoring." But that is not enough. In an Active Directory environment, Kerberos tickets remain valid even when the account is disabled. A Kerberos ticket has a default lifetime of 10 hours. The attacker could still access resources for hours using an already-issued ticket.

Markus therefore resets the password of the krbtgt account. This is the account that signs all Kerberos tickets in Active Directory. By resetting it, all existing tickets become invalid, and every user and service on the network must re-authenticate. This causes brief disruptions (some services lose their authentication and must be restarted), but it is the only way to ensure the attacker has no valid tickets remaining.

Important: The krbtgt account must be reset twice, with at least 12 hours between resets. The technical reason: Active Directory stores the current and previous password of the krbtgt account, and tickets signed with the previous password remain valid. Only after the second reset are all old tickets definitively invalid.

Immediate Measure 2: Reset All Admin Passwords

Markus resets the passwords of all domain admin accounts, including his own and the deputy's account. He uses passwords of at least 20 characters generated by a password manager.

Additionally, he resets the passwords of all service accounts that were running on the compromised systems. Every account whose credentials may have been in the credential cache of a compromised system must be treated as compromised.

Immediate Measure 3: Disable VPN Access

The VPN connection is completely deactivated. All remote access to the corporate network is blocked until further notice. IT staff at remote sites are informed by phone and work offline temporarily.

Immediate Measure 4: Check Scheduled Tasks

Markus and Julia search all servers for suspicious scheduled tasks and services. They find the reverse shell on the domain controller and remove it. They also check autostart entries, GPO scripts (Group Policy Objects), and WMI event subscriptions that the attacker could also have used for persistence.

Thursday: External Forensics and Damage Assessment

On Thursday morning, the external forensics team arrives. Their task is to determine the full scope of the compromise and ensure no additional backdoors remain in the network.

Forensic Methodology

The forensic investigators work according to a structured method:

1. Create a timeline. Using security logs (domain controller, file server, VPN gateway, firewall), a complete timeline of attacker activities is created. When did they first log in? On which systems were they active? Which data did they access? When did exfiltration begin?

2. Compromise assessment. Every system on which the attacker was active or that communicated with a compromised system is checked for Indicators of Compromise (IoCs). This includes: suspicious files, unknown services, manipulated registry entries, unusual network connections, and modified system files.

3. Quantify data exfiltration. Using firewall logs and proxy logs, the volume of data transferred to which external addresses is determined. At Weber Logistik, the analysis shows that approximately 15 gigabytes of data were exfiltrated through the cloud storage service.

4. Identify persistence mechanisms. The forensic investigators systematically search for all ways the attacker could return: additional accounts, scheduled tasks, backdoors in scripts, manipulated GPOs, Golden Tickets (Kerberos tickets created with the stolen krbtgt hash).

Forensic Findings

The forensic analysis reveals:

The attacker was active in the network for 8 days
They had access to 14 of 22 servers
They exfiltrated data from three network shares (customer contracts, freight data, HR data)
They created a Golden Ticket that would have given them persistent access (now invalidated by the double krbtgt reset)
They read emails from the CEO and IT manager on the Exchange server
Two servers had additional backdoors (web shell on the internal wiki server, manipulated PowerShell profile on the deployment server)

Friday to Weekend: Recovery and Hardening

The recovery phase begins after the forensic investigators confirm that all persistence mechanisms have been identified and removed.

Clean or Rebuild Systems

For each compromised server, an individual decision is made: clean up or reinstall? The rule of thumb: If the attacker had admin rights on the system, a fresh install is safer than cleanup, because it cannot be conclusively ruled out that deeply hidden backdoors were overlooked.

At Weber Logistik, four servers are rebuilt: the domain controller (the heart of the infrastructure — always rebuild when compromised), the terminal server (the attack entry point), the file server (data restored from backup), and the deployment server (manipulated PowerShell profile).

The remaining compromised servers are cleaned, patched with fresh operating system updates, and placed under intensive monitoring.

Credential Hygiene

The comprehensive credential reset continues:

All user passwords are forced to reset (at next login)
All service account passwords are manually changed to strong, unique passwords
The generic "admin-srv" account is not restored; instead, individual service accounts with minimal permissions are created
The krbtgt account is reset a second time (12 hours after the first reset)
Managed Service Accounts (gMSA) are set up for automated tasks, with automatic password rotation

MFA Everywhere

Multi-factor authentication is activated for all admin accounts and all VPN connections. The objection "MFA disrupts the workflow for service accounts" is no longer accepted. For automated tasks, there are technical solutions (Managed Service Accounts, certificate-based authentication) that do not preclude MFA for interactive logins.

Tighten Network Segmentation

Weber Logistik implements stronger segmentation:

Admin workstations are placed in their own VLAN, from which server administration is performed exclusively (Privileged Access Workstation concept)
The domain controller is only reachable from the admin workstations, no longer from arbitrary clients
The terminal server no longer has the right to access the domain controller
Lateral movement between server segments is restricted to defined ports and protocols

Build Monitoring

Perhaps the most important point: Weber Logistik implements a basic SIEM system that monitors the following events in real time and alerts on anomalies:

Admin account logins (every login, not just failed ones)
Creation of new accounts in privileged groups
Changes to Group Policy Objects
Bulk LDAP queries
Unusual outbound data flows
Logins outside of defined working hours
Logins from unknown source IPs

Weeks 2 to 4: Regulatory Notifications and Post-Incident Review

Reporting Obligations

Weber Logistik reviews its reporting obligations:

GDPR: Since HR data and customer contact data were exfiltrated, a reportable data breach has occurred. The notification to the data protection supervisory authority is filed within 72 hours. Affected individuals are notified.

NIS2: As a logistics company with over 50 employees and significant revenue, Weber Logistik must assess whether it falls under NIS2 regulation. If so, an initial notification to the BSI is required within 24 hours.

Criminal complaint: Filed with all forensic findings.

Lessons-Learned Workshop

Two weeks after the incident, Markus conducts a structured workshop. The findings are painful but instructive:

Root cause 1: Generic admin account without MFA. The "admin-srv" account had a weak password unchanged for 14 months and no MFA. This is the most common cause of compromised admin accounts in SME environments. Generic accounts make traceability difficult and are rarely treated with the same care as personal accounts.

Root cause 2: Credential caching on the terminal server. The cached credentials in the terminal server's credential cache enabled the escalation from a regular user to a domain admin. This vector has been known for years and can be mitigated through Credential Guard, restricted admin logins on servers, and regular clearing of the credential cache.

Root cause 3: Lack of monitoring. Not a single warning sign was detected in real time. Without Julia's manual routine check of group memberships, the attacker might have remained undetected for weeks or months.

Root cause 4: Flat network segmentation. The terminal server, file servers, and domain controller were all in the same network segment. The attacker could move laterally without obstacles.

The Action Plan

Measure	Status
Eliminate generic admin accounts, create individual accounts with minimal rights	Implemented
MFA for all admin access and VPN	Implemented
Activate Credential Guard on all servers	In progress
SIEM system with real-time alerts for admin activity	In progress
Privileged Access Workstations for IT administration	Planned (8 weeks)
Network segmentation between server tiers	In progress
Password policy: 90-day rotation for service accounts, Managed Service Accounts where possible	Implemented
Quarterly review of all privileged group memberships	Implemented
Regular tabletop exercises for admin compromise scenarios	Planned (12 weeks)

What This Case Teaches

Compromised admin accounts are the jackpot for any attacker because they represent the keys to the entire kingdom. Lateral movement with admin rights is alarmingly easy in most Active Directory environments because the networks are too flat, too many accounts have too many privileges, and monitoring is too weak.

Generic admin accounts are a relic. They must be eliminated and replaced with individual, MFA-protected accounts with minimal permissions. Automated tasks run on Managed Service Accounts, not on accounts with Domain Admin rights.

The attacker uses your own tools. Living-off-the-Land techniques are so effective because PowerShell, WMI, and Remote Desktop appear on no blocklist. Detection requires behavioral analysis, not signature-based detection: it is not whether PowerShell is used that is suspicious, but when, by whom, and for what.

A double krbtgt reset is mandatory. With any compromise of a domain admin account, the krbtgt account must be reset twice to invalidate Golden Tickets. This is not an optional measure but a necessary one.

Monitoring of privileged accounts is not optional. A well-designed logging and monitoring strategy is the foundation: every login of an admin account, every change to privileged groups, and every creation of new accounts in sensitive groups must be monitored and evaluated in real time. In ISMS Lite, access control concepts can be documented, permissions tracked, and security incidents reviewed in a structured manner. Without this monitoring, attackers remain undetected for weeks or months.

The compromise rarely starts with the admin. In this case, the entry point was a simple phishing email. The path to the admin account led through credential caching on a terminal server. Defense must address the entire attack chain, not just the final step.