Monday. 9:47 AM.
I already have domain admin access. Got it last month when I was probing their Active Directory structure. They told everyone they implemented tiering. What they actually did was rename some organizational units and called it a day. Everyone still has admin rights everywhere. I found a service account on a workstation with cached credentials. Nobody was monitoring credential cache. I had what I needed.
Today I'm using that access to take the next step.
I craft a certificate request for webmail.example.com.
I submit it to their Certificate Authority.
Their CA shouldn't be issuing certificates for that namespace. There is no webmail.example.com server in their infrastructure. An administrator who actually does their job would check the request first. They'd look at the certificate policy. Does the CA allow issuing certificates in this namespace? No. They'd cross-reference against the infrastructure database. Does this server exist in our records? No. They'd ask the obvious question: why are we issuing a certificate for a server that doesn't exist? There's no business justification. The request gets rejected. I never get past the first gate.
But here's what actually happens.
9:48 AM.
The certificate either auto-issues because the template allows Authenticated Users to enroll with no approval required. Or it lands in an approver's queue. The approver has forty-seven items waiting. Budget review. Vendor approval. Incident ticket. Meeting prep. Three other cert requests stacked behind mine. They glance at it. Cert request. Looks normal. Click approve. Move on. They didn't check whether webmail.example.com is part of any current project. They didn't verify it's an authorized namespace. They didn't cross-reference against the infrastructure database. They just approved it because it looked like a certificate request and they had too much else to do.
By 9:51 AM, I have a certificate for a namespace their own CA policy should have rejected.
9:50 AM.
I have domain admin. I use it to modify DNS records. I create an A record for webmail.example.com. It points to my server. When users in this organization type webmail.example.com into their browser, they hit my box instead of the real one.
9:52 AM.
I set up a reverse proxy. When users connect, they see their actual organization's webmail login form. It looks perfect. The SSL certificate I just got from their CA validates. The domain name is correct. Everything is legitimate. They type their username and password. My server captures it. Username. Password. Harvested. Stored.
Then my server forwards the credentials to their real webmail server. If the credentials are valid, they get logged in normally. They have no idea anything happened. If they made a typo, my server sends back the real error from their real server: "Bad username or password. Please try again."
The user thinks they fat-fingered it. They try again more carefully. Same error. They assume something's broken with the system and move on.
I now have valid credentials.
10:15 AM.
admin@example.com : D7$xKm9@
Valid. Logged in. Moved on.
10:42 AM.
finance@example.com : Tr0pic$sun2024
Valid. Logged in. Moved on.
11:15 AM.
operations@example.com : SecurePass#2024
Valid. Now I have credentials for the operations team.
By lunch I have captured real, working credentials for seven users in their organization. None of them know it happened. They think they had a bad day trying to access email.
11:30 AM.
I have domain admin. I use it to check the email system. Specifically, I'm looking for which mailboxes have the most sensitive traffic. Finance? Executive? Operations? I identify the finance manager. Their mailbox would have budget information, vendor negotiations, acquisition discussions. Everything I need to understand this organization's real priorities and vulnerabilities.
I log in using the credentials I just harvested from that user.
I set up an email forwarding rule. Every email that comes into this account gets forwarded to my server. But I'm not done yet.
11:45 AM.
Here's the thing about their MFA: they use email-based OTPs. When you need to authenticate to something, they send a one-time password to your email.
This is security theatre if your attacker controls the email.
I check the forwarding rule. It's working. Every incoming email is being forwarded to my server in real-time.
An OTP arrives. Meant for some other user's authentication. I now have that OTP before they do.
12:30 PM.
I have everything.
A legitimate certificate from their CA for a namespace their own policy should have rejected. Captured credentials for multiple users. Full access to the finance manager's email account. OTP interception capability in real-time. The ability to receive any authentication code meant for anyone in the organization before they see it.
I have domain admin from last month. I have email access from today. I have their OTP infrastructure compromised.
I have complete organizational access. Not through sophisticated techniques. Through a series of operational failures that compounded perfectly.
What should have happened
Now let me show you what should have happened at every single step.
The certificate request arrives. The system should check: is this request associated with a project? Is there a change ticket? Is there business justification? There isn't any. The request should be flagged for additional scrutiny. An approver should ask the question: why are we issuing a certificate for webmail.example.com? What business need does this serve? There's no legitimate business need. The request gets rejected. I never get past the first gate.
But that didn't happen because there's no Certificate Policy and Practice Statement. The CA doesn't have one. There's no document defining what the CA is supposed to do. What namespaces it can issue for. What validation is required. What business justification is needed. How approval should work. Without a CP/PS, there's no policy to enforce. There's no standard. There's no control. A certificate request is just a technical artifact. The approver has no baseline to check against. They have no way to know whether this certificate serves an actual business purpose or is a compromise attempt.
So the request either auto-issues or gets rubber-stamped.
The CA should have a Certificate Policy and Practice Statement that explicitly defines which namespaces it's authorized to issue certificates for. Not every namespace. Specific, approved namespaces. When a request arrives for webmail.example.com, the system should check: is this namespace in the CP/PS? Is it authorized for issuance? It's not. The request gets rejected automatically. The CA refuses to issue a certificate for an unauthorized namespace regardless of who requested it or what approval they had.
But that didn't happen because there is no CP/PS. Without it, the CA has no defined policy restricting issuance. The CA allows issuing for any namespace in the organization's domain. There's no explicit whitelist of authorized namespaces. There's no policy document to enforce. There's no check preventing certificates for namespaces the organization doesn't actually use.
So I get the certificate.
Even if project validation and namespace validation had failed, the approver should still verify the request. They should check: is this server in our infrastructure? Is this request expected? Is this namespace legitimate? If they can't answer those questions confidently, they should reject it and ask for clarification.
But that didn't happen because the approver is overloaded. They have too many requests in their queue. They're making decisions under time pressure. They approve without validating. They're rubber-stamping rather than reviewing.
So I get the certificate.
The organization should monitor DNS changes. New A records, CNAME records, anything. When a new record appears for webmail.example.com pointing to an unexpected IP address, an alert should fire. The DNS team investigates. They find that someone with domain admin access created a DNS record pointing to an external server. They immediately correct it. They investigate how the attacker got domain admin in the first place.
But that didn't happen because there's no DNS change monitoring. Changes happen silently. Nobody notices that webmail.example.com is now pointing to an attacker's infrastructure.
So I redirect DNS.
The organization should monitor authentication patterns. Multiple login failures from the same IP. Odd login patterns using real credentials but with suspicious behaviour. When users start getting bad password errors and then trying again from the same IP, that's suspicious. An alert should fire. The security team investigates. They find that users are authenticating to an attacker-controlled server. They block the infrastructure. They invalidate the compromised credentials.
But that didn't happen because there's no authentication anomaly detection. Failed logins are logged but not analyzed. A pattern of failed logins followed by successful ones looks normal. Nobody notices the pattern that indicates credential harvesting.
So I harvest credentials.
Every email forwarding rule that gets created should trigger an alert. Who created it? What's the destination? Is this expected? For the finance manager, who never forwards email, a new rule suddenly forwarding to an external address should raise immediate flags. The rule gets disabled. The account gets investigated for compromise. The user gets notified.
But that didn't happen because email forwarding rules are not audited. They can be created without triggering alerts. An attacker with compromised credentials can set up forwarding rules and nobody notices until a compliance audit happens months later.
So I set up forwarding.
The organization uses MFA. Email-based OTP. This is inherently weak because if email is compromised, MFA is compromised. The right approach is MFA should never depend on email as the delivery mechanism. Hardware tokens. Authenticator apps. Push notifications to a separate app. Anything that doesn't route through email.
If email-based OTP is unavoidable, at least monitor for impossible patterns. If the same person's OTP is being used from two geographically impossible locations in the same minute, that's suspicious.
But that didn't happen because email-based OTP is the only MFA mechanism. There's no detection for OTP reuse patterns. An attacker intercepting email sees every OTP before the user does.
So I intercept OTPs.
The organization should have implemented true tiering. Domain admins have separate accounts and workstations from regular users. Admin access is not cached on user workstations. Service accounts are rotated regularly. An attacker can't get domain admin credentials by finding a cached service account on a regular workstation.
But that didn't happen because the organization said they implemented tiering. They renamed some organizational units. They called it a day. Everyone still has admin rights on most systems. Service account credentials sit in the credential cache on workstations. An attacker with a single compromised workstation can escalate to domain admin in minutes.
So I had domain admin from the start.
The timeline
9:47 AM: Certificate request submitted.
9:51 AM: Certificate issued. Either auto or rubber-stamped.
9:52 AM: DNS record created pointing to attacker's server.
10:15 AM: First user credentials harvested.
11:30 AM: Email account compromised via harvested credentials.
11:45 AM: First OTP intercepted.
12:30 PM: Complete organizational access achieved. Domain admin. Email access. OTP interception.
Total time: 2 hours 43 minutes. Zero detection. Complete compromise.
How do you stop this attack?
You require project validation for every certificate request. Every certificate must be associated with a project or change ticket. There must be business justification. An approver can't approve a certificate without understanding what it's for and why it's needed.
You define and enforce namespace policy. The CA has a certificate policy that explicitly lists which namespaces it will issue certificates for. Any request for a namespace outside that list is rejected automatically.
You validate against infrastructure inventory. Before approval, the system checks: does this server exist in our infrastructure database? Is it registered? Is it authorized? If not, the request gets flagged or rejected.
You monitor DNS changes. Every DNS record creation or modification is logged and alerted. Unexpected A records pointing to external IP addresses trigger investigation immediately.
You monitor authentication patterns. Failed logins are analyzed. A pattern of multiple failed logins followed by successful ones from the same IP indicates credential interception. Alert. Investigate. Block.
You audit email forwarding. Every email forwarding rule creation is logged and alerted. Forwarding to external addresses requires approval. Forwarding rules on sensitive accounts trigger alerts automatically.
You use hardware-based MFA. Email-based OTP is inherently weak if email is compromised. Use hardware tokens, FIDO2 keys, or authenticator apps. Anything that doesn't depend on email.
You implement true tiering. Not organizational unit renaming. Actual tiering. Domain admins have separate accounts and workstations. Admin credentials are not cached on user machines. Service accounts are rotated. Privileged access is monitored.
You use operational tooling that forces these validations to happen whether the approver is busy or not.
Where Truvald fits
Truvald does this at the certificate level. It validates every request against project association, namespace policy, and infrastructure cross-reference. It surfaces a decision: approve or reject.
I don't get the certificate at 9:51 AM. The request gets rejected at 9:48 AM.
The cascade of failures never happens because the first failure is prevented.
Eight defences, all absent
This attack worked because eight separate defences failed simultaneously. Not because they were all terrible. Because they were all absent or ineffective.
The certificate request should have been rejected at the template level, the approval level, the DNS level, the authentication level, the email level, and the MFA level. It wasn't rejected at any of those levels.
An organization with even three of these controls in place would have caught this attack by lunchtime. An organization with all eight would never have gotten to 9:51 AM.
You don't need perfect security. You need layered security that actually works. Most organizations have the layers drawn on a diagram. Few organizations actually implement them operationally.
Truvald makes one of those layers operational by default. It forces project validation, namespace validation, and infrastructure cross-reference.
But the real fix is the organization doing their job: implementing the rest of the layers, operating them consistently, monitoring for gaps when they fail.
Because if those gaps exist, an attacker like me will find them. And by lunchtime, I'll have everything.
Hiro out.