This post expands on one of the top risks we covered in our recent webinar, Beyond Vulnerability Scanners. If you think a clean vulnerability scan means you’re in the clear, think again.
Poor password hygiene, especially reuse, remains one of the biggest threats to enterprise security. Across hundreds of penetration tests, BreakPoint Labs has yet to find a network without major credential hygiene issues. In nearly every engagement, password reuse exposes systems to domain-wide compromise. Attackers know this. They don’t need sophisticated exploits when they can just log in.
According to Verizon’s 2024 DBIR, 80% of breaches involve weak or reused passwords. Ponemon’s 2023 report links 50% of breaches to stolen credentials. We see it constantly: even well-patched networks with clean scanner reports are still using weak, recycled admin passwords — like “Winter2023!”
Scanners are great for catching CVEs and configuration issues. But they don’t flag reused passwords, soft reset procedures, or untrained help desks. Security teams often chase critical vulnerabilities while ignoring easy entry points like weak credential policies. The result? A fully patched network that’s still vulnerable to an obvious attack.
Threat actors know password hygiene is often neglected — and time and again, breaches occur not through advanced exploits but through reused or weak credentials. Below are real-world examples that underscore just how common — and damaging — this attack path is:
In every case, attackers took the path of least resistance — reused passwords, missing MFA, and untested reset procedures. These are the exact weak points that BreakPoint Labs uncovers in engagements: legitimate credentials misused by threat actors without a single exploit needed.
Even with strong passwords, many organizations are still vulnerable — not because of weak credentials, but because they’re too easy to reset. According to IBM, human error contributes to over 95% of incidents.
Attackers exploit forgotten password flows and helpdesk processes. Most organizations don’t test these for social engineering, and adversaries know it.
BreakPoint Labs regularly tests this: attackers use LinkedIn data, social media, and breach info to impersonate staff and trick helpdesks into resetting credentials. “Hi, I’m Carol from HR, I lost my phone…” — if that works, your strongest controls don’t matter.
The good news? These weaknesses are fixable. The solutions aren’t new — but they need consistent implementation. Here’s how to reduce the risk of password reuse and credential-based attacks:
Audit legacy service accounts and migrate to gMSAs where possible — it’s one of the best ways to secure non-human identities.
Most attackers don’t exploit your tools. They exploit your people and your processes. At BreakPoint Labs, we emulate real adversaries to help uncover the blind spots scanners miss. Credential weaknesses are one of the most overlooked paths to compromise — but also the most preventable.
✔️ Review your organization’s password policies and reset procedures.
✔️ Educate your teams on the real-world impact of credential-based threats.
✔️ Test your controls the way attackers would — before someone else does.
Let’s close the gaps your tools are missing.
References
1. Verizon. (2024). 2024 Data Breach Investigations Report.
2. TechCrunch. (2024, July 30). HealthEquity Data Breach Affects 4.3 Million People.
3. Dark Reading. (2024). Snowflake Account Attacks Driven by Exposed Legitimate Credentials.
4. KrebsOnSecurity. (2016, June 19). Citing Attack, GoToMyPC Resets All Passwords.
5. IBM Security. (2014). Cyber Security Intelligence Index.
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.
As the Department of Defense continues accelerating capability delivery to warfighters, agility, and modern software development are an integral part of the process. Delivering new features rapidly requires an authorization process to keep pace with continuous change for a developing capability. To tackle these challenges, the DoD introduced Continuous Authorization to Operate (cATO)—a new way to ensure security without impeding progress.
At BreakPoint Labs, we’ve been at the forefront of this paradigm shift, supporting critical DoD cyber missions and accelerating software delivery to users. We’ve had the opportunity to assist organizations in transitioning from a control assessment point-in-time approach to focusing on continuous risk determination and authorization through demonstrated continuous assessing, monitoring, and risk management. Our experience has given us unique insights into the transformational approach that is changing how the Department evaluates and authorizes highly effective development, security, and operations (DevSecOps) practices within a software development environment. As such, we’re introducing a 5-part series titled Unpacking the DoD’s cATO Evaluation Criteria.
Continuous Authority to Operate (cATO) is a framework that grants an organization’s systems or networks continuous authorization to assess whether they meet the required security standards. As opposed to traditional “ATO” processes, which require a static cycle of approval, usually every 3 years, cATO offers dynamic, ongoing authorization based on the current security state of systems in runtime.
The DoD defines cATO as: “The state achieved when an organization that develops, secures, and operates a system has demonstrated enough maturity in maintaining a resilient cybersecurity posture that traditional risk assessments and authorizations become redundant.”2
This approach aligns with the DoD’s Software Modernization Strategy, pushing for better DevSecOps practices and faster, more secure software deployment. The March 2025 State of DevSecOps report published by the DoD CIO describes DevSecOps as a critical enabler of the shift to cATO, noting that over 50 DoD software factories are now delivering code using DevSecOps practices.
The traditional ATO process was sufficient when systems were less complex and security challenges were more predictable. However, with the rise of cloud technologies, continuous deployment models, and ever-evolving cybersecurity threats, organizations found that static authorization led to blind spots in security compliance.
This is where cATO comes into play. Instead of evaluating systems at predefined intervals, cATO ensures systems remain compliant through ongoing assessments, allowing organizations to maintain security postures dynamically without significant downtime.
The DoD’s shift to cATO also incorporates Zero Trust principles. The March 2025 State of DevSecOps report explicitly frames cATO as incorporating real-time assessment, Zero Trust principles, and DevSecOps to secure the supply chain against emerging threats. Organizations building toward cATO should treat Zero Trust architecture as a foundational element, not a parallel initiative.
As organizations prepare for cATO evaluation, they should focus on:
DevSecOps Platform (DSOP): The set of tools and automation that supports software development, including secure pipelines and control gates.
Processes: Workflows and practices that ensure continuous risk management and seamless integration of security.
People: The skills, training, and collaboration between teams responsible for development, security, and operations. Building a culture of security is just as important as the technology.
For Military Services and DoD Agencies and Field Activities, cATO isn’t just a buzzword—it offers advantages in the form of:
To implement cATO, organizations need to adopt a blend of automation tools, monitoring platforms, and updated security practices.
Key steps include:
As we dive deeper into cATO Evaluation Criteria throughout this series, we’ll explore each of these pillars in detail and offer practical insights and strategies for implementation. We’ll draw on our extensive experience supporting critical DoD initiatives to provide a roadmap for organizations looking to embrace this new standard in cybersecurity and software deployment.
The path to cATO is less about process change and more about the shift in how software development and security are approached. cATO offers DoD Components a modernized authorization process for dynamic, resilient software development environments to deliver secure, scalable, and reliable software at the speed modern warfare demands.
A traditional Authorization to Operate is a point-in-time approval, typically renewed every three years, based on a compliance review conducted at a specific moment. A Continuous Authorization to Operate replaces that static cycle with ongoing authorization based on the real-time security state of the system. The DoD defines cATO as the state achieved when an organization has demonstrated enough maturity in maintaining a resilient cybersecurity posture that traditional risk assessments become redundant. Rather than proving compliance at intervals, organizations must demonstrate continuous monitoring, active cyber defense, and a secure software supply chain as ongoing capabilities.
The DoD cATO framework rests on three pillars. The first is Continuous Monitoring (ConMon), which requires near real-time visibility into Risk Management Framework controls, with aggregated security data available to authorizing officials continuously rather than at scheduled intervals. The second is Active Cyber Defense (ACD), which requires real-time threat response, integration with Cybersecurity Service Providers, and a regular cadence of penetration testing and vulnerability assessments. The third is Secure Software Supply Chain (SSSC), which requires security to be integrated throughout the software development lifecycle using approved DevSecOps platforms, automated control gates, and Infrastructure as Code. Each pillar is covered in detail in this series.
The March 2025 State of DevSecOps report published by the DoD CIO describes DevSecOps as a critical enabler of the shift from point-in-time risk assessment to continuous authorization to operate. An organization practicing DevSecOps is building the pipeline, automation, monitoring, and culture that cATO requires. The report notes that cATO incorporates real-time assessment, Zero Trust principles, and DevSecOps to secure the supply chain against emerging threats. DevSecOps is the methodology that makes continuous assessment operationally possible. cATO is the authorization outcome that recognizes that maturity.
The DoD’s March 2025 State of DevSecOps report explicitly frames cATO as incorporating Zero Trust principles alongside real-time assessment and DevSecOps. Zero Trust requires continuous verification of every user, device, and connection rather than assuming trust based on network location or prior authorization. This aligns directly with cATO’s requirement for continuous rather than periodic security assessment. Organizations building toward cATO should treat Zero Trust architecture as a foundational requirement, not a parallel initiative.
DevSecOps is the practice of integrating security into software development and operations continuously rather than treating it as a phase at the end of the development cycle. cATO is the DoD authorization framework that recognizes and rewards that maturity. An organization practicing DevSecOps is building the foundational capability that cATO requires. DevSecOps is the methodology. cATO is the formal recognition that an organization’s development, security, and operations practices are mature enough that traditional point-in-time risk assessments become redundant.
The Software Engineering for Continuous Delivery of Warfighting Capability guide is published by the Office of the Under Secretary of Defense for Research and Engineering. It provides guidance for DoD Program Management Offices, systems engineers, and acquisition officials on modern software development practices. The guide has gone through three revisions: initial release in April 2023, a December 2024 revision that clarified Agile and DevSecOps terminology and metrics, and a July 2025 revision that substantially updated guidance on AI and machine learning. For cATO programs, the guide defines the engineering and DevSecOps practices that underpin the Secure Software Supply Chain pillar of cATO evaluation.
Penetration testing is an explicit requirement under the Active Cyber Defense pillar of cATO. It’s not a one-time compliance gate but a recurring component of the continuous assessment posture. Organizations pursuing cATO need to demonstrate a regular cadence of adversarial testing as evidence that security is actively managed. The findings from penetration tests feed directly into the continuous risk determination process and give the Authorizing Official current data on exploitable risk rather than a compliance status based on a prior snapshot.
The Authorizing Official accepts risk on behalf of the organization and grants the authorization to operate. In a traditional ATO, this decision is based on a point-in-time assessment package reviewed periodically. In cATO, the Authorizing Official needs continuous, near real-time visibility into the system’s security posture so risk decisions can be made as the environment changes rather than on a fixed review schedule. This shifts the AO from periodically reviewing static documentation to maintaining ongoing awareness through a live security dashboard.
Infrastructure as Code means that system and environment configurations are defined and managed through code rather than manual processes. For cATO, IaC matters because it creates a consistent, auditable, and repeatable deployment process where security controls are enforced programmatically at every deployment. It reduces configuration drift, the gradual deviation of a live system from its authorized security baseline, which is one of the core failure modes that point-in-time authorization processes cannot detect between review cycles.
The DoD defines a software factory as a collection of people, tools, and processes that enables teams to continuously deliver value by deploying software to meet the needs of a specific community of end users. The March 2025 State of DevSecOps report notes there are over 50 DoD software factories now using DevSecOps to deliver code into production. Software factories represent the organizational implementation of the DevSecOps practices that cATO evaluation is built around. A program operating with a software factory has the foundational infrastructure that cATO requires.
cATO is not universally mandatory, but it is the preferred authorization approach for programs using continuous deployment models under the DoD Software Modernization Strategy. Programs delivering software updates frequently and operating in cloud or DevSecOps environments are the primary intended audience. Programs still operating on traditional waterfall development cycles may find that a traditional ATO remains more practical, but the direction of DoD policy is clearly toward continuous authorization for modern software development environments.
There is no fixed timeline because cATO is a state of demonstrated maturity rather than a certification with a defined endpoint. Organizations starting from a traditional ATO posture should expect the transition to take significant time, as it requires building or maturing pipelines, monitoring tooling, DevSecOps practices, and organizational culture across development, security, and operations teams. The March 2025 State of DevSecOps report identifies bureaucratic inertia aligned to traditional approaches as one of the primary barriers, noting that existing processes across cyber, test and evaluation, acquisition, and requirements all need to be realigned toward rapid incremental delivery.
The primary reference documents are the DoD CIO’s Continuous Authorization to Operate memo, the DevSecOps Continuous Authorization to Operate Evaluation Criteria, the March 2025 State of DevSecOps report published by the DoD CIO at dodcio.defense.gov, and the Software Engineering for Continuous Delivery of Warfighting Capability guide published by OUSD R&E and last updated July 2025 at cto.mil. For programs operating within a specific military service, check for service-specific implementation guidance in addition to these DoD-level documents.
1. Department of Defense Software Modernization Strategy – DoD CIO
2. Continuous Authorization To Operate (cATO) Memo – Department of Defense
3. DevSecOps Continuous Authorization to Operate Evaluation Criteria – DoD CIO
4. DevSecOps Continuous Authorization to Operate Evaluation Criteria – DoD CIO
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.
BreakPoint Labs is excited to share some tips and tricks for improving vulnerability management programs. Our goal is to help vulnerability analysts become more technical and leverage tips and tricks from pentesters. Check out our quick video here and the tips below:
BreakPoint Labs engineers had a great time this past weekend at BSidesJXN 2017 held at the Bomgar facility in Jackson, MS. Our engineers gave a talk titled “Adding Pentest Sauce to Your Vulnerability Management Recipe” – all about improving vulnerability management based on Red Team tips and tricks. BSidesJXN is a great example of why we love BSides events – strong and friendly community of information sharing. Check out their website for some more information and consider attending next years event.
The motivation for the talk came from common pentest findings that are missed during vulnerability scanning and management. The goal was to supply a vulnerability analyst with some tips and tricks from the red team to help them secure their environment. The slides for the talk are below and cover ten tips for improving vulnerability management:
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)
