Red Team Diary: From a Single Phishing Email to Domain Admin in Six Days

Representative engagement. Client details anonymized and specifics changed under NDA.

One user clicked a link on a Tuesday afternoon. By the following Monday we owned their Active Directory, had read the payroll export, and had a screenshot of it sitting in our loot folder. Nobody on their side noticed until day five.

This client was proud of their perimeter, and honestly they had reason to be. Hardened VPN, EDR on every laptop, MFA everywhere. So when they scoped this red team assessment, the brief was blunt: stop treating us like a vulnerability scan. Treat us like an adversary who wants something specific. Start from zero access, get to domain admin, and let’s see who notices.

Here is the diary, day by day. The names and numbers are changed. The path is exactly what we walked.

Key takeaways

• A single phished credential is usually enough to reach the internal network. The internet-facing perimeter is rarely the thing that saves you.
• The fastest route to domain admin is almost never an exploit. It is stacked misconfigurations: over-privileged accounts, reused local admin passwords, and weak Active Directory delegation.
• EDR catching a payload is not the same as your SOC responding to it. We are frequently loud and still go unanswered for days.
• Kerberoasting, shared local admin credentials, and lingering privileged sessions are the three findings we report on almost every internal engagement.
• A red team assessment measures detection and response, not just whether a hole exists. That is what separates it from a standard penetration test.

What is a red team assessment, and why not just run a pentest?

A red team assessment is a goal-driven simulation of a real attacker, run against your people, process, and technology at once. The objective is not “find every bug in this app.” It is something a criminal would actually want: read the CFO’s mailbox, exfiltrate the customer database, push a change to production. We pick a path and move quietly toward it.

A penetration test answers where the holes are. A red team answers what happens when someone walks through one. Both have their place. But if you have run a few pentests already and your board is asking whether you would survive a targeted intrusion, the pentest has stopped being the right tool. You need someone playing to win, on the clock, with your defenders unaware of the timing.

Day 1: The email that got clicked

We did not spray thousands of messages. Targeted red team phishing is quiet by design. The first afternoon went to open-source recon: LinkedIn, the company blog, a conference talk one of their engineers had given, a couple of addresses sitting in old breach dumps. That handed us the email naming convention ([email protected]) and enough context to write something a busy engineer would open without thinking.

The pretext was a shared document about an internal tooling migration, aimed at the platform team. Not the CEO. Engineers have broader access and click more links. The landing page was a clean clone of their Microsoft sign-in, served from a lookalike domain we had registered and let age for two weeks so it did not read as freshly minted. We ran it behind an evilginx-style reverse proxy, which means we captured the password and the session cookie. That cookie walks straight past MFA.

Two clicks in the first hour. One completed login. We now held a valid session and valid credentials for a mid-level engineer. Maps cleanly to MITRE ATT&CK T1566 (Phishing) and T1078 (Valid Accounts), and it is where most of our engagements actually begin.

Day 2: Getting a foothold and looking around

Stolen creds are nice. Code execution on an internal host is better. We rode the session to their VPN portal, landed in a low-privilege position, and got a foothold on the engineer’s workstation. That changes the whole game. Now we can enumerate the domain from the inside.

Our first move on any internal network is quiet reconnaissance with BloodHound. Collect session data, ACLs, and group membership, then let the graph tell us where the shortest path to domain admin runs. It is almost never a straight line. There is almost always a line.

# Collect Active Directory data from the foothold (low and slow)
SharpHound.exe --collectionmethods DCOnly,Session --stealth

# Then in the BloodHound UI: mark our compromised user as Owned,
# and run "Shortest Paths to Domain Admins from Owned Principals"

The graph lit up. Our compromised engineer sat in a group with local admin on a cluster of build servers. The kind of over-permissioned group nobody remembers granting and nobody has reviewed since. That was our on-ramp.

Day 3: Kerberoasting and cracking offline

Any domain user can request Kerberos service tickets for accounts that have a Service Principal Name set. Those tickets are encrypted with the service account’s password hash. So you request them, pull them down, and crack them offline where no lockout policy and no alert can touch you. This is Kerberoasting (T1558.003), and it is the most reliable trick we have on internal networks.

# Request roastable service tickets with Impacket
GetUserSPNs.py acme-corp.example/j.doe -request -dc-ip 10.10.0.5 -outputfile roast.txt

# Crack offline with Hashcat (mode 13100 = Kerberos TGS-REP)
hashcat -m 13100 roast.txt rockyou.txt -r best64.rule

One service account cracked in under an hour. The password was Summer2023!, set by a human, on an account with a non-expiring policy and, as it turned out, membership in a privileged group. This is the pattern everywhere: a service account gets stood up once, granted more rights than it needs “to be safe,” and then nobody touches it for four years.

Day 4: Lateral movement and harvesting credentials

