Welcome to the final installment of The Attacker’s Playbook. So far, we’ve covered exploiting the human element (Part 1), finding unlocked doors (Part 2), and using forgotten keys to the kingdom (Part 3) to get inside a network.
But initial access is just the beginning. The real damage is done when we move through the internal network, abusing trust and misconfigurations to turn a minor foothold into a major compromise.
Active Directory (AD) is the heart of most corporate networks, but its permissions can become a tangled “rat’s nest” of complexity. An automated vulnerability scanner can’t understand the intricate web of trust relationships that a human attacker can exploit.
The Flaw: A standard user account may seem harmless, but it could have a hidden, indirect path to administrative power. It’s not uncommon to find that the default “Domain Users” group has overly broad permissions, such as the ability to log into nearly every computer on the network, including servers.
Specifically, we look for the “GenericAll” permission. This allows one group to fully control another object. Even if the target account is disabled, an attacker with GenericAll rights can enable it and abuse those permissions.
The Attack: As we acquire user accounts, we use Bloodhound to map complex relationships and find unexpected privilege escalation paths.
This exact flaw was enumerated on a recent pentest where the “Domain Users” group had GenericAll access to a disabled service account. Seemingly for no reason, this permission existed on an account no one was monitoring.
From there, we enabled the account, reset the password, and masqueraded as that service account on the network. We discovered this service account had interesting permissions, including the ability to modify the password of a Domain Administrator.
After confirming this action was allowed within the Rules of Engagement (ROE), the team abused these permissions to take over the entire AD forest and ultimately the network.
The Result: By manually navigating this maze, we can turn a low-privilege account into a full Domain Administrator, demonstrating a critical risk that no vulnerability scanner would discover.
Mitigation Strategies: Active Directory is a common target because it’s often a “rat’s nest” of complex permissions.
The most damaging breaches rarely rely on a single vulnerability. Instead, they emerge from creative chaining of minor, overlooked issues, a forgotten file, an exposed port, a default password—into a pathway through the maze of internal trust.
Key Takeaways:
Defending against these threats requires adopting the attacker’s perspective. This is where red team expertise provides the greatest value, simulating real-world thinking, not just automated scans.
Your security journey doesn’t end with this playbook. Contact us to learn how our expert-led penetration testing helps organizations secure their networks from the inside out.
That wraps up The Attacker’s Playbook. But your security journey shouldn’t stop here. Check out our deeper dives on Active Directory in “Abusing Active Directory: Down the Rabbit Hole We Go,” and watch this short clip from our recent webinar on Active Directory permission risks — or get in touch to test your defenses before attackers do.
In previous installments of The Attacker’s Playbook, we explored how human error (Part 1) creates the initial opportunity and how attackers exploit forgotten physical and digital entry points (Part 2).
But truth be told, we don’t always have to work that hard. Often, the “keys to the kingdom” are left right out in the open, in the form of default passwords, reused credentials, and sensitive data stored in the wrong places.
The simplest access control failures are often the most effective. We operate under the principle that default credentials are the same as having no authentication at all.
The Flaw: We find these “ghost keys” everywhere, from routers and medical software to printers. One of the most glaring examples involved finding cameras in medical rooms with live feeds of patients, accessible to anyone who knew the default password.
However, the risk extends beyond defaults. Attackers also hunt for the obscure Active Directory (AD) attribute known as “PassNotReq” (Password Not Required). If this is set to true, the user can circumvent password policies and set any password they want—including a blank one.
We use specialized tools like AD-RECON, an Active Directory reconnaissance tool developed by BreakPoint Labs, to quickly triage Bloodhound data and identify accounts with this attribute, as they are likely configured with weak or nonexistent passwords.
The Attack: An attacker will always start by checking for default credentials and password reuse. They look for exposed configuration files or scripts, such as a PowerShell script that sets the same local admin password across the network, which is essentially a reusable key to the entire kingdom.
In one engagement, we found a Domain Admin account from 2003 with a completely blank password. It’s important to note that this blank password wasn’t a default setting; It was a human-configured error that had remained undetected since its inception in 2003. Why did it persist for so long? Because vulnerability scanners generally don’t check AD password complexity or perform brute-force attacks, and pentesters often assume “blank” won’t work, so they don’t even try it.
The Result: A single default password can allow an attacker to gain a critical foothold, view sensitive patient video, or even achieve full domain takeover.
Mitigation Strategies: Basic security hygiene is non-negotiable.
So, why discuss passwords and data in the same post? Because they are the two halves of the “Keys to the Kingdom.” Passwords are the key, and the data is the treasure inside the chest. Once an attacker uses those weak credentials to get in, they immediately start hunting for the data you forgot about.
The Flaw: It’s extremely common to find Protected Health Information (PHI) and PII on systems where it has no business being. This data sprawl is typically the result of human error and a lack of training or convenience, like a doctor bypassing the secure network to use the Guest WiFi for faster internet access. We often find ourselves asking, “Why is there an exposed network share containing not just PHI, but old ransomware artifacts?”
The Attack: An attacker with internal access will hunt through these misplaced files. In one instance, we discovered dumps of email communications between thousands of students and their school’s healthcare center, filled with vast amounts of PHI and left on an easily accessible share.
The Result: This lack of data governance creates a massive, hidden risk. A single compromised workstation can lead to a catastrophic data breach if that station has access to years of forgotten, sensitive files.
Mitigation Strategies: Data governance is a critical, often-overlooked security control.
Leaving keys and sensitive documents out in the open is an invitation to attackers. Whether it’s a text file, an unlocked port, or a default password, poor security hygiene is an attacker’s best friend.
Key Takeaways:
PassNotReq) are invisible risks that standard scanners miss.Beyond compliance, protecting patient data is about resilience. Our security assessments simulate how attackers exploit these weaknesses, helping you find and fix them before they’re used against you.
So what happens once we’ve got the keys? That’s when the real damage begins. In the final chapter, we dive deep into the maze of internal trust—exploiting complex Active Directory paths that scanners can’t see. Part 4 is where persistence and privilege collide.
In Part 1, we showed how a single text file could compromise an entire healthcare network. But not every breach starts with a forgotten password file.
Sometimes, the threat is physical. It’s an unlocked workstation in a patient room, an open network jack in a hallway, or a forgotten web portal that everyone—including the IT team—forgot was facing the internet.
Hospitals are unique environments. They host a constant stream of visitors who are granted a level of privacy not found in a typical corporate office. Unfortunately, this physical access can quickly become a digital nightmare.
The Flaw: For a busy hospital IT team, securing every connected workstation is a monumental challenge, yet these workstations remain a frequent entry point for attackers.
The Attack: An attacker can plug a device into a physical port on an unsecured workstation. Even if the organization has disabled USB drives, many common prevention methods are ineffective against Human Interface Device (HID) attacks.
In this scenario, a malicious device masquerades as a keyboard. This allows it to bypass standard USB storage restrictions and rapidly type commands to download and execute malware.
The Result: In just a few minutes, an attacker can turn an unsecured workstation in a patient room into a persistent foothold deep inside the network. The attacker achieves this without needing to defeat a single security appliance.
Mitigation Strategies: Physical and digital security are deeply intertwined.
Sometimes, the greatest risks are the systems you don’t even know are exposed. Poor asset management, a human process, can leave a critical internal system open to the entire internet.
The Flaw: During a pentest for a healthcare customer, our team identified a pager application web portal for medical personnel that was accessible from the internet. The organization didn’t realize this system was publicly exposed. This kind of oversight in asset management is a common challenge we see when conducting security penetration testing for our clients.
The Attack: We discovered we could send a pager message to our Point of Contact without being authenticated to the system. An attacker could exploit this vulnerability to cause significant disruption to staff communications.
In addition, the application publicly listed personnel names and phone numbers, providing a perfect resource for a future phishing or social engineering campaign.
The Result: A critical communication line was left open to potential disruption, and a sensitive employee directory was exposed to the public, all from a system they didn’t know was exposed.
Mitigation Strategies: You can’t protect what you don’t know you have.
Your true attack surface is always larger than the systems you have on paper. A single workstation or forgotten web portal can open doors that attackers are eager to exploit.
Key Takeaways:
Our hospital cybersecurity assessments go beyond basic scans. We evaluate everything from workstations to waiting room jacks to exposed web portals, helping organizations secure both the physical and digital sides of their attack surface.
Once we’re in, we look for the “keys to the kingdom” — and too often, they’re left lying around. In Part 3, we reveal how default credentials, old accounts, and mismanaged data expose entire networks. If you think your old password doesn’t matter, think again.
When you picture a cyberattack, what comes to mind? Is it a shadowy figure in a hoodie, typing code to execute a brilliant, sophisticated exploit against a firewall? While that makes for a great movie scene, the reality is often far less cinematic.
Organizations invest millions in state-of-the-art security technology, but time and again, we find that the most critical breaches don’t start with a zero-day exploit. They start with a simple, predictable, and profoundly human mistake. To show how a small error can have massive consequences, let’s look at a real case from one of our healthcare assessments.
During a large-scale assessment of a healthcare network, our team was inside the environment, sifting through terabytes of data on internal file shares. This is where manual work often yields the most critical findings.
The Flaw: Using a tool called Snaffler, which scans network shares for interesting data, we received a massive output file to analyze. Through careful analysis, a team member spotted something unusual in a temporary folder on a random system: a file named p.kdbx. We immediately recognized this as a KeePass password database. Right next to it was a simple text file: p.txt.
The Attack: We opened p.txt. It contained a single string of text. On a hunch, we used that string as the password to open the KeePass database. It worked.
The Result: The database exposed numerous sensitive accounts. Most notably, it provided us with the credentials for a service account with a direct path to full Domain Administrator privileges. A single, forgotten text file gave us the keys to the entire kingdom.
For a detailed breakdown of the tools and techniques we use to discover exposed files and credentials on network shares, read our in-depth guide: Introduction to Share Analysis.
This is the human element at its purest. It wasn’t a complex software vulnerability or a misconfigured firewall. It was one person’s simple mistake that completely undermined the organization’s security posture.
This is a perfect example of what we look for. However, “human error” is a broad category that attackers systematically target. It can be a process failure, like forgetting to decommission a public-facing web server. It can be a hygiene lapse or a policy gap, such as granting overly permissive access rights to users for convenience.
This is why proactive testing is so critical. It’s not about blame; it’s about building resilience against the predictable patterns of human behavior. You can’t defend against an adversary until you understand what they are looking for first.
The story of a single text file compromising a network isn’t just hypothetical; it’s a prime example of the cybersecurity threats in healthcare that begin with people.
Key Takeaways:
Our security assessments combine technical testing with social engineering to help organizations identify and fix these risks before attackers exploit them. Because mistakes are inevitable, but breaches don’t have to be.
Think a forgotten text file can’t cause real damage? Think again. In Part 2, we’ll show how attackers don’t always need passwords — sometimes all it takes is an unlocked door, both digital and physical. Stay tuned for the Patient Room Hack and other real-world entry points.
In July 2025, the U.S. Department of Health and Human Services’ Office of Inspector General (HHS-OIG) released a cybersecurity audit of a large Northeastern hospital.
The findings revealed a sobering truth: even hospitals with robust defenses, like firewalls, disaster recovery, and security training, remain vulnerable if basic configuration and authentication controls are not consistently enforced.
To provide the technical testing for this audit, OIG engaged BreakPoint Labs (BPL) to conduct penetration testing, web application reviews, and vulnerability scanning under a signed Rules of Engagement. Our work demonstrated how minor weaknesses in internet-facing systems can escalate into significant risks to patient safety and data integrity.
Healthcare providers remain at the center of the cyber threat landscape.
Together, these numbers reinforce the OIG’s audit findings: healthcare is too often playing defense against adversaries who only need to find one overlooked gap.
The OIG audit validated that many of the hospital’s defenses were effective. Employees successfully resisted phishing attempts, and the web application firewall blocked most malicious traffic. However, BPL’s technical assessment identified exploitable weaknesses that highlight where hospitals remain at risk:
OIG issued five recommendations, all accepted by the hospital:
Hospitals and healthcare organizations can use this roadmap to harden their defenses quickly:
Days 0–30: Close Obvious Gaps
Days 31–60: Prove Controls in Practice
Days 61–90: Make Security Durable
As OIG’s trusted technical partner in this hospital audit, BreakPoint Labs brings proven expertise in offensive security testing tailored for healthcare environments. Our services help you proactively identify and fix the same types of vulnerabilities found in this engagement.
Our healthcare cybersecurity services include:
Cybersecurity is patient safety. Don’t wait for an audit to find your blind spots.
Request a consultation with BreakPoint Labs today, and let’s build a perimeter-hardening plan that works.
Note: This post summarizes lessons learned from an OIG audit without naming the hospital or exposing sensitive details. Recommendations are sector-wide best practices suitable for public use.
https://oig.hhs.gov/documents/audit/10493/A-18-22-08019.pdf
Finding the paths to escalate privileges in Active Directory (AD) can be challenging when dealing with a complex web of permissions, as shown in the picture above. This blog explains a method for discovering less obvious escalation paths by focusing on accounts with broad access that are not well protected (AdminCount False).
Often, during offensive engagements, you’ll find yourself with some initial access to the network, and you want to expand your access. On most networks, this can be achieved most efficiently by escalating privileges within Active Directory (AD). There are numerous ways to identify escalation paths, which generally involve identifying AD objects that are not properly protected and can perform a variety of interesting actions.
One interesting way to identify this is by analyzing the AD object attribute “AdminCount”. Microsoft leverages this attribute to apply additional protections to the object. I won’t be going over this in detail here, but you can learn more here: https://learn.microsoft.com/en-us/windows/win32/adschema/a-admincount
This value is set to either “True” or “False” with an AD object. AD objects that can do a lot of actions within the Domain are assigned a value of “True” (Example: Domain Admins, Enterprise Admins, etc.). The way I see networks is that you can divide them into two sections based on inbound permissions: objects with AdminCount: False, which allow more things to reach them, and objects with AdminCount: True, which allow fewer things to reach them.
It’s actually somewhat predictable when looking at an object’s inbound permissions. If AdminCount False, usually the same set of objects can reach it, and if it’s True, the same objects can reach it. Typically, you will not have an object with AdminCount: False that can reach an object that has AdminCount: True. If you do this, you are likely to identify new escalation paths.
When performing engagements, I often find a handful of accounts that numerous AD objects can reach due to AdminCount: False, which have excessive permissions that expose the entire domain to takeover. Generally, it’s just these few accounts that open the door for any attacker who can gain access from a lower-level object (for example, a Tier 1 help desk) and then escalate to these accounts, ultimately taking over the entire domain.
CVE-2017-8613: A good example of this common issue is with the Azure Sync account (MSOL_XXX). These accounts are frequently vulnerable to this permission abuse path because, for a considerable period, Microsoft failed to apply the AdminCount: True setting to these high-access accounts (they can dcsync by design).
https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2017-8613
https://learn.microsoft.com/en-us/security-updates/securityadvisories/2017/4033453
This same vulnerability is introduced to AD environments due to poor permission configuration. I observe this pattern in every engagement, and I wanted to share my analysis techniques to help others identify these escalation paths.
So, what I started doing on engagements is auditing all user accounts with AdminCount: False and their outbound rights. The idea is to identify accounts with lower inbound protections that can achieve a lot.
In Bloodhound, you can see this attribute in the “Node Info” tab:
You can list out all users with their AdminCount value via a simple query:
MATCH (u:User) return u.samaccountname, u.admincount Note: I find it helpful to return the admincount attribute for most of the queries. This is provided as a simple example. It’s just good context to have when analyzing various attack paths.
Now, to automate this further, we need to determine their outbound rights to find who is admincount: false and can do more in the domain, as this will find interesting escalation paths similar to CVE-2017-8613:
def get_admincountFalseUsers_trans():
with GraphDatabase.driver(URI, auth=AUTH) as driver:
result = do_query(driver, "MATCH (m:User {admincount: false}) return m.name, m.objectid, m.admincount")
admincount_outbound_file=open("admincount_false_outbound_trans_rights.txt", "w")
for record in result:
if record["m.name"]:
username = record["m.name"]
objectid = record["m.objectid"]
admincount= record["m.admincount"]
result1 = do_query(driver, "MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH p=shortestPath((u:User {objectid: '"+objectid+"'})-[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)")
for record1 in result1:
if record1["count(p)"]:
trans_rights=str(record1["count(p)"])
admincount_outbound_file.write("[-] User: "+username+" Transitive Outbound Rights: "+trans_rights+" Admincount: "+str(admincount)+"\n")
admincount_outbound_file.close()
with open("admincount_false_outbound_trans_rights.txt", "r") as fp:
entries = str(len(fp.readlines()))
print("[+] Generating a List of Users with AdminCount=False Transitive Outbound Rights: admincount_false_user_outbound_trans_rights.txt ("+entries+") lines")The code snippet is pulled from AD-RECON; it will retrieve a list of users with AdminCount: False and then gather the numerical value associated with their transitive outbound rights. Then I will sort the output with bash because I failed to produce the output sorted in Python; maybe I will change that, but for now, just do the following:
```
└─$ cat admincount_false_outbound_trans_rights.txt| sort -k 7,7 -nr | less -S
``` This will sort the output based on the 7th element in the line, which is the numerical count for the transitive outbound rights in reverse numerical order (so highest rights on top):
```
[-] User: MSOL_F367GGD8CDD8@ORGRIMMAR.ORG Transitive Outbound Rights: 43848 Admincount: False
[-] User: acct1@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: passreset@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: domainjoin@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: carol@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
...
``` The result is output that quickly identifies accounts with lower inbound protections, which can lead to various consequences. Now, all these aren’t always exactly the problem themselves, so you must look at the actual transitive outbound rights for these objects to see how they’re getting their permissions. When you do this, you’ll see there are a handful of accounts ending up in this graph that are allowing these lower-level Admincount: False accounts to do a lot of things.
Example: Since the MSOL account can dcsync and essentially take over the domain, and its Admincount is false, the “passreset” account can change its password and thus has an escalation path to take over the domain. Had the MSOL account been adequately protected with AdminCount set to True, this escalation path might not have existed. On most networks, you will find that the MSOL account is a problem, but it is not the only account that extends permissions up to higher-level AD objects.
Another example we often see is that the account used to add computers to the domain may not be properly configured and may not have permissions over the Domain Controllers (such as WriteAccountRestrictions and Owns), which creates a potential escalation path. See, getting to the domain controllers might be hard, but because the AdminCount: False for the “domainjoin” account, you just need to get any account that can reset a password (example, a Tier 1 help desk), and then take over the domainjoin account, and then the Domain Controllers.
When diving deep into AD, as in this case, you can discover numerous additional escalation paths to enhance security, not just the one initially required to achieve the desired access. Please note that on a Red Team, this might not be the primary goal, but for a penetration test (PenTest), it’s beneficial to include as many escalation paths as you can identify.
Andrew McNicol is the Chief Technology Officer and a co-founder of BreakPoint Labs, where he oversees the company’s technical strategy and manages the Cybersecurity Assessments line of business. He is a recognized expert in adversarial penetration testing, with more than 15 years of experience leading numerous technical teams on red team operations, vulnerability assessments, and penetration testing engagements to achieve each client’s specific objectives. Andrew holds numerous professional certifications and is a frequent speaker at government and industry security forums.
In our first post, “OT Attack Surface Management: It’s Turtles All the Way Down”, we established that an attacker’s view of your OT attack surface is a complex environment where any point can be an entry point. It truly is “turtles all the way down.”
Now we look past the top turtle. Some of the most devastating attacks don’t come from a direct assault on your perimeter, but from exploiting the trust you place within the stack in your vendors, your software, and even your own staff. In this second part of our series based on Ray Blasko’s recent presentation at OT.SEC.CON, we’ll explore how to manage OT supply chain security and insider threats. You can watch the full presentation on the BreakPoint Labs video hub.
A supply chain attack is one of the most difficult threats to defend against. It can be a piece of hardware, a software application, or even a routine update that arrives with a malicious payload hidden inside. When a vendor is compromised, attackers can exploit that trusted relationship as a pathway into your network. They effectively inherit the same trust and privileges you’ve granted to that vendor.
So what can you do?
No one wants to believe their coworker is a spy. We want to trust the people we work with. But an insider threat isn’t always malicious. It could be an employee, a contractor, or anyone with insider knowledge who is unintentionally tricked or, worse, is being blackmailed or threatened.
The danger is that this person may already have administrative privileges, allowing them to bypass many of your defenses from the start.
The defense against this begins with a simple acknowledgment that the threat is real. From there, your strategy relies on two core principles:
Trust is a relationship, not a security control. Every layer of your operation, from the software you install to the people you grant access, must be secured and validated.
Up Next: In our next post, we get physical. We’ll explore how attackers can walk right past your digital defenses in “OT Physical Security Assessment: A Guide to Compromising Remote Sites.”
Are you effectively managing the risk from your third-party vendors and internal systems? The experts at BreakPoint Labs can help you build a more resilient security posture. Contact us to start the conversation.
Ray Blasko is the Technical Director for offensive operations at BreakPoint Labs and a Red Team Operator for a DoD-certified Red Team, responsible for assessing and securing critical ICS/SCADA assets. He is recognized as a subject matter expert in both attacking and defending IT and OT environments, and he excels at resolving the technical and strategic issues that arise in protecting critical infrastructure. Ray holds numerous professional certifications and regularly presents at DoD Red Team conferences, trade conventions, and information security events.
In the first part of this series, we introduced the ‘turtles all the way down’ concept of the OT attack surface. Then, we dove into the layers of trust within that stack, exploring supply chain and insider threats in Part 2. Now, we move from the digital and trusted to the tangible and physical. In this third installment, based on Ray Blasko’s presentation at OT.SEC.CON, we’ll explore the world of physical security assessments. You can watch the full recordings on the BreakPoint Labs video hub.
You’ve spent millions on firewalls, endpoint detection, and sophisticated monitoring tools. Your digital fortress is state-of-the-art. But what if an attacker could bypass all of it in less than 60 seconds with a cheap lockpick and a bit of nerve?
For an offensive security professional, a physical compromise is often the most fun and eye-opening part of an assessment. While you’ve secured the digital front door, attackers are often able to just walk in through the back.
If an attacker needs to gain access to your OT environment as quickly as possible, the easiest path is often direct physical access. In the words of our Technical Director, Ray Blasko, “the first thing I’m going to do is I’m going to go find a remote site that’s unmanned and get in that way.”
These sites are a goldmine of vulnerabilities. Let’s walk through a real-world example from one of our assessments.
A water utility took us to a remote water tower. From their perspective, it was well-defended:
The defender saw strengths. An attacker saw a playground of opportunities:
Inside that unlocked building was a connected router inside an (unlocked) PLC cabinet. We plugged in a laptop and instantly had access not only to that site but to their entire main OT environment. Total time from arrival to full network compromise: under a minute.
Physical threats aren’t just about doors and fences. A wireless HID attack is particularly dangerous. Attackers have gotten creative with weaponized USB devices. This goes far beyond leaving a thumb drive in the parking lot. We’ve seen malicious hardware hidden in charging cables and even vape pens.
One of the most effective attacks uses wireless mice and keyboards. An attacker can use a tiny, cheap RF dongle to send keystrokes to a wireless mouse receiver from up to 50 feet away, telling the computer to execute commands. Even if you block USB drives, you can’t block Human Interface Devices (HID) like a mouse or keyboard, making this a perfect way to bypass controls and attack secure or even air-gapped networks. An attacker can plug one of these tiny receivers into the back of a machine, and it will likely go unnoticed for a long time.
Your digital security is only as strong as the physical security that protects it. Don’t let an unlocked door be the downfall of your entire security program.
Up Next: In our final post, we’ll tie it all together and discuss how to build a proactive defense that can even stand up to advanced, nation-state level threats in “Proactive OT Security: Defending Against Zero-Days & Nation-States”
How resilient is your physical security? BreakPoint Labs conducts comprehensive physical security assessments to uncover the gaps you can’t see. Contact us to learn more.
Ray Blasko is the Technical Director for offensive operations at BreakPoint Labs and a Red Team Operator for a DoD-certified Red Team, responsible for assessing and securing critical ICS/SCADA assets. He is recognized as a subject matter expert in both attacking and defending IT and OT environments, and he excels at resolving the technical and strategic issues that arise in protecting critical infrastructure. Ray holds numerous professional certifications and regularly presents at DoD Red Team conferences, trade conventions, and information security events.
Red teaming of AI-enabled systems is becoming essential for every organization to ensure they aren’t introducing risk to themselves and their stakeholders as they implement generative AI applications. Pentesters and red teamers need to become familiar with AI-specific attack techniques and terminology.
Microsoft has put out some AI Red-Teaming Playground Labs that are a great way to practice attacking AI applications. In this series of blog posts, we’ll walk through some of these challenges and uncover AI red-teaming tactics, techniques, and procedures (TTPs) that you can add to your arsenal.
The setup is a bit of effort initially, but I promise it’s worth it and won’t take much once it’s running. We’ll create an Azure account if you don’t already have one, set up an AI deployment for the Playground to use, then install and connect the Playground itself. Finally, effective offensive security testing should combine both automated and manual testing, so we’ll set up Microsoft’s PyRIT framework so we can walk through each challenge both manually and programmatically.
If you don’t have an Azure account, let’s set one up real quick. Cloud stuff always feels intentionally obscure and overly-complicated, so I’ll try to be detailed, but don’t blame me if this part is a pain. Also be aware of costs – new Azure accounts get $200 in free credits, and for this setup and Challenge 1 testing I’ve only used $0.09 of that, so no big deal here but just know that billing is happening in the background.
Here are the steps I took:
If all that worked successfully, congrats because it took me an embarrassingly long time to get to this point on the first pass. Let’s continue:
Success! Now you’ve got two models for the AI Red-Teaming Playground Labs to communicate with.
Install docker compose if you don’t have it already – if you’re using Kali like me, remember do not use apt install docker-compose! Do this instead:
apt install -y docker.io
mkdir -p ~/.docker/cli-plugins/
curl -SL https://github.com/docker/compose/releases/download/v2.24.6/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose`
chmod +x ~/.docker/cli-plugins/docker-compose
docker compose versionThis is a great time to mention that docker is my archnemesis and it always causes me personal pain to recommend using it, but here we are.
Next is setting up the labs locally. Pull down the git repo:
git clone https://github.com/microsoft/AI-Red-Teaming-Playground-Labs.gitThe repo has a .env.example file in it. Copy this to .env and follow the instructions inside it to create a SECRET_KEY and an AUTH_KEY, then populate the rest with your Azure endpoint and API key saved previously. Set the model as “gpt-4o”.
And that should be it! Within that directory, run:
docker compose upThen navigate to http://localhost:5000/login?auth=<AUTH_KEY> and you should see a list of challenges to launch.
Finally, we’ll install PyRIT, which is Microsoft’s open-source framework for automating security testing of generative AI applications. Its documentation can also be obscure and needs a little more detail in my opinion, but we’ll do our best to figure it out.
Install pyrit, jupyter, and ipykernel:
pip install pyrit jupyter ipykernelInstall kernelspec:
python -m ipykernel install --user --name=pyrit_kernelSetup complete!
Challenge 1 – Direct Prompt Injection is straightforward and simple enough to do manually. The exact same prompt won’t work 100% of the time due to the nature of GenAI being non-deterministic and all that, but you shouldn’t have much of a problem convincing the chat bot to give up its passwords.txt.
I recommend poking around the PyRIT documentation and watching at least this high-level walkthrough from Microsoft. Even better, watch all 10 quick episodes of their AI Red-Teaming 101 course.
At a high-level, here’s what’s happening in PyRIT:
Datasets = Initial prompts to be fed into the pipeline.
Orchestrator = from their docs: “The Orchestrator is a top-level component that red team operators will interact with the most. It is responsible for telling PyRIT which endpoints to connect to and how to send prompts. It can be thought of as the component that executes an attack technique.”
Converters = converts the prompts into something else – it could be different encoding, putting prompts into a Word doc instead of just plain text, or much more complex things like the MathPromptConverter which is used to “transform user queries into symbolic mathematical problems by applying set theory, abstract algebra, and symbolic logic”. We’ll look at a few of these in a second.
Target = an AI target and how to connect to it. For this it will be an HTTPTarget but other examples include OpenAIChatTarget, AzureBlobStorageTarget, and HuggingFaceChatTarget.
ScoringEngine = to avoid manually reviewing every chat response, you can set up scorers that will automatically grade responses to see if they meet set criteria. We won’t do this today but you’ll want this when doing high-volume testing.
Ok let’s launch the Jupyter notebook. For some of these labs, Microsoft has included a notebook to start with for PyRIT testing.
jupyter notebookWhen the web GUI launches, select File -> New -> Notebook and choose the pyrit_kernel when prompted for Kernel. On the right, Upload and choose “AI-Red-Teaming-Playground-Labs/notebooks/Lab 1 – Credential exfiltraiton.ipynb”.
Follow the instructions to fill in the raw_http_request variable – don’t forget to adjust the curly braces according to step 7, and then put your prompt variable into the “input” parameter as shown below. Run the first cell and double check the print output looks as expected.
Note: if you ever get a JSONDecode error running the second cell (where it makes requests to the Lab 1 challenge HTTP endpoint) it’s likely due to a 401 response because the session cookie expired – you’ll need a new cookie/request here.
Note 2: if you see a duckdb error about unhashable type, this is a known bug in the newest duckdb (1.40), revert to 1.3.2 with pip install "duckdb==1.3.2"
Now that we’ve got a valid POST request that will send prompts to the Challenge 1 endpoint, let’s look into Converters to see how the initial prompt can be manipulated. Since I want to test out a bunch of Converters, in the first cell I changed the prompt converter import statement to get all of them:
from pyrit.prompt_converter import *In the second cell, when it defines the HTTPTarget, add the parameter “use_tls=False” at the end or else you’ll get SSL errors (as the challenges are HTTP only). It should now look like:
http_prompt_target = HTTPTarget(http_request=raw_http_request, callback_function=parsing_function, timeout=20.0, use_tls=False)CharacterSpaceConverter is a simple option to test first. It does exactly as advertised – puts a space between every character. Within the orchestrator, set the prompt_converter to CharacterSpaceConverter and run the notebook – you should see the converted prompt and the chat bot’s response.
Within the repo, you can find a list of all the built-in converters inside “PyRIT/pyrit/prompt_converter/__init__.py” (at the time of testing, I counted 61 total). Play around with different converters to see what options you have. You can stack multiple Converters as well and they’ll execute sequentially – here’s Leetspeak followed by CharacterSpace:
For a more complicated Converter, I tried MathPromptConverter, which frames the prompt as advanced math logic to see if it will complete the “math problem” which might get you past security controls. This and some other Converters require an LLM resource that PyRIT can use to generate advanced prompt mutations (and yes, you’re using GenAI to generate attacks against GenAI, this is life now).
Fortunately we just set up an Azure OpenAI endpoint for the Playground Labs and can re-use that same resource. You will need to define the endpoint details (found in Azure AI Foundry -> Deployment -> gpt-4o) within the code or in a .env file as explained in the PyRIT documentation.
We’ll do it directly in the code for now. Add an OpenAIChatTarget for this out-of-band prompt generation and give it the model name, API key, and endpoint. Within the orchestrator function call, add the MathPromptConverter and point it to the OpenAIChatTarget you just defined. The code should look similar to below (I’ve redacted my endpoint details):
Take a second to thank the universe you didn’t have to dig up old high school calculus textbooks to craft this prompt. Unfortunately here, the Challenge 1 chat bot didn’t fall for the math trap.
Playing with the Converters was interesting and there are plenty of techniques to try. The first to succeed in retrieving passwords.txt was the PersuasionConverter using the option “expert_endorsement”:
And that’s it for Challenge 1! Despite the simple example, it’s easy to see the potential here for automating large scale testing of AI implementations. We’ll be back soon for Challenge 2 – Metaprompt Extraction.
Ray Blasko is the Technical Director for offensive operations at BreakPoint Labs and a Red Team Operator for a DoD-certified Red Team, responsible for assessing and securing critical ICS/SCADA assets. He is recognized as a subject matter expert in both attacking and defending IT and OT environments, and he excels at resolving the technical and strategic issues that arise in protecting critical infrastructure. Ray holds numerous professional certifications and regularly presents at DoD Red Team conferences, trade conventions, and information security events.
In penetration tests and red team engagements, we frequently exploit privilege escalation paths in Active Directory (AD). When discussing remediation, clients often think, “I’ll just disable that account to eliminate the risk.” However, in some instances, simply disabling the account does not remove the risk. When we explain this to customers, they tend to look confused because the account is indeed disabled. Still, the residual risk is tied to specific escalations involving permissions over a higher-privilege account from alternative access. For example, privileges such as “WriteDACL” or “GenericAll” can enable an attacker to exploit a disabled account by re-enabling it and leveraging the escalation path as if it were never disabled.
During an engagement, the team gains access to several users through password guessing or by discovering cleartext passwords on shared drives and begins evaluating the access and privilege escalation paths of these compromised users within Active Directory. The team identifies one user (User A) who has (GenericAll) rights over User (B).
This is especially interesting because appears that User A’s access to User B is somewhat outside the normal permissions, as the rest of the permission paths reside with high-value targets.
Further investigation shows that User B can do a lot of interesting things (effectively has control over all the domain objects):
In this instance, User B is disabled. However, since the attackers have User A, who has “GenericAll” over User B, they can enable the user and leverage it to escalate their privileges.
This perfectly demonstrates how simply disabling the account of User B does not reduce the risk for this attack path; it just adds an extra step for the attacker to enable the account, which is trivial.
Now that you understand simply disabling accounts within AD doesn’t always eliminate the attack surface, you should consider the following:
Tips for Investigation:
We find it useful to assess the outbound rights of all disabled accounts (we do this for every account in the domain, but to focus on the topic of this blog, we will concentrate on disabled users) to identify those with significant access. From this point, examine who has rights to reach them (inbound permissions). This can assist in pinpointing potential escalation paths from lower targets to disabled accounts that possess considerable access. Below are some helpful Cypher Queries you can leverage within Neo4j against the Bloodhound database:
List all Disabled Users:
MATCH (m:User {enabled: false}) return m.name, m.objectid, m.admincount
Using the SID for each user (m.objectid), you can list out transitive permissions for each user based on a count:
MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH p=shortestPath((u:User
{objectid: '"+objectid+"'})-
[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|AllExtendedRights
|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)
In practice, we find querying is best done in Python. Below is a more complete snippet of code:
def get_disabledUserOutboundRights_transitive():
with GraphDatabase.driver(URI, auth=AUTH) as driver:
result = do_query(driver, "MATCH (m:User {enabled: false}) return m.name, m.objectid, m.admincount")
disabled_outbound_file=open("disabled_user_outbound_transitive_rights.txt", "w")
for record in result:
if record["m.name"]:
username = record["m.name"]
objectid = record["m.objectid"]
admincount= record["m.admincount"]
result1 = do_query(driver, "MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH
p=shortestPath((u:User {objectid: '"+objectid+"'})-[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|
AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)")
for record1 in result1:
if record1["count(p)"]:
trans_rights=str(record1["count(p)"])
disabled_outbound_file.write("[-] User: "+username+" Transitive Outbound Rights: "+trans_rights+"
Admincount: "+str(admincount)+"\n")
disabled_outbound_file.close()
with open("disabled_user_outbound_transitive_rights.txt", "r") as fp:
entries = str(len(fp.readlines()))
print("[+] Generating a List of Disabled Users with Transitive Outbound Rights: disabled_user_outbound_trans_rights.txt
("+entries+") lines")
The result will make a text file of all the disabled users and their transitive outbound rights, one per line. This can help us analyze the outbound rights of all disabled users quickly to find interesting targets for additional analysis:
The output will look like this:
[-] User: userb@BREAKPOINT.LABS First Degree Outbound Rights: 20771 Admincount: True So to sort the data based on "who has the most rights", first we will use the Linux sort utility based on a number in reverse order on the 7th element in the line (which is the outbound right count). └─$ cat disabled_users_outbound_transitive_rights.txt | sort -nr -k 7,7 | less -S [-] User: userb@BREAKPOINT.LABS Transitive Outbound Rights: 20771 Admincount: True [-] User: userc@BREAKPOINT.LABS Transitive Outbound Rights: 6165 Admincount: True [-] User:userd@BREAKPOINT.LABS Transitive Outbound Rights: 5098 Admincount: True [-] User: usere@BREAKPOINT.LABS Transitive Outbound Rights: 4821 Admincount: True [-] User: userf@BREAKPOINT.LABS Transitive Outbound Rights: 4821 Admincount: True
From here, review the inbound rights for these accounts in Bloodhound, and you might discover an interesting way to control one of these disabled users who have extensive rights in the domain.
Disabling an Active Directory account does not always equate to eliminating risk. Attackers can potentially re-enable disabled accounts if they possess the necessary permissions, such as “GenericAll” or “WriteDACL,” on those accounts. To truly mitigate risks, organizations should go beyond simply disabling accounts. Consider removing the account entirely if it’s no longer needed, revoking its access rights, and thoroughly evaluating potential attack paths leading to these disabled accounts.
By proactively assessing outbound and inbound rights, especially for disabled accounts with significant access, and utilizing tools like Bloodhound and Cypher queries, you can uncover hidden vulnerabilities and strengthen your Active Directory security posture. Remember, a seemingly disabled account can still pose a threat if the underlying permissions are not properly addressed.
Andrew McNicol is the Chief Technology Officer and a co-founder of BreakPoint Labs, where he oversees the company’s technical strategy and manages the Cybersecurity Assessments line of business. He is a recognized expert in adversarial penetration testing, with more than 16 years of experience leading numerous technical teams on red team operations, vulnerability assessments, and penetration testing engagements to achieve each client’s specific objectives. Andrew holds numerous professional certifications and is a frequent speaker at government and industry security forums.