GRC work is repetitive by design. Every enterprise customer asks roughly the same 150 questions in a slightly different spreadsheet. Every TPRM assessment wants the same information — your ISO/SOC2 status, your data retention policy, your incident response SLA, your encryption standards — just formatted differently, with different column names, sometimes in Excel, sometimes in a web portal, sometimes in a PDF form.
For a long time, filling these was pure manual labor. Someone on the security team would open the spreadsheet, read each question, pull up our policy documents, write a response, move to the next row, repeat. A single TPRM sheet could take half a day.
Then we started using Claude. Specifically, Claude via Cowork — Anthropic’s desktop tool that gives Claude direct file access and lets you work with documents, spreadsheets, and context that lives on your machine. This post is about what that changed, how we set it up, and how we scaled it across the team.
A Third-Party Risk Management (TPRM) questionnaire is a document an enterprise sends to vendors asking them to prove they’re secure. Banks, large enterprises, and regulated industries all have them. If you’re a B2B SaaS company selling into these sectors, you fill a lot of them.
The typical sheet has sections like:
Each question has a Yes/No/Partial answer column, a Comments/Evidence column, and sometimes a Document Reference column. There can be anywhere from 80 to 400 rows.
The answers don’t change much between customers — your encryption standard doesn’t change because a different bank is asking. But extracting the right answer from your policy documents, framing it correctly for the question, and doing that 200 times in a row is exhausting and error-prone.
Claude, when given your security policies and a TPRM sheet, can read both and fill the questionnaire — accurately, consistently, and in minutes instead of hours.
Here’s the exact workflow we use with Claude Cowork:
Before anything else, gather your organization’s core security documents into a folder:
You upload these to Claude Cowork once. Claude reads them and holds that context throughout your session. Every answer it gives is grounded in your actual policies, not hallucinated.
Drop the customer’s TPRM spreadsheet into Cowork. Claude reads the structure — columns, sections, row-by-row questions — and understands what kind of answer goes where.
A simple prompt gets you started:
1 | Here is our TPRM questionnaire from [customer]. |
Claude works through the sheet section by section. Where it’s confident (encryption standards, access control, certifications), it fills in complete answers. Where a question is ambiguous or the answer requires a judgment call, it flags the row and explains why.
This is the most important part of the workflow. You don’t review every row — you review only what Claude flagged. In practice, out of a 200-row sheet, Claude will flag 10-20 rows that genuinely need a human decision. The other 180 are done.
Those 10-20 flags are often the most important questions anyway — compensating controls, exceptions, questions about subprocessors in specific jurisdictions, questions where your answer might differ by product line.
You handle those, Claude fills the rest. What used to take 4 hours now takes 30-40 minutes.
This is where things get interesting.
In Cowork, you can share a session — the full conversation, context, and uploaded documents — with other team members. This means the context you’ve built (policies uploaded, answers refined, flags resolved) doesn’t have to be rebuilt by the next person who opens a TPRM sheet.
1. A single trained session per document set
One team member sets up the “GRC context” session — uploads all policy documents, adds the standard answers file, and does a few test runs to tune Claude’s response style (tone, length, format of answers). That session is then shared with the rest of the team.
Every new TPRM sheet goes into this session. Claude already knows your policies. You just upload the new sheet and run.
2. Collaborative review in the same chat
When a sheet has complex flags, two people can work in the same shared session simultaneously — one reviewing Claude’s draft answers, the other providing policy context through the chat. Claude sees both inputs and refines accordingly. This is faster than a review meeting.
3. Knowledge transfer for new team members
When someone new joins the security team, they don’t start from zero. They read the shared Claude session — the conversation history shows not just the outputs but the reasoning, the edge cases that came up, the answers we debated. It’s a live documentation of how GRC decisions are made at the company.
After using this workflow across many different questionnaire formats, here’s an honest breakdown:
The last category is exactly what you want humans reviewing. The 80% that Claude handles confidently is precisely the work that was draining the team before.
If you want to replicate this, here’s a concrete starting point.
Folder structure on your machine:
1 | /grc-context/ |
The standard-answers.md file is worth building carefully. It’s a markdown file with sections like:
1 | ## Encryption |
Claude references this file first before going to longer policy documents, which speeds up responses and keeps answers consistent.
Starting prompt for a new sheet:
1 | I'm going to give you a TPRM questionnaire. You have access to: |
What this workflow represents isn’t just automation — it’s a fundamentally different way of staffing GRC work.
Before: one senior security person reads 200 questions, applies policy knowledge, writes responses, gets reviewed.
After: Claude reads 200 questions, applies policy knowledge, writes responses, flags 15 for senior review. Senior person reviews 15 items. Team ships the questionnaire.
The senior security person’s judgment is still in the loop — just on the questions that actually need it. The rest of their time goes to the work that can’t be automated: understanding what a customer actually cares about, negotiating on compensating controls, deciding whether an exception is acceptable.
The shared session model also creates something valuable that’s hard to quantify: institutional memory that’s searchable. When a new kind of question comes up — say, a customer asks about DPDP compliance for the first time — the session captures how we answered it. The next person who gets the same question finds it in the conversation history. Claude already knows the approved answer.
We’re still building this out. A few directions we’re exploring:
GRC questionnaires are a tax on security teams at B2B SaaS companies. The questions are largely the same. The answers are largely the same. The work is largely repetitive.
Claude, given your actual policy documents and a shared working session, turns that work from a half-day task into a 30-minute review. The workflow is:
The output is consistent, policy-grounded, and faster than anything we were doing before. And unlike a script or a template, it actually understands the question being asked.
]]>Before talking about Kerberoasting, ACL abuse, Shadow Credentials, or any advanced Active Directory attack, one thing must be clear: Active Directory is not a hacking topic, it is an identity system.
Most people fail at AD pentesting because they jump directly into tools without understanding how identity, authentication, and trust actually work inside an enterprise network. This article is written to fix that gap.
This is not a cheat sheet.
This is not a command-based tutorial.
This is a mental model of Active Directory — the same model attackers abuse and defenders try to protect.
Active Directory is Microsoft’s centralized identity and access management system. In simple terms, it is the system that answers two fundamental questions across an entire organization:
Who are you?
What are you allowed to do?
When an employee logs into their laptop, accesses a file server, connects to a database, or opens an internal application, Active Directory is almost always involved in that decision. AD is not limited to Windows logins. It quietly controls access across servers, applications, file shares, printers, VPNs, and even cloud services in hybrid environments.
A common beginner mistake is to think of Active Directory as “just users and passwords”. In reality, passwords are only one small part of a much larger identity system.
::contentReference[oaicite:1]{index=1}
Active Directory is organized in layers, and each layer represents a different scope of trust and administration.
At the top is the forest. A forest is the highest security boundary in Active Directory. Everything inside a forest implicitly trusts everything else inside the same forest. In many organizations, there is only one forest, but large enterprises and merged companies may have multiple forests connected by trust relationships.
Inside a forest are one or more domains. A domain is an administrative boundary. Users, computers, and policies belong to a domain. When people refer to something like corp.local or company.internal, they are referring to an Active Directory domain.
Within domains, objects are often organized into Organizational Units, commonly called OUs. OUs are not security boundaries. They exist to organize objects and apply policies. For example, HR computers might live in one OU, IT computers in another, and servers in a separate OU. This structure becomes extremely important later when we talk about Group Policy abuse.
Understanding this hierarchy is critical, because attackers do not “hack a domain controller” first. They move through identity relationships inside this structure.
A Domain Controller, often called a DC, is a server that holds a copy of the Active Directory database and provides authentication services.
The AD database contains every object in the domain: users, groups, computers, permissions, and relationships. This database is replicated across domain controllers to ensure availability and consistency.
From an attacker’s point of view, the Domain Controller is not valuable because it is a server. It is valuable because it is the source of truth for identity. Whoever can influence what the Domain Controller believes about identities effectively controls the domain.
This is why many advanced AD attacks do not require malware, exploits, or file drops. They manipulate identity data instead.
In Active Directory, users represent people or services. Groups represent collections of identities. Computers are also identities.
This is one of the most important concepts to understand: machines authenticate just like users. A domain-joined computer has its own account and its own password. This design enables secure communication between machines, but it also creates opportunities for attackers later in an engagement.
Groups are how access is actually granted. Users rarely receive permissions directly. Instead, users become members of groups, and those groups are granted access to resources. This design simplifies administration, but it also means that group membership is power.
When attackers escalate privileges in AD, they are often manipulating group memberships or abusing permissions that allow them to do so indirectly.
Many people confuse authentication and authorization, but they are not the same thing.
Authentication answers the question of identity. It answers “Who are you?”
Authorization answers the question of access. It answers “What are you allowed to do?”
Active Directory first authenticates an identity using Kerberos or NTLM. After authentication succeeds, authorization decisions are made based on group memberships and permissions.
This distinction matters because an attacker can be fully authenticated as a valid user and still have very limited access. Most AD attacks are about changing authorization, not authentication.
::contentReference[oaicite:2]{index=2}
Kerberos is the default authentication protocol used in Active Directory. Unlike older protocols, Kerberos does not send passwords across the network repeatedly. Instead, it relies on tickets.
When a user logs in, the Domain Controller issues a Ticket Granting Ticket, commonly called a TGT. This ticket proves the user’s identity for a limited time. When the user tries to access a service, such as a file server or database, the user presents the TGT and receives a service-specific ticket.
This ticket-based design improves security and performance, but it also introduces unique attack surfaces. Kerberoasting exists purely because of how Kerberos service tickets are designed and encrypted.
Without understanding Kerberos at this level, Kerberoasting feels like magic. With this understanding, it feels inevitable.
::contentReference[oaicite:3]{index=3}
LDAP, the Lightweight Directory Access Protocol, is how Active Directory stores and retrieves information.
Whenever tools enumerate users, groups, computers, or permissions, they are not “hacking” anything. They are performing LDAP queries. LDAP is designed to be readable by authenticated users because applications need to find users, groups, and attributes.
This openness is necessary for AD to function, but it also means attackers can learn a lot about an environment without triggering alerts. Enumeration is not exploitation. It is simply asking the directory questions.
Group Policy Objects, or GPOs, define how systems behave inside a domain. They control password policies, security settings, startup scripts, software installation, and more.
GPOs are applied based on where an object lives in the AD hierarchy. A single GPO can affect hundreds or thousands of machines. This makes GPOs one of the most powerful features in Active Directory.
From a defensive perspective, GPOs enforce consistency. From an attacker’s perspective, they represent centralized authority. Any weakness in GPO permissions can have massive impact, which is why GPO abuse appears later in advanced AD attacks.
Every object in Active Directory has an Access Control List, or ACL. ACLs define who can read, modify, or control an object.
These permissions are far more granular than most administrators realize. It is possible for a user to have permission to modify a group, reset a password, or change an attribute without being an administrator.
Many of the most powerful AD attacks are not exploits. They are permission abuse. Attackers find unexpected write permissions and chain them together to reach high-value targets.
This is why modern AD attacks are often described as graph problems rather than vulnerability problems.
Active Directory trusts allow identities from one domain or forest to access resources in another. Trusts are essential for business operations, especially during mergers or multi-domain environments.
However, trusts also expand the attack surface. A compromised domain does not exist in isolation if trusts are in place. Attackers can abuse trust relationships to move laterally across domains and even forests.
Many real-world breaches become catastrophic because trust relationships were assumed to be safe without continuous monitoring.
The most accurate way to understand Active Directory is as an identity graph. Users, groups, computers, and permissions form nodes and edges in a massive graph.
Attacks are not about breaking one node. They are about finding a path. Each small permission, each group membership, and each trust relationship becomes a stepping stone.
Tools like BloodHound visualize this graph, but the underlying concept exists whether you use tools or not. Once you understand AD as a graph, advanced attacks start to make sense.
If you skip these fundamentals, advanced topics like Kerberoasting, Shadow Credentials, or AD CS exploitation will feel like isolated tricks. With this foundation, they feel like logical consequences of design decisions.
Active Directory is not insecure by accident. It is complex by necessity. Attackers succeed when complexity outpaces visibility and operational discipline.
Active Directory is the backbone of enterprise identity. Every advanced AD attack abuses something that already exists by design: trust, delegation, permissions, or authentication flows.
Before learning how to break Active Directory, you must understand how it works when it is functioning correctly. That understanding is what separates real security engineers from tool operators.
In the next article, we will build directly on this foundation and explore Kerberoasting, an attack that exists not because of a vulnerability, but because of how Kerberos and service accounts are designed.
Understanding AD makes attacks predictable.
Predictable attacks are preventable.
Core Thesis
Red teams rarely succeed because a vulnerability exists.
They succeed because trust existed where resistance did not.
Red teaming is frequently reduced to the act of exploiting vulnerabilities, demonstrating payloads, or producing proof-of-concept screenshots. This interpretation is convenient, measurable, and easy to report. It is also incomplete. While exploitation may appear in the later stages of an engagement, it is rarely the decisive factor in a real compromise. Systems typically fail long before an exploit is executed.
Modern breaches repeatedly demonstrate that attackers succeed not because defenses are absent, but because trust is misplaced. Identity systems trust tokens. Services trust internal traffic. Pipelines trust dependencies. Applications trust intended usage. Red teams exist to interrogate these trust relationships under adversarial conditions. This distinction separates offensive security as a discipline from vulnerability discovery as a task.
This article examines why red teams do not begin by hacking systems, but by mapping trust. Through real incidents, CVEs, and breach case studies, it demonstrates how trust abuse consistently precedes exploitation and why security programs that ignore this reality remain fragile.
Trust is rarely documented as a first-class design element. Instead, it emerges implicitly from architectural decisions made for performance, convenience, or operational simplicity. A service trusts requests originating from a private network. An application trusts tokens issued by an identity provider. A deployment pipeline trusts that dependencies behave as advertised. These assumptions are often reasonable in isolation, but dangerous in composition.
Unlike cryptographic guarantees, trust assumptions are rarely enforced continuously. They are validated once during design and then assumed indefinitely. Over time, systems evolve, dependencies change, and new integrations appear. The original trust boundary remains, even though the context that justified it no longer exists.
Red teams focus on identifying these outdated assumptions. They examine where trust is implicit, inherited, or transitive. When trust expands beyond its original scope, it becomes an attack surface. At that point, exploitation is optional.
The security industry has trained itself to think in terms of vulnerabilities. CVEs provide structure, severity scoring offers prioritization, and patching offers closure. While this model is useful for software defects, it is insufficient for understanding compromise at the system level.
Many high-impact breaches did not require a novel vulnerability. Instead, they exploited legitimate functionality operating under flawed trust assumptions. The vulnerability, when present, merely accelerated an outcome that was already architecturally possible.
Key Observation
When trust collapses, vulnerabilities become implementation details rather than enablers.
Red teams understand this distinction. They do not ask which vulnerability exists, but which behavior is trusted. When trust collapses, exploitation becomes a formality rather than a requirement.
The SolarWinds compromise is frequently discussed as a sophisticated supply chain attack. While technically accurate, this framing obscures the more important lesson. The failure was not primarily the insertion of malicious code, but the depth of trust placed in the update mechanism itself.
Organizations implicitly trusted that signed updates from a widely used vendor were safe. That trust extended into highly privileged environments, including government networks. Once the update channel was compromised, the attack propagated without resistance.
Key facts:
Reference:
https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a
Red teams studying this incident focus not on the malware, but on why update mechanisms are rarely subjected to adversarial validation.
Identity systems represent one of the most concentrated trust surfaces in modern infrastructure. Tokens, assertions, and sessions are treated as authoritative representations of identity and intent. When identity systems fail, the blast radius is systemic.
Incidents involving misconfigured OAuth flows, improperly validated JWTs, or over-privileged service accounts demonstrate a recurring pattern. The vulnerability itself is often trivial. The impact is severe because identity is trusted everywhere.
A notable example is CVE-2022-3602, a vulnerability in OpenSSL that affected certificate validation and trust chains:
Red teams assess identity not by breaking cryptography, but by tracing where identity is assumed to be correct without verification.
Many organizations treat internal networks as trusted environments. This assumption persists despite years of breach data demonstrating otherwise. Once an attacker gains a foothold, internal trust relationships often provide everything needed to progress.
Real-world breaches repeatedly show that lateral movement succeeds because internal services trust each other implicitly. Authentication is relaxed, authorization is coarse, and monitoring is limited. The attacker does not need to exploit each service individually; they move through pre-approved paths.
Red teams map these trust relationships explicitly:
These paths are rarely visible in vulnerability scans.
Some of the most damaging attacks involve no vulnerabilities at all. Instead, they exploit features behaving exactly as designed. Discount logic, referral systems, quota enforcement, and workflow orchestration are common examples.
Because these failures do not map cleanly to CVEs, they are often dismissed as edge cases. In reality, they represent systemic trust failures. The system trusts that users will not behave adversarially within allowed operations.
Attack Pattern
Legitimate actions
- Unexpected sequencing
- Repetition at scale
= High-impact abuse
Red teams analyze features as attack primitives. They ask how features can be combined, repeated, or sequenced to produce unintended outcomes.
Security controls are often deployed to satisfy compliance or design requirements. Their presence is taken as evidence of security. However, controls that have never been exercised under adversarial conditions remain theoretical.
Examples include:
Red teams validate controls by applying pressure. A control that fails silently under pressure is indistinguishable from no control at all.
Most security processes are optimized for component-level assessment. Code reviews focus on functions. Threat models focus on diagrams. Penetration tests focus on endpoints. None of these processes naturally surface trust assumptions spanning systems.
Organizational incentives compound the issue. Trust failures are difficult to quantify, hard to remediate, and often politically sensitive. It is easier to patch a vulnerability than to redesign an identity model or restrict internal trust.
Red teams operate outside these constraints. Their mandate allows them to question assumptions that other processes accept by default.
At its core, red teaming is not about breaking systems. It is about validating whether trust is deserved. This requires a shift in mindset from vulnerability discovery to adversarial evaluation.
| Traditional Testing | Red Teaming |
|---|---|
| Finds bugs | Tests assumptions |
| Validates controls | Applies pressure |
| Component-focused | System-focused |
| Compliance-driven | Adversary-driven |
When organizations internalize this perspective, security becomes proactive rather than reactive.
Red teams do not hack systems in the way popular narratives suggest. They interrogate trust. They challenge assumptions. They expose where legitimacy is granted without verification and where controls exist without resistance.
Real-world breaches consistently demonstrate that trust failures precede exploitation. Vulnerabilities may accelerate compromise, but they rarely initiate it. Security programs that focus exclusively on patching defects will continue to miss the deeper problem.
Security improves only when trust is tested under adversarial pressure. This site exists to document those tests, the failures they reveal, and the lessons they produce.
All analysis presented here is based on publicly documented incidents and authorized security research. No exploitation guidance is provided. The intent is to improve defensive understanding through adversarial analysis.
]]>