Local admin on the build servers meant we could move laterally. We were deliberate here. This is the phase where noisy tooling gets teams caught, and where a competent SOC should have woken up. We avoided writing Mimikatz to disk and pulled cached credentials from memory in-process, then reused the local administrator hash to authenticate elsewhere.

That local admin password was identical on every server in the segment. One hash. Pass-the-hash (T1550.002). Dozens of hosts. On one of them, an administrator had left an RDP session logged in, and harvesting that token handed us a domain admin’s context without ever learning the password. Reused local admin credentials and forgotten privileged sessions are, in our experience, the two things that most often turn a contained foothold into a total loss.

Day 5: Domain admin, and the first phone call

By day five we held a domain admin token. To prove impact without breaking anything, we ran a controlled DCSync (T1003.006) to pull the hash of the krbtgt account, the key that lets an attacker forge golden tickets and persist more or less forever. We did not build the golden ticket in production. We documented the capability and stopped there.

This was also the day the SOC finally called our point of contact. Our lateral movement the day before had tripped an EDR alert. The payload got flagged. But the alert sat in a queue for the better part of a day before anyone triaged it. The technology worked. The response did not. That gap is precisely what a red team assessment exists to measure, and no scanner will ever find it.

Day 6: Reaching the objective

The agreed objective was access to sensitive financial data. With domain admin, that part was trivial. We mounted the finance file share, found a payroll export and a folder of unencrypted customer PII, captured proof, timestamped everything, and pulled out. No data left their environment. Total elapsed time from first click to objective: six days, most of it spent moving slowly on purpose to test whether anyone was watching.

What we found: the real root causes

None of this needed a zero-day. Not one CVE was involved. The entire chain was built from configuration and hygiene:

• MFA that did not survive session theft. Their MFA held up fine against password spray and was useless against a reverse-proxy phish that steals the session cookie. Phishing-resistant MFA with FIDO2 hardware keys breaks the chain on day one.
• A Kerberoastable service account with a weak, static password. A 25-plus character managed secret, or a group Managed Service Account, and it stops being crackable.
• Shared local administrator passwords. Windows LAPS randomizes the local admin password per machine. With it, our pass-the-hash spree ends at exactly one host.
• Detection without response. The alert existed. The runbook to action it in minutes did not.

How this typically gets stopped

Here is the uncomfortable part. Spending more on prevention tools would not have helped this client much. They already had good tools. What they lacked was configuration hygiene and a response process that had been tested under pressure. Rotate and vault service account credentials. Deploy LAPS. Move privileged accounts onto phishing-resistant MFA. Tier your admin accounts so a workstation compromise cannot reach a domain admin token. And above all, run live tests against your SOC until an alert turns into an action instead of a queue entry.

How CyberXplore helps

This is the work we do all year. Our red team assessment service runs goal-driven adversary simulations that mirror how real intruders operate: phishing, foothold, Active Directory attack paths, and quiet lateral movement, so you learn how far someone gets and whether your team catches it in time. You get an attack narrative like the one above, every step mapped to MITRE ATT&CK, plus remediation your engineers can act on Monday morning. If you want to know how your environment holds up, get a quote and tell us what your crown jewels are.

FAQ

How long does a red team assessment take?

Most engagements run three to six weeks end to end, depending on scope and how much stealth you want. The active intrusion in this diary took six days, but real red teams often move slowly on purpose to test detection over time. Recon, reporting, and a debrief workshop add to the calendar.

How is a red team assessment different from a penetration test?

A penetration test enumerates and proves vulnerabilities in a defined scope, usually with defenders aware it is happening. A red team assessment is objective-driven and covert. It tests people, process, and detection together, and success means reaching a goal like domain admin or data exfiltration. If you have never run a pentest, start there. Red teaming assumes a reasonable baseline of maturity.

Will a red team assessment disrupt our production systems?

No. We work under strict rules of engagement agreed in advance, avoid destructive actions, and coordinate with a small trusted group on your side. Proof-of-impact steps like DCSync are done in a controlled way, and we never remove real data from your environment. Safety and reversibility are written into the scope.

Do we need to tell our security team it is happening?

Usually only a small “white cell” of trusted stakeholders knows the timing, so the SOC’s response is genuine. That is the entire point. If defenders are watching for you, you learn nothing about real-world detection. We agree a safe word and escalation contacts up front so nobody chases a false alarm into a crisis.

What do we get at the end?

A full attack narrative, every step mapped to MITRE ATT&CK, evidence for each finding, a prioritized remediation plan your engineers can execute, and a debrief for both technical and executive audiences. The value is not the list of issues. It is the story of how they chained together and what breaks the chain.

How often should we run one?

Annually for most organizations, or after a major change like a merger, a cloud migration, or standing up a new SOC. Environments drift, staff turn over, and the misconfigurations that let us in tend to creep back. A periodic red team assessment keeps your detection and response honest.