red-run, with its default red-run-ctf skill, turns Claude Code into a “Hack the Box”-style capture-the-flag (CTF) solver. It is designed to establish access on network targets in lab environments and escalate privileges to administrator or root. It accomplishes its objectives using tools and methodology that could just as well be deployed against live targets in the real-world. red-run agents carry out attacks that are illegal without authorization.

With that in mind, if agentic LLMs are ever to execute offensive cyber actions in sensitive environments, their operators must have a high degree of confidence that their agents will behave responsibly and remain within scope boundaries. LLMs make unpredictable decisions as their context burdens increase, even with carefully crafted prompts. That strange reality - one in which the model “knows” everything, but has the judgment of an unsupervised intern - is the unfortunate nature of a nondeterministic system. Unpredictability does not mesh well at all with some of the environments we face in the field as offensive security operators.

Erica L. Shoemate of The EN Strategy Group said recently on The Threat Vector podcast regarding agentic LLMs: “we’re not just automating tasks - we’re automating judgment.”

So, what happens when the judgment is wrong mid-operation? How can we inject some human guidance at those critical decision points?

The Claude Code ecosystem has, until now, offered only two options to handle subagents that started veering off course:

1. Kill the subagent, wasting tokens and losing its working context in the process. Provide a more precise prompt. Re-spawn the agent and hold onto your butts.

2. Wait for the subagent to complete its run, screaming “RTFM!” while you watch it spiral out of control.

Neither of those options are acceptable when your little Claudies can run destructive tools and commands. You need a way to interact directly with your agents and redirect or stop them in their tracks when they start down token-wasting or, most especially, dangerous paths.

I spent an evening building a custom solution to this problem using tool hooks and an MCP server. It worked - operators could pause subagents mid-run to have conversations and redirect them. It was exciting! Then I learned that Anthropic was already solving this problem with the experimental agent teams feature. Enabling it was as simple as adding a line in settings.json…

red-run now uses Claude Code’s agent teams architecture. Each teammate runs in its own tmux pane as a fully interactive Claude Code session, giving the operator real-time visibility and approval over every action. Escape ends a running task instantly. The operator and team lead can message teammates directly mid-run to steer them down better paths. Oh, and teammates can message each other directly… yeah.

Even with the enhanced visibility granted by agent teams, it can sometimes be tough to follow along while your agents move through an engagement. The new state-mgr teammate attempts to help with this by acting as the second-in-command, focused solely on managing the engagement state. It tracks findings and their statuses, traces provenance, deduplicates data, and updates the attack chain graph in state-viewer as the engagement progresses. The red-run-ctf team lead now focuses less on being a scribe and more on routing actionable findings to skilled teammates in a timely fashion.

All of that happens in persistent context windows that last for the entire engagement. Teammates accumulate knowledge and remember what they have attempted and accomplished, all guided by the operator and team lead, with the state database functioning as the ultimate source-of-truth.

red-run-ctf strives to be a no-holds-barred, blazing fast, flags-at-all-cost CTF solver. It is designed to move fast and iterate, improving its capabilities and its supporting tools in the process. That said, it is a proof-of-concept that, in its nascent state, most closely resembles the threat model of a script kiddie. Imagine, though, the agentic tools that are being built and perfected by nation state threat actors with talented development teams and real infrastructure; advanced persistent threats with sophisticated evasion techniques and years of dwell time, now moving at the speed of agents.

Regardless of how it may be portrayed on screen or in print, Offensive Security Testing can be extremely tedious and unforgiving. It requires organization, discipline, patience, system-of-systems thinking, and a multi-threaded intellect. Offensive Security Engineers have always pushed to automate at least a portion of their test methodologies for a cleaner, more-consistent, and detail-oriented approach. To that end, a thriving community has produced amazing tooling over the years; game-changing work that includes NMAP, Hydra, Metasploit, BurpSuite, aMASS, Impacket, masscan, Ghidra, Nikto, and the list goes on. We have heard whispers of “fully automated penetration tests” and “fully automated red teaming”, but nothing has ever really materialized and impacted our community in the same way as the semi-autonomous but ultimately operator-driven tools that we all use every day.

Then came the LLMs.

Multiple companies and individuals hit the ground running with LLM-augmented and fully-automated test suites. Some have even had a significant degree of success [1][2]. Many of us in this community have built our livelihoods around providing Offensive Security Testing, usually with really smart humans supported by well-built tools. It feels like something very exciting is happening right now with the tools that support those humans, though. Agentic coding can turn a simple chat-based LLM into a partner that lives in your terminal with you and can run your entire stack, as long as you can get past that whole “existential threat” question. LLMs are now and will continue to be incredible catalysts for change, but with that change inevitably comes complex and gnarly new problems to solve.

In the spirit of building, breaking, and bending new technologies to our will, a BLS operator has created red-run. It is an Offensive Security Testing Framework designed to run on top of Claude Code. It took ~2 weeks to build and required a shitload of tokens and at least one all-nighter. If we learned anything, it’s that the next few years are going to be exciting (and terrifying). As a working prototype, it’s far more capable than any of us thought it would be.

red-run is a Claude Code project that combines skills, MCP servers, and agents with routing logic that guides Claude and an operator through the phases of a targeted attack against IT infrastructure. It is an offensive security toolkit that no doubt pales in comparison to the sophisticated LLM-powered tooling that nation-state level threat actors already have in their arsenal.

Why?

But wait… Claude Code can already do this, with no skills required. Why make red-run?

red-run levels up Claude Code for Offensive Security operations:

• Customizable skill library with semantic RAG retrieval.

• Automated engagement state tracking, logging, and evidence gathering.

• Persistent shell and interactive tool sessions that can be shared between agents.

• Headless browser automation with Playwright.

• Offsec-aware agent routing and task parallelization suggestions.

• Self-improvement through retrospectives.

Plus, it is just so damn fun to hack and iterate with Claude Code. It is an accelerator. Tools like Claude Code and other “AI” coding agents will likely become requirements for any serious Offensive Security team. Without them, you will simply fall behind. Remember - the bad guys have this stuff too.

What?

Let’s zoom out for a moment.

A Large Language Model’s (LLM) context window is the amount of text that it can consider in its memory at one time. Think of the context window like volatile memory that is measured in tokens rather than gigabytes. A single token is roughly equivalent to three-quarters of a word [3].

Claude skills are markdown files that are loaded into context when called upon. Skills tell Claude how to do things the way you want them done. Claude already knows how to do just about everything. It can research. It can reason. It can troubleshoot. It can iterate. It can hack. The trick is getting it to do things in the correct way, in the proper sequence, and with accountability.

When a Claude Code session approaches its context limit, the context window is automatically compacted (summarized, essentially). This is not good for extended sessions where you have gained initial access, moved laterally, and started privilege escalation when, suddenly, your context window is compacted and critical earlier information is lost.

red-run attempts to solve this problem with the orchestrator skill - the single skill that is loaded into context at startup. orchestrator acts as the main function and is intended to run on the Opus model with adaptive thinking enabled.

First and foremost, orchestrator is responsible for tracking the overall state of the engagement in a SQLite database during execution. A frequently updated state tracking database allows orchestrator to reconnect all the necessary dots after the lobotomization that is the compaction process. In fact, lengthy engagements can be resumed from an entirely fresh session with minimal productivity loss.

The second and equally important job of the orchestrator is skill and agent routing. Routing guides the engagement through its various phases - enumeration, initial access, lateral movement, pivoting, privilege escalation, exfiltration. Whenever the orchestrator learns new information about the target, it decides which skills to invoke and which agents to task next, in one of two ways:

• Using a hardcoded decision tree. Examples:

  • new target discovered? → network-recon

  • web service found? → web-discovery

  • Kerberos? → ad-discovery

• Searching for a relevant skill using retrieval-augmented generation (RAG). Example:

  • network-recon-agent finds Apache Tomcat AJP connector

  • orchestrator has no hardcoded logic for this scenario

  • orchestrator sends query “Apache Tomcat AJP connector” to skill-router MCP server

  • skill-router responds with ajp-ghostcat skill ranked as most relevant, with a 76% similarity score

  • orchestrator tasks web-exploit-agent with the ajp-ghostcat skill

Agents can be dispatched to work in parallel on separate tasks whenever potential attack paths diverge, and the orchestrator or human operator can always step in to redirect off-task agents, as needed. When agents report back, the orchestrator makes new routing decisions based on the updated target datapoints.

Agents write interim findings to the state database mid-task, so the orchestrator can detect new discoveries and delegate follow-up agents within minutes rather than waiting for the original agent to complete. For example, if ad-discovery encounters a new web service, the orchestrator learns about it and can task web-discovery immediately, not ten minutes later, once ad-discovery finishes its full run. This iterative workflow of agentic tasking keeps the Opus-powered main context window free for operator interaction, and the main loop continues ad infinitum until all operator-defined objectives are achieved.

Retrospectives

Post-engagement is where red-run really starts to shine. The retrospective skill runs in the main context window and reviews the steps taken during the engagement. Skill routing decisions are analyzed. Agent behaviors are examined, down to the individual commands executed during agentic tasks. Gaps in payloads and methodology are identified. Manual interventions are noted.

Claude produces a prioritized list of items that can include skill methodology updates, agent improvements, new skills to build, and orchestrator routing fixes.

Warning: the retrospective skill leads to some existential questions, like “why am I here at all?”

Future State

red-run has evolved from a simple offensive security skill library into a RAG-backed on-demand agent dispatcher with a hierarchical planning system that prefers parallelization (say that three times fast). It is slowly becoming a push-button utility that can navigate most infrastructure-style CTFs from IP address to root flag or die trying (or until you run out of money to throw at Anthropic). Its effectiveness is amplified in the hands of a skilled operator who can nudge agents in the right direction when they inevitably jump down rabbit holes or make mistakes.

That said, red-run is still VERY MUCH a proof-of-concept (PoC). The orchestrator, in its current form, is a fancy CTF solver and is not meant for client-facing engagements. It is designed to complete labs and improve itself over time through retrospectives, similar to how a junior penetration tester might learn.

The orchestrator skill will evolve and mature. red-run could one day be made entirely modular, enabling an operator to swap out a CTF-focused orchestrator for a client-safe version that prefers stealth and evasion, or a version that trains operators on new techniques. Skills will expand to include cloud infrastructure, operational technology (OT), and reverse engineering (RE). MCP servers will be built to support custom command-and-control (C2) infrastructure, phishing activity, and local models for data processing and reporting.

We are in the very early days of agentic coding, but the implications for the offensive security community cannot be understated. It would not be surprising to see authorized penetration testing engagements soon supplemented with semi-autonomous orchestrated agents that assist human operators. It would be equally unsurprising to see these types of tools deployed during real attacks by threat actors with bad intentions.

Demo

To illustrate the speed with which these tools can move, here is red-run vs Flight.HTB (WARNING: spoilers ahead).

Full disclosure: Flight.HTB has been used as a test bed for several recent red-run features and routing improvements. Claude navigated the correct path on its first attempt, but not this quickly.

This run took 1 hour and 24 minutes in real time, but red-run has spent as many as 3 hours and as few as 45 minutes solving this box. CTF testing has exposed the truly indeterminate nature of LLMs. Agents take slightly different paths through the same box each iteration, even with identical operator prompts. Sometimes agents get stuck on mundane problems like clock skew - a task with explicit troubleshooting steps in their loaded skill. They often ignore agent- and skill-level instructions like “DO NOT download tools from the internet” due to prompt pressure. And these agents, loaded with Claude-built skills, have absolutely no OPSEC awareness. Claude has no chill. red-run will light up your SOC, all while your sensitive data is sent off to Anthropic servers. Do not run this in production.

Closing Thoughts

Even with the latest models and meticulously-written skills, “AI” is just another tool in the arsenal for both attackers and defenders (for now). Anyone who uses LLMs daily knows that they continue to make outright bad decisions from time to time. When positioned as a threat-actor targeting your production environment, those bad decisions can become instantly catastrophic. Indeed, a new type of threat actor has been created - overly trusting and inexperienced agentic tool users.

LLMs are not deterministic. The same input is never guaranteed to produce the same output. This is why skilled humans must be kept in the loop whenever an LLM might execute code on an asset - to supervise and to enforce constraints.

It is unclear what offensive security jobs will look like in a year, let alone in five years, given the current pace of change. Human operators will certainly continue to execute hands-on-keyboard tasks, but those tasks will evolve (as they always have).

Afterthoughts

At first glance, it might appear that we’ve somehow “jailbroken” the model, but this is not the case. “Jailbreaking” typically implies that safety features were bypassed in order to trick the LLM into doing something it was not meant to do. Claude Code is supposed to help with security testing. It says so right there in the system prompt:

IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases. [4]

Security researchers and ethical hackers need this functionality in Claude Code in order to keep pace with threats. With sufficient resources, advanced threat actors can build and run their own sophisticated attack-oriented models on their own hardware, with no flimsy guardrails attempting to limit them to “authorized security testing”. Advanced threat actors do not need Anthropic.

Good cloud detection requires tracking domains and subnets owned by cloud providers. This is inherently difficult, since they’re constantly changing. Some providers, like Cloudflare, are kind enough to publish their ranges, which can be periodically scraped and aggregated into a combined signature. You can then check a host against those subnets to definitively answer the question, “Is this thing behind Cloudflare?”

But most providers don’t publish their infrastructure. This almost always leads to manual tracking of CIDRs, ASN numbers, and domains, and quickly devolves into a mess. Since the data must be scraped from multiple and/or competing sources — an HTML webpage here, a random person’s github there — it leads not only to outdated data, but incomplete and inaccurate data as well.

Here are some tools that helped to pioneer this capability, but which still rely on hardcoded lists:

• projectdiscovery/cdncheck

• oldrho/ip2provider

• lord-alfred/ipranges

• schniggie/cdn-ranges

Basic cloud provider detection has always been built into BBOT. When you run a BBOT scan, hosts are tagged as “cloudflare”, “fastly”, etc:

Until today, BBOT’s CloudCheck-powered cloud detection has also relied on these same manual methods. This is why we’ve overhauled CloudCheck from the ground up to solve each of these problems, resulting in faster, more accurate, and more comprehensive detection across numerous cloud providers.

CloudCheck

CloudCheck is an open-source cloud signature database, CLI tool, Python library, and Rust library. As of January 2026, it supports 56 cloud providers (see here for an up-to-date list).

JSON Signatures

CloudCheck’s signatures are updated daily via an automated CI/CD pipeline, which cleans, dedupes, and defrags all the data before saving it to a JSON file on GitHub. This file is free to download and parse, and useful if you like to do things manually instead of using the convenient CLI and API wrappers.

Unique Data Sources

CloudCheck leverages several unique methods to stay up-to-date automatically.

For domains, instead of hardcoding domains like “amazonaws.com”, it pulls daily from domain-list-community. This not only helps to keep the domain lists up-to-date and avoids manual maintenance, but also enables detection of child entities — for example, Kindle and Audible domains nested underneath Amazon:

For IP addresses, instead of hardcoding CIDRs or ASN numbers, organizations are tracked by their Internet Registry IDs. This means CloudCheck can detect brand-new ASNs as they’re spun up, even before they’re announced to the public.

The secret ingredient here is ASNDB, which is queried during the daily signature update. ASNDB is our very own REST API, and part of a soon-to-be-announced API Suite with a generous free tier.

Convenient Categories

Cloud providers are sorted into categories like “cloud”, “cdn”, “waf”, “gov”, etc.

Installation

CloudCheck is written in Rust and installable with one command:

cargo install cloudcheck

Usage - CLI

CloudCheck’s CLI is simple to use. Just execute CloudCheck followed by the hostname or IP you want to look up.

cloudcheck <hostname or ip>

Output is JSON:

Let us know on Discord or Github which features you want added to the CLI!

Usage - Python API

# installation
pip install cloudcheck

import asyncio
from cloudcheck import CloudCheck

async def main():
    cloudcheck = CloudCheck()
    results = await cloudcheck.lookup(”8.8.8.8”)
    print(results) # [{’name’: ‘Google’, ‘tags’: [’cloud’]}]

asyncio.run(main())

Usage - Rust API

# Add to Cargo.toml
[dependencies]
cloudcheck = “9.2”
tokio = { version = “1”, features = [”full”] }

use cloudcheck::CloudCheck;

#[tokio::main]
async fn main() {
    let cloudcheck = CloudCheck::new();
    let results = cloudcheck.lookup(”8.8.8.8”).await.unwrap();
    println!(”{:?}”, results); // [CloudProvider { name: “Google”, tags: [”cloud”] }]
}

Usage - REST API

CloudCheck’s CLI and code libraries perform their lookups against a local in-memory database, which can also be served as a REST API:

We’ve deployed this at cloudcheck.api.bbot.io. You can try it out for free at 10 requests/minute:

Conclusion

We hope you find CloudCheck useful. It is only a small part of the growing BBOT ecosystem - an open-source framework for recursive asset discovery and reconnaissance.

To fully leverage this tech stack and our expert team of analysts and researchers, contact us to learn more about our Enterprise ASM Offering.

Happy hacking!

“I shouldn’t be able to even reach that from here”

This is the first in a series of articles detailing the goals, objectives, and approach to Attack Surface Management (ASM) and ASM as-a-service (ASMaaS).

A few caveats:

- BLS provides ASM as a service (ASMaaS) and almost all of the content in these articles is derived from interactions with our customers.

- BBOT is our FOSS tool that makes our ASMaaS possible. BBOT Pro and BBOT Enterprise are currently being developed. These articles will ONLY discuss the FOSS version.

- This is not Gospel. This is not necessarily even canon. These are more or less tales from the trenches that enabled us to design and develop ASMaaS and BBOT to drive down customer risk.

- There is competing terminology that BLS did not create or define. An attempt will be made to disambiguate where possible, but this is by no means the final word.

… and we’re off.

ASM Goals and Objectives

“If someone can interact with it, you need to know about it.”

In the simplest of terms, the primary goal for ASM is to continuously minimize the risk associated with internet-facing applications, services, and systems. (For the remainder of this article these will be collectively referred to as “assets”) .

Supporting Objectives Include:

- Continuous Discovery and Enumeration of:

- IPs

- Ports

- Deployed Technologies

- Subdomains

- Email Addresses

- Vulnerabilities

- Misconfigurations

- Threat Intelligence Gathering and Analysis based on Business and Attacker profiles

- Continuous Risk Assessment and Asset Prioritization

- Triage and Remediation for Vulnerable Assets based on Priority and Risk

- Verification Testing and Risk Reduction

Reading through the Goals and Objectives above, it should be clear that ASM draws from multiple security controls and categories. The ASMaaS BLS provides today includes elements of or touchpoints with :

- Asset Management

- Vulnerability and Patch Management

- Risk Management

- Threat Intelligence Gathering and Analysis

- Continuous Penetration Testing

- Incident Response

There are also relatively new services and capabilities being offered that overlap with what has previously been defined as ASM. These include (but are not limited to):

- Breach and Attack Simulation (BaS)

- Adversarial Exposure Validation (AEV)

- Automated Penetration Testing

- Continuous Automated Red Teaming (CART)

A detailed analysis of Gartner categories is beyond the scope of this article. However, the overlap with the Goals and Objectives of ASM seems unavoidable. For example:

“BAS and, to a greater extent, AEV provide a strategic, proactive approach to strengthening cybersecurity defenses. Unlike sporadic audits or single-point penetration tests, these platforms deliver continuous, automated validation of your security posture, pinpointing strengths, exposing weaknesses, and guiding remediation.” 1

At the risk of oversimplifying things, each category of security controls “serves at the pleasure” of Risk Management; everything is (and should be) driven by the choices the Business makes with regard to risk. Policies, security controls, applications, and utilities are selected and deployed based on the Risk Management Strategy and Objectives of the Business. In an industry where new categories, terminology, and acronyms appear every week, this is where we are choosing to plant our flag. Basically, “I don’t care what you call it, if it doesn’t fit into our overall Risk Management Strategy and satisfy these requirements, we don’t need it”.

The Business Case for ASM: The CISO Needs Answers … like now

“Wait, so how did they get in again?”

The CISOs we work with are well read and hyper-aware. They answer to the board and when they need answers they let you know in no uncertain terms. More often than not, Executive Leadership will have read about an attack or breach on the front page of the Wallstreet Journal OR received a panicked call from a CISO colleague OR seen something on the news OR all of the above. The immediate ask to their Cybersecurity Leadership Team is, “Do we need to worry about this?”

If statistics and reporting can be believed, then there is a good chance that whatever awfulness has occurred began its life as an attack against one or more public-facing assets. To illustrate this point:

“One in four attacks (26%) against critical infrastructure exploited vulnerabilities in common public-facing or internet accessible applications. This percentage is even higher (30%) for all incidents that X-Force responded to in 2024.” 2

“VPN and edge devices accounted for 22% of exploitation of vulnerabilities vectors in breaches, which is almost eight times the 3% found in the prior year’s report.” 3

If this is case, then this is where ASM really shines. If we have a basic understanding of the initial attack vector, including the vulnerability and primary targets, then ASM enables our team to quickly answer the following questions and effectively communicate back to the CISO:

- Does the targeted software or technology exist anywhere in our Business?

- If so, what Business workflows are attached to the assets running the targeted software or technology?

- Of those managed assets, which are vulnerable to the most recent attack?

- What are the potential impacts of a successful attack?

- How do we remediate in the near-, mid-, and long-term based on the risk?

- What’s the timeline for the fix and when can we tell the Board “all is well”?

These scenarios are consistent with BLS Operations across its customer base as an ASMaaS provider. ASM Analysts are constantly gathering data with regard to new and emerging threats as well as the most prominent vectors of attack. For the current calendar year BLS has executed 17 “Halting Actions” for a single ASMaaS customer alone. “Halting Actions” (HAs) are initiated when a vulnerability or misconfiguration is discovered in an internet-facing asset that constitutes an urgent and significant risk to the Business (life, limb, or property). When a halting action is called, all ASM services and activities are stopped for the vulnerable class of assets until the vulnerability is remediated and the fix is verified and validated. With the global average cost of a data breach at roughly 4 million USD in 2025, the negative impacts to the Business would have been significant if one or more of these vulnerabilities had resulted in a breach (17 HAs @ ~ 4 million USD per HA = 68 million USD )

A large part of the value proposition of ASM is that it is done continuously; the team is always prepared, engaged, and driving down risk regardless of whether that call ever comes from the CISO. The team is always working the ASM methodology asking:

- What do we own and expose to the internet?

- Do all of these things have legitimate Business requirements that justify the exposure?

- Is any of it vulnerable?

- How would it be attacked?

- What would happen if an attacker got hold of it and is it bad enough that we have to fix it right now?

- How do we make sure this doesn’t happen again?

Hopefully this short introduction has provided a high-level overview of ASM and highlighted the potential value it can bring to a Business. In the next article we’ll define ASM metrics and Key Performance Indicators (KPIs). Mores specifically, it will address:

1. What data and metrics are gathered and reported?

2. Based on the data and metrics gathered, what are the ASM KPIs?

3. How do the KPIs translate to positive impacts on the business? (i.e., why should our CISO give a sh*t ?)

Follow-on articles will detail the ASM methodology outlined above and include detailed technical walkthroughs for deploying and using BBOT for ASM.

But as any software company learns sooner or later, software is meant to be broken, and after 10 years of breaking other people’s, the time has finally come to break ours.

We’re referring to four new BBOT CVEs discovered by Justin Steven, a researcher at Tanto Security. Two of these are critical severity, and introduce the possibility for a clever defender to get code execution on the attacker’s system during certain BBOT scans. Fixes have been pushed in BBOT 2.7.0.

Affected BBOT versions are < 2.7.0. If you’re still running these old versions, and if you’re scanning a target known for their spicy honeypots, you may be in danger. See below for details.

BBOT CVEs

CVE-2025-10281 - [4.7 MEDIUM] - Insecure URL Handling in git_clone leads to Leaked API Key

When executing a scan with a GitHub API key, the target exposes a specially crafted git repo link to steal your API key. It was resolved by fixing the URL validation to ensure GitHub API keys are sent only to github.com URLs.

CVE-2025-10282 - [4.7 MEDIUM] - GitLab Domain Confusion in gitlab Leaks API Key

When executing a scan with a GitLab API key, the target hosts a web server pretending to be an on-prem Gitlab server, which steals your API key. It was fixed by separating GitLab into two modules: one for on-prem, and one for GitLab.com.

CVE-2025-10283 - [9.6 CRITICAL] - Improper .git Sanitization in gitdumper Enables RCE

A target being scanned by BBOT hosts a malicious git repo on one of their webservers, which upon being downloaded and checked out by gitdumper, results in RCE on the scanner system. This was fixed by performing aggressive sanitization on the git folder (deleting the git index, config, and all hooks) before running `git checkout`.

CVE-2025-10284 - [9.6 CRITICAL] - Improper Archive Extraction in unarchive Enables RCE

The target hosts a collection of specially crafted compression archives, e.g. tar files, which upon subsequent extraction, could write arbitrary files, leading to RCE. This was due to the possibility of a directory name collision, leading to extraction to a non-empty folder. We fixed it by aborting extraction early if the destination folder already exists.

Disclosure

We are super grateful to Justin for catching these vulns, and especially for his gracious handling of the disclosure, which helped make what could have been a stressful situation as manageable as possible. Having plenty of notice and helpful feedback during the patching process enabled us to craft solid fixes and push them out in a timely manner.

Timeline:

• July 4th, 2025 - Initial disclosure

• July 4th, 2025 - Work begins on patches

• August 25th, 2025 - PoCs finalized

• August 25th, 2025 - Patches finalized

• September 11th, 2025 - Patches approved

• September 11th, 2025 - Patches merged into Dev

• September 11th, 2025 - Patches merged into Stable

• September 11th, 2025 - Patches published to Pypi

• October 8th, 2025 - Blog, CVE Release

Justin will be revealing more details, including PoC exploits, in his talk at Kawaiicon on November 8th.

Closing Notes

Despite catching us a bit off guard, these bugs honed our security process, and demonstrated the best aspects of open source. The gitdumper and unarchive modules responsible for the critical CVEs were contributed by the community. Similarly, their open code helped the community identify and report the CVEs. This kind of collaboration is exactly why we believe in open source and will continue to push forward for more (and more secure) open source tools!

Justin is a talented researcher and we’re excited to see his talk. The exploits themselves, particularly the ones for gitdumper and unarchive, are the product of significant effort on his part. As security researchers, we recognize this and have to admit, they are pretty cool!

Thanks again to Justin and the team at Tanto Security. We appreciate the tough love and all the effort put towards improving BBOT.

How to Update

Stay safe and patch your stuff! Use these commands to update BBOT:

pip install --upgrade bbot

pipx upgrade bbot

How to Report Vulns

If you discover a vuln in BBOT or another BLS tool, please report it via GitHub’s security advisory feature:

https://github.com/blacklanternsecurity/bbot/security

A CVE will earn you some cool BLS swag, including a challenge coin!

Happy hacking!

Safari Adventure

In a recent research project, we focused on three CVEs that Black Lantern Security operators frequently encounter in customer environments. Leveraging BBOT as our primary tool, we set out to identify and enumerate these vulnerabilities across the internet. In this article, we’ll share the journey of our exploration—tracking down these “herds” of technologies, overcoming challenges along the way, and uncovering key insights during our adventure.

Background

One of the most compelling use cases for BBOT is its ability to move directly from the discovery phase to identifying exploitable vulnerabilities in a single step. In many cases, it can quickly pinpoint serious issues with minimal, non-intrusive checks. This is largely due to powerful modules unique to BBOT, such as Badsecrets.

For large-scale internet vulnerability scanning, Nuclei is often the first tool people think of, and for good reason. We have a lot of respect for Nuclei and see it as an essential part of the infosec toolkit. However, some vulnerabilities are simply too complex to be handled within the limits of a Nuclei template, and this is where BBOT really shines.

A number of these vulnerabilities have a habit of resurfacing across different environments and have appeared repeatedly in many BLS customer environments. This got us wondering: just how widespread are these issues across the internet? While testing for a specific customer is manageable, performing the same checks on a huge scale is a much bigger challenge.

has already talked about how BBOT can explode with results if you are too inclusive with your targets, and these results could quickly become the entire internet with some careless configuration settings. Recursion is BBOT’s secret ingredient, but it also can spiral into a void of unending depths of the internet if not carefully controlled and limited.

With this in mind, we began a research project to capture the percentage of internet-facing systems vulnerable to exploitation through some of the most prevalent unauthenticated web vulnerabilities we discover, focusing on those that are readily identifiable using BBOT’s built-in modules.

To do so, we knew we needed to focus our efforts on these specific technologies. But how do you go about compiling a list of those? Thankfully, sites like Shodan.io, BuiltWith, WhatRuns, and Ful.io have already done much of the heavy lifting. These platforms catalog and inventory externally facing web technologies, providing us with a comprehensive starting point to target the specific technologies associated with the vulnerabilities we were researching.

The Elephant

We focused our efforts on three major web technologies:

• Telerik: A suite of UI components and tools for building web applications, most commonly used with .NET and JavaScript frameworks.

• DotNetNuke: An open-source content management system and web application framework for building and managing websites on the .NET platform.

• AjaxPro: A third-party library that enables AJAX calls to server-side methods in ASP.NET applications.

We used BBOT’s modules to validate each web technology and then detect whether the specific CVE existed on the website:

• Telerik: CVE-2017-9248

• DotNetNuke: CVE-2017-9822

• AjaxPro: CVE-2021-23758

Using the aforementioned services for inventorying web technologies across the web, we set out to catalog each site associated with the technology and began our analysis. A few caveats need to be defined before we continue.

Caveats

• We used the services mentioned to generate a list of sites using the particular web technology. This is not all-inclusive and does not account for custom implementations of the technology.

• We did not perform directory brute forcing or conduct any other in-depth discovery efforts to find custom endpoints of the web technology. All technologies were assumed in their default install location/configuration.

• We did not do any additional analysis on the site outside of the default detection mechanism with BBOT. Operators can choose to do additional scanning with the recursion engine of BBOT; however, this was outside the scope of our research.

• All scanning was conducted passively using BBOT and its modules, which simply browsed publicly accessible web pages to identify version information and technology fingerprints. No intrusive or active exploitation techniques were used. While we developed some custom tooling to assist in validating version-based vulnerabilities, these tools operated without interacting with the sites in any harmful or unauthorized manner. We will not be releasing the specific methods or technical details used for validation.

Our approach focused on targeting the most easily identifiable and vulnerable web technologies—the sickest and weakest of the attack surface herd. These were systems that could be quickly observed and validated without the need for extensive analysis or additional tools beyond the BBOT scan.

Finding the Elephant

In order to validate the web technology, we first needed to execute a BBOT scan that would take the list of targets and check for the web technology based on the detection logic defined in each of the modules. For example, the most common Telerik endpoint is Telerik.Web.UI.DialogHandler.aspx, which, combined with the detection logic in the module, validates that Telerik is actually present. Using this as our indicator, we could utilize the BBOT module to do the rest of the work for us.

Problem 1

The first problem we encountered was the sheer size of the elephant we were trying to identify. Typical BBOT scans start with a high-level target (e.g., example.com) and then use the recursion to find other in-scope assets. BBOT is designed to discover its own additional targets. We may manually provide some additional domains if we have them, but providing thousands of domains is not typical for most BBOT use cases.

With just Telerik UI alone, we inventoried over 120,000 different sites that reported using this technology. In order to accomplish this discovery, we had to execute 12 different scans on this web technology alone. Taking smaller bites of this technology, we were still able to consume the meal, albeit at a slower pace. One of the magical things about BBOT is its recursion, but this magic can be a double-edged sword. At the time of this research was being conducted, there was a 10,000-domain limit in place, however this has been fixed in a recent revision.1 2

Problem 2

BBOT’s magic lies within its recursive capabilities, which enable the discovery of an organization’s vast digital landscape by repeatedly expanding on initial targets. Starting with a relatively small target list, BBOT can use the modules and recursion to uncover an expansive surface hidden to the untrained eye. discusses this process in his talk about recursion, in a link posted above.

We know that our target list is already larger than most scan results and that we have recursion functionality that can blow up scans, both in data returned and length to completion. and made this easier in a recent update to BBOT with Presets. BBOT’s presets feature allows us to tailor the scope and focus of our scans by selecting specific modules and configuring target discovery parameters. This enables us to limit a scan with predefined web technologies’ modules to the discovered targets, ensuring a more efficient and targeted exploration of the organization’s digital landscape.

An example preset YAML file that could be used:

config:
  scope:
    strict: true
modules:
- portscan
- telerik
output_modules:
- json
- txt

This would force BBOT to keep a strict scope of only the targets listed in the target file, isolate just the portscan and Telerik module, and output to JSON and TXT formats. This would solve our problem of trying to eat the entire herd of elephants instead of just the specific elephant we’re after.

Problem 3

Besides the hard limits of the size of the elephant and making sure we stuck to our specific target elephant, we also had to deal with the hardware requirements to do the survey. Typically, a BBOT scan doesn’t require more than 2 GB of memory and 2 CPUs. A VM with this size can easily accomplish the vast majority of discovery work when the targets are under 1,000 and a moderate selection of modules is used. However, when targeting web technologies as pervasive as the three we are looking for, a VM of this size isn’t enough juice.

For this research, we used a VM with 4 vCPU and 8 GB of memory, with 4 GB of swap space. Using the larger resource allocation allowed us to run the (majority of the) scans to completion. Most scans took an average of 1 hour and 30 minutes to complete. For comparison, when we work with our enterprise customers for our Attack Surface Management (ASM) service and execute intense scans, those can last well over 8+ hours (depending in modules used and configurations set).

Problem 4

Another issue that can arise with intense scans is ending up on a deny list. If the target utilizes a reputation-based service or WAF like BrightCloud or CloudFlare, this can block our scans and end up giving a false negative for the result. BBOT has built-in features that allow it to be run in an agent mode, allowing a decentralized infrastructure. Our road map for a new release will have our I/O feature set, which will extend this capability.

We did not attempt to resolve this issue; if a WAF was present and blocked our detection mechanism, we simply moved on to the next target.

Eating the Elephant

Now that we had all of our targets, configuration, and assets ready, we could finally head out on this safari. First, we used our preset configuration and a subset of our target list and began enumeration.

Telerik Herd

Background

CVE-2017-9248 is a cryptographic weakness in Telerik UI for ASP.NET AJAX DialogHandler, allowing attackers to gain access to a file manager utility that supports arbitrary file uploads, often resulting in remote code execution (RCE). The vulnerability arises from an information leak in error messages during the decryption of Telerik “DialogParameters,” a set of encrypted configuration values echoed back to the server as user input.

Attackers can exploit these error messages to systematically deduce the Telerik.Web.UI.DialogParametersEncryptionKey. With this key, they can decrypt and re-encrypt the parameters, gaining unauthorized access to the file upload utility, which they can then abuse to upload and execute files on the server.

Discovery

Targeting the Telerik software first, we kicked off our initial segment scan to identify endpoints reported by the list we generated. Out of the first 10,000 assets, we only were able to discover 567 “DialogHandler” endpoints, which is only a roughly 5.7% true positive rate. While there were other Telerik endpoints discovered that may be associated with other CVEs, we focused on this specific endpoint for our research. Of the 567 endpoints we validated, only 31 were found to be vulnerable, representing approximately 5.5% of the total validated endpoints. This is still a fairly large number for a 8-year-old vulnerability.

Extending this logic to the rest of the target list yielded 7,635 total sites that had the “DialogHandler” endpoint, of which 1,291 were still vulnerable to the CVE. In other words, approximately 17% (nearly one fifth) of publicly accessible Telerik sites had vulnerabilities that could be exploited to allow unauthorized file uploads. The discovery of Telerik endpoints in assessments is always exciting for BLS operators, as it often presents a high-probability and low-effort opportunity for success.

One specific consideration regarding the Telerik herd is the fact that multiple other CVEs for Telerik could also be vulnerable (e.g., CVE-2017-11317, CVE-2019-18935, CVE-2024-1801). However, these additional CVEs were not in our scope to assess. Additionally, not all Telerik sites have the “DialogHandler” endpoint enabled, and not all installments of Telerik use the default locations; this was evident in the percentage of reported sites using Telerik vs. the true positive endpoints discovered (12,755/122,698; 11%).

DotNetNuke Herd

Background

CVE-2017-9822 is a deserialization vulnerability in DotNetNuke (DNN). It affects versions 5.0.0 through 9.3.0 and can lead to RCE. The vulnerability is tied to the DNNPersonalization cookie, which is used to store personalization settings for anonymous users.

Exploitation occurs when custom application code (or pages, such as custom 404 error pages—a common default) processes the DNNPersonalization cookie without properly validating its content. This allows an attacker to craft a malicious serialized object, embed it in the cookie, and trigger its deserialization on the server.

Discovery

For the DotNetNuke web technology, we had to use custom detection tooling (which we will not be releasing) in order to validate the vulnerability. The default BBOT module triggers a benign exploit validation, which executes code on the server and should only be run with authorized use. We obtained a total of 59,702 sites from the list. The first scan returned a positive rate of 794 out of 10,000 sites vulnerable to the CVE (8%; higher than the percentage from the first Telerik scan).

Expanding this scan to the rest of the total sites cataloged resulted in 4,485 vulnerable sites running DotNetNuke. Overall, 7.5% were vulnerable to the CVE allowing for code execution. Again, this is with the caveat that the BBOT module only examines default exploitable locations within DotNetNuke. The CVE often manifests itself through custom pages; however, no additional analysis was performed against the sites. Across all of the scans, the technology DotNetNuke was observed on a total of 48,741 sites. Of the sites we positively identified as running DotNetNuke, 9.2% were vulnerable to the CVE.

AjaxPro Herd

Background

CVE-2021-23758 is a critical vulnerability in Ajax.NET Professional (AjaxPro) versions prior to 21.11.29.1 that allows attackers to achieve RCE. The issue arises from the framework’s deserialization process, which fails to adequately validate user-provided JSON data. Attackers can craft malicious payloads that contain specially formatted type information to exploit this weakness, enabling them to execute arbitrary code on the server.

A key aspect of this vulnerability is its unauthenticated nature, which makes it particularly easy to exploit. Many versions of AjaxPro include a default class, ICartService, which is often enabled by default and exposes a method that accepts arbitrary objects. The combination of a default exploitable class and a lack of authentication greatly increases the risk to applications using the vulnerable framework.

Discovery

The final herd we went after in our safari was AjaxPro. Again, for this vulnerability, we had to develop custom tooling in order to validate that the site was vulnerable. For AjaxPro, our list contained 12,036 sites running the software—definitely a smaller scale compared to the first two herds.

Out of the 12,306 sites, 1,755 were confirmed to be vulnerable to the CVE allowing deserialization. Of all AjaxPro sites being cataloged, 14% were vulnerable to this CVE. This particular herd had the highest false-positive rate out of the safari that required the custom tooling for validation. A large caveat to this web technology is the custom locations often observed. The other two herds are more often deployed with default locations and configurations. We’ll be looking for ways to improve the detection accuracy of the module in the future.

After-Meal Thoughts

After completing our research, we were surprised by the alarmingly high percentages of true positive vulnerabilities identified in these web technologies. It is concerning that despite some of the CVEs dating back as far as 2017, nearly double-digit percentages of vulnerabilities persist for each technology. Combining these vulnerabilities with supplementary discovery methods greatly increases the likelihood of identifying additional exploitable weaknesses.

While we specifically and carefully enumerate our customers’ organizations and businesses for our ASM service, for this exercise, we adopted a strategy much closer to the way a real attacker’s campaign would be structured. If an attacker’s goal is just to find as many vulnerable systems as possible, we have demonstrated how they could leverage the numerous online services that exist solely to identify and track the technologies used by websites. Once a specific technology is identified, vulnerabilities associated with it become much easier to exploit, especially for older technologies with CVEs that have publicly known exploits. Real threat actors are conducting this research constantly, looking for systems to exploit.

This highlights the need for any company to leverage a robust ASM service, like the one we provide, to continuously monitor and assess their digital footprint. While Black Lantern’s ASM service does conduct these scans and discover these vulnerabilities, we take it one step further, and our analysts conduct in-depth analyses of attack surfaces. By implementing an ASM program, a business can identify and mitigate these risks before they are exploited.

At Black Lantern Security, we understand the importance of staying ahead of emerging threats. That’s why our enterprise ASM service, powered by BBOT, continuously monitors your attack surface for the latest vulnerabilities and provides proactive coverage against emerging threats. Start protecting your organization today by signing up for our ASM service. Contact us now to get started and secure your digital footprint!

Subscribe now

Today we’re excited to announce a new web screenshot tool, Webcap.

Webcap is designed to fill the role of Gowitness, but with some additional advanced features that make it ideal for pentesting and bug bounties, while enabling easy integration into your bash or python scripts.

In an upcoming release, it will replace Gowitness as the primary web screenshot module in BBOT.

Features

In addition to the usual features expected from a web screenshot tool, Webcap has some new and unique capabilities. Some of these capabilities make it easier to use, while others appeal to advanced users.

Webcap stays extremely lightweight by interfacing directly with the Chrome Devtools API. It doesn’t depend on any frameworks like Selenium, Puppeteer, or Playwright, and doesn’t use any third party headless libraries. Instead, it natively implements only the features it needs.

Web Interface with Perception Grouping

Webcap’s web interface comes equipped with a feature that groups similar screenshots together, allowing you to browse quickly through them. This works by way of a perception hash which is calculated for every screenshot.

This perception filter is designed to ease the pain of scrolling through pages of identical screenshots.

JSON Output

Webcap supports JSON output in the terminal. This includes comprehensive data extracted from the browser session.

Capturing of JavaScript

In addition to capturing the fully-rendered DOM, Webcap also detects any JavaScript parsed by the browser. It outputs these individually, for later analysis.

Capturing of Individual Requests + Responses

Webcap captures every request and response made by the browser in the course of loading the page. This includes iframes, AJAX API calls, JavaScript files, and more. These are included in the JSON output.

OCR Text Extraction

Finally, Webcap can extract visible text from the fully-rendered page. Since this uses OCR, it includes rasterized text from images.

Upcoming Features

Here are some features we plan on adding soon:

• Technology Detection

• Custom JavaScript injection

How to Install

pipx install webcap

Example Commands

Scanning

# Capture screenshots of all URLs in urls.txt
webcap scan urls.txt -o ./my_screenshots

# Output to JSON, and include the fully-rendered DOM
webcap scan urls.txt --json --dom | jq

# Capture requests and responses
webcap scan urls.txt --json --requests --responses | jq

# Capture javascript
webcap scan urls.txt --json --javascript | jq

# Extract text from screenshots
webcap scan urls.txt --json --ocr | jq

Server

# Start the server
webcap server

# Browse to http://localhost:8000

Conclusion

We hope you find this tool useful. Stay tuned for more features, and for the imminent Webcap module in BBOT!

If you have questions or ideas, please let us know on the Webcap Github, or ping us in the Black Lantern Security Discord.

Happy hacking!

BBOT’s new features make it easier to use, while significantly speeding up scans.

Above: A chord graph of the relationships between BBOT's modules and the data types they produce/consume. Click the image to explore it interactively.

How did we get here?

Two years ago we released BBOT (Bighuge BLS OSINT Tool), an open-source scanner inspired by Spiderfoot. Its initial claim to fame was its ability to find more subdomains than any other tool. Since then, it's been steadily gaining users, and as of today, it's been downloaded 400K times. It's always wonderful to hear how people are using it in the bug bounty space. Whenever we hear that BBOT got someone a new payout by finding an outlier subdomain, or a critical RCE, it warms our hearts!

BBOT's success is a result of the countless contributions from the community (thank you!), which include many of the powerful new modules and features in 2.0. Development has been happening at a fast pace. To give you an idea, BBOT has already passed 4,000 commits, surpassing even Spiderfoot (with ~3,700), a tool that has been in active development for ten years! That is how much work has been going into BBOT -- both by us at BLS, and by the community -- and how we've already arrived at version 2.0!

New Features in 2.0

BBOT 2.0 keeps BBOT's original recursive design, while adding some powerful new features and optimizations.

Note: For full release notes, see Upgrading to BBOT 2.0.

Highlights

Here are the three main feature highlights for BBOT 2.0:

• Presets: An alternative to command-line flags that let you conveniently store your entire scan config in a single YAML file.

• BadDNS: Find subdomain hijacks and other DNS-related vulns.

• Speed Optimizations

  • YARA integration by @paulmmueller == insane boost in regex performance!

  • New DNS/HTTP Engines by @thetechr0mancer == leverage all your CPU cores!

Presets

Presets are one of the biggest features in BBOT 2.0. They were born out of necessity, to save you from having to construct giant BBOT commands. This was something we discovered early on: that due to BBOT's extreme customizability and the fact that it had over 100 modules, commands could get out of hand pretty quickly:

Presets solve this by consolidating all your scan settings into a single YAML config. You can create your own, or choose from a list of built-in presets.

You can list them all with -lp:

# list BBOT presets on the command-line
bbot -lp

And enable them with -p:

# enumerate subdomains on evilcorp.com
bbot -t evilcorp.com -p subdomain-enum

You can also mix and match an unlimited number of presets:

# combine subdomains + web spider
bbot -t evilcorp.com -p subdomain-enum spider

You can also create your own custom preset that includes other presets:

target:
  - evilcorp.com
  - 1.2.3.0/24

blacklist:
  - test.evilcorp.com

# include other presets
include:
  - subdomain-enum
  - spider

config:
  web:
    http_proxy: http://127.0.0.1:8080
  modules:
    github:
      api_key: 258e88dcbd3cd44d8e7ab43f6ecb6af0

Run BBOT with your custom preset:

bbot -p ./my_preset.yml

For a full list of built-in presets, see Full List of Presets.

For details on Presets, see the Documentation.

BadDNS

BadDNS is a slick DNS-hijacking tool written by @paulmmueller that's integrated into BBOT 2.0. It replaces BBOT's old subdomain_hijack module, and detects a myriad of vulnerabilities including dangling records.

For details, see the BadDNS Blog Post.

Speed Optimizations

BBOT 2.0 includes several very significant performance improvements, along with numerous small ones. These have combined together to make BBOT 2.0 close to 10x faster than its predecessor.

The two most significant performance-boosting features are YARA integration and new DNS + HTTP engines.

YARA Integration

Initially, we used Python's built-in regex library to mine useful goodies (emails, URLs, subdomains, etc.) from various sources like HTTP responses. This was effective, but not very efficient. Lots of regexes multiplied against lots of data resulted in serious slowdowns for the scan.

In BBOT 2.0, @paulmmueller has completely overhauled the excavate module to use YARA. This not only provides an insane speed boost (YARA has some wicked algorithms for this), it allows you to add on your custom YARA rules. Pair this with the work @Domwhewell has done to download Git repos and docker images, and pair that again with his module that extracts text from practically every file format known to man, what you effectively have is a grep -R for your target's entire web presence. Oh, and he also made a Trufflehog module to search all of that for secrets.

Yeah, we’ve all been busy. Stay tuned for new developments on these features. It's only going to get crazier!

New DNS / HTTP Engines

Before (BBOT v1)

After (BBOT v2)

Early on in BBOT's development, we transitioned to using asyncio. This simplified the code, and resulted in better stability and performance.

However, we are constantly looking for new ways to speed up scans, and the next bottleneck we encountered was in asyncio itself. Specifically, BBOT was issuing so many DNS and HTTP requests that it reached the max capacity of an asyncio loop within a single CPU core.

To address this, we've introduced an optimization to the way BBOT interacts with DNS and HTTP, which gives DNS and HTTP each their own dedicated Python process and asyncio event loop. To achieve this without the dreaded overhead of multiprocessing, we use ZeroMQ in a ROUTER/DEALER configuration. ZeroMQ enables extremely fast and efficient communication between the processes.

Community Shout-outs

Finally, we want to give special thanks to four specific members of the community, who have been most active in contributing to BBOT:

• @Domwhewell for continuing to create loads of powerful modules for secrets-looting and more.

• @Shadow for testing every new feature ruthlessly, and showering us with awesome ideas! (and congrats on writing his first module).

• @colin-stubbs for bringing his DNS expertise to BBOT by adding CAA-record capabilities (and many more to come!).

• @nicpenning and @CarsonHrusovsky for integrating BBOT with Elasticsearch.

Thanks guys, you’ve been awesome to work with! Let’s keep building this thing!

Black Lantern Security is publicly releasing our new Python DNS auditing tool, BadDNS.

It’s primarily a subdomain takeover detection tool but covers other DNS related issues like zone transfers and NSEC walking as well.

Some of the discussion assumes prior knowledge of various DNS record types and of subdomain takeover concepts. Here’s a good primer for those who need it.

Introduction

Let’s jump into the obvious question first: Why another subdomain takeover tool? 

There are lots of subdomain takeover tools already, including some we really like. But, we wanted to pair solid subdomain takeover detection with exceptional domain discovery, so as to be able to look for these issues at massive scale, and against the hardest to find domains. That is why although BadDNS is a standalone command line tool, it is built from the ground up to integrate into BBOT with its own BBOT module.  

We are simultaneously releasing BadDNS and also upgrading our existing subdomain takeover capabilities in BBOT to use BadDNS. 

Integrating an existing tool into BBOT in this case wasn’t straightforward, and would have required us to make a lot of compromises that would have introduced significant performance issues and limited some of our detection methodology.

We are also doing a few unique things that most other tools aren’t, such as with our references and txt modules. Before we talk about those, let’s start by going though all of the modules, beginning with those that may be the most familiar.  

BadDNS Modules

• cname - Check for dangling CNAME records and interrogate them for subdomain takeover opportunities

• ns - Check for dangling NS records and interrogate them for takeover opportunities

• mx - Check for dangling MX records and assess their base domains for availability

• nsec - Enumerate subdomains by NSEC-walking

• references - Check HTML content for links or other references that contain a hijackable domain

• txt - Check TXT record contents for hijackable domains

• zonetransfer - Attempt a DNS zone transfer

cname

Dangling CNAMEs are the most common type of subdomain takeover; this module detects several types of takeovers associated with them. This can include service-specific takeovers, like those pointing to Azure or AWS assets, for example. The logic for this type of takeover is usually wrapped up in signatures, which we will discuss more later.  

It will also look at the parent domain, to see if it’s unregistered or expired (using WHOIS data). If you can takeover the parent domain, you obviously control all it’s subdomains as well.

ns

Dangling NS records are also fairly common, although it’s getting harder to find exploitable ones recently. AWS’s route53 service used to be one of the more reliably exploitable types of dangling NS records. We aren’t exactly sure what AWS is doing behind the scenes to protect their customers (if anyone knows, please share!), but they are definitely doing something. However, we have confirmed that it is still at least sometimes possible to successfully perform a takeover with them. 

Like CNAME takeovers, NS takeovers are also based on signatures because exploitation depends on the particular service they are associated with. 

mx

A takeover based on a dangling MX record can be accomplished if the base domain is available for registration. BadDNS will use WHOIS data to attempt to detect this condition.  

Taking over a dangling MX record allows attackers to intercept and potentially manipulate email communications, leading to data breaches, loss of confidentiality, and compromised email functionality. The severity of the impact depends on the priority settings of the MX records. 

references

The references module starts to cover some ground most tools don’t. This detects takeovers in JavaScript or CSS includes present in the HTTP content of the target. Another way to think of this kind of takeover is as a “second-order” subdomain takeover. Control of the domain where JavaScript is loaded from has roughly the same consequences as a stored cross-site scripting vulnerability, for example. Behind the scenes, the cname module is being called against the domains found to be hosting JS/CSS content. 

In the future, we plan to also look at domains found in CORS/CSP headers vulnerable to takeovers.

txt

The txt modules looks at DNS txt records for domain names. If it finds one, it runs the cname module against them. A hit here might not be significant at all – it completely depends on how the organization is using the txt record, which is probably all over the map.

This type of detection is the least likely to be exploitable - but if it is, it could be very interesting. If you get a detection here, it's worth doing the takeover and just spinning up a server and seeing what requests get sent to it. 

The previous BBOT subdomain_hijack module introduced this concept, and we expand on it with BadDNS.

zonetransfer

The zonetransfer module in BadDNS specifically targets the potential vulnerability associated with DNS zone transfers, a critical process for synchronizing record information between a primary DNS server and its secondary servers. While zone transfers are vital for DNS operation, they can expose an organization's full DNS records if not properly secured.

The zonetransfer module attempts to perform a zone transfer on the authoritative name servers for a target domain. If the attempt is successful, it not only completes the zone transfer but also compiles and presents all harvested records, potentially unveiling a detailed map of the organization's DNS infrastructure. 

nsec

The nsec module in BadDNS utilizes “NSEC walking” to enumerate DNS zones by exploiting the way NSEC records function within DNSSEC. NSEC records, intended to secure DNS by confirming the absence of specific DNS entries, inadvertently disclose the name of the next domain in the zone sequence. The module leverages this feature to make sequential queries, effectively mapping the entire domain structure within a DNS zone, including subdomains and entries that may be sensitive or intended to remain private. This enumeration can reveal a comprehensive view of the DNS zone's structure, including details not intended for public access. 

With both zonetransfer and nsec, when used with BBOT, any discovered domains are automatically fed back into the scan.

Generic Detections

Another important concept with BadDNS are “generic” detections. This occurs when a dangling CNAME or NS record is found, but there is no signature match indicating the possibility for exploitation. Alerting on these are important for the discovery of new subdomain takeover signatures, as they will essentially point out which services are frequently producing dangling records and therefore need to be researched. In BBOT, these will be emitted as FINDING events (whereas signature detections will be VULNERABILITY events). 

Signatures

That brings us to the other big reason for creating BadDNS – the issue of takeover signatures. 

Currently, there isn’t a single source of signatures or research into takeovers. However, we have found the most useful signatures are those in Nuclei Templates, and within the tool dnsReaper. For discussions and research, the community has coalesced around the GitHub repository can-i-take-over-xyz. Its issues page has become a common location for discussions about takeover techniques. 

We have observed a hesitancy in the community for any one entity to become the ‘authority’ on takeover signatures, which we completely understand and share ourselves. This directed our approach of ingesting the best sources of signatures already present and converting them automatically into our format. Currently, we ‘absorb’ signatures from Nuclei and dnsReaper using automated GitHub actions. These are then generated into pull requests we can quickly and easily review, complete with automatic testing of the generated signatures. This allows us to utilize whatever the community comes up with in terms of new signatures, while not making ourselves the direct maintainers of them, and also allowing us the room to create our own signatures or modify existing ones if needed.  

Usage

Here’s some basic usage information to get you started:

CLI 

First of all, the standalone BadDNS CLI is embedded within our pypi package. So all you need to do is install with pip: 

pip install baddns

After that, you can run BadDNS by just typing `baddns` in your console.  

Usage

Positional arguments:
 target                subdomain to analyze

options:
 -h, --help            show this help message and exit
 -n CUSTOM_NAMESERVERS, --custom-nameservers CUSTOM_NAMESERVERS
                       Provide a list of custom nameservers separated by comma.
 -c CUSTOM_SIGNATURES, --custom-signatures CUSTOM_SIGNATURES
                       Use an alternate directory for loading signatures
 -l, --list-modules    List available modules and their descriptions.
 -m MODULES, --modules MODULES
                       Comma separated list of module names to use. Ex: module1,module2,module3
 -d, --debug           Enable debug logging

BBOT 

Using BadDNS with BBOT allows for checking for DNS related issues at immense scale, taking advantage of its cutting-edge DNS recon capabilities. 

For information on using BBOT, please refer to the BBOT Documentation.

To do so, just run bbot with -m baddns(the baddns package will automatically be install by BBOT). To combine with subdomain enumeration, run it along with the subdomain-enum flag, as shown below: 

bbot –f subdomain-enum –m baddns –t <targetdomain>

Research

One goal for BadDNS is that it can be used as a starting point for research into novel DNS-related vulnerabilities. Its modular design and import-friendly architecture facilitate rapid prototyping of new detection code.

We have already encountered instances of DNS behaving in bizarre and unexpected ways. For example, during the course of creating the ns module, we discovered that many DNS servers were essentially lying to us about NS records. If the NS record was present, but there was no associated SOA record (basically the definition of a dangling NS record) all but a small percentage of servers would happily report back that there were no NS records at all.

We wondered how much this behavior may have affected other tools’ ability to detect dangling NS records. The solution isn’t too complicated - we just need to perform a fully recursive lookup for these records, ignoring any caching, starting at the root DNS servers and moving forward. This was so important for detecting dangling NS records that we built our own recursive resolving class from scratch.

The weirdest thing was actually that something like 5% of DNS servers would always tell us the truth and report the dangling NS records. We briefly considered using this handful of servers as a shortcut, but ultimately decided that was not sustainable and wrote the recursive lookup code instead.

We are also looking forward to exploring more unusual behavior in newer DNS components like NSEC3 and other parts of DNSSEC. The added complexity that comes along with the added security potentially creates more opportunities for abuse.

Since then, the tools have received some neat upgrades and there are even some new ones on the block. We decided it would be fun to do an updated face-off for 2023, and we're glad we did because we encountered some surprises along the way - like this suspiciously good subdomain API (more on that later)!

The goal of this face-off is to rank the top subdomain enumeration tools based on: 1) number of subdomains found, and 2) runtime.

Tools being tested:

• BBOT

• theHarvester

• Subfinder

• Amass

• OneForAll

• Spiderfoot

• Findomain <-- new this time around

• Sublist3r

We selected these tools mainly based on their quality and popularity. If you don't see yours in this list, please let us know so we can test it next time!

Rules

The theme this year is airlines. We will be running each of the above tools against both a large target (Delta Airlines: delta.com) and a small target (Spirit Airlines: spirit.com). By testing against both a large and a small target, we can see how well each of the tools scale with the size of the attack surface.

Similarly to last time, we will be running each tool out-of-the-box with no API keys and only the minimal config changes required to enable brute force and boost thread count.

Wildcards and unresolved subdomains will be removed using this script.

Results

Subdomains Found:

Runtimes (Lower is Better):

Analysis

The first thing you might notice is that while the outcomes for the small target (spirit.com) were pretty close, delta.com produced a lot more variety. Specifically, there is a big gap between BBOT, theHarvester, Amass, and everything else. There is an interesting explanation for this, which leads us on a fun side-journey out of the land of tools and into the land of APIs.

As it turns out, a single data source is responsible for this difference. First added to Amass only two months ago, subdomain.center is a new and mysterious API created by the Automated Reconnaissance & Pwning Syndicate. It is free to use, with a limit of 3 requests per minute, and needless to say it is now also a BBOT module.

I call it ‘mysterious’ because it's mysteriously good. Subdomain.center returns more subdomains than any other free API by a huge margin. It returned 1,594 valid delta.com subdomains, while RapidDNS (its runner up) returned only 774.

The most mysterious thing about this API is the data itself. Its database is full of strange and complex (but totally valid) subdomains that don't seem to show up anywhere else. No other free APIs contain this data, and none of the tools we're aware of are capable of discovering them via brute force. Even BBOT's massdns module with its NLP-powered subdomain mutations couldn't replicate a fair number of them.

I reached out to ARPSyndicate hoping to find some answers as to the source of their data, but they declined comment except to say that they are “continuously aggregating and analyzing DNS datasets”. Truly then, it's a mystery where they got them. But who cares? They're giving them away for free!

(UPDATE 8/6/2023: Subdomain.center’s website now says, “Subdomain Center utilizes Apache's Nutch, Calidog's Certstream, OpenAI's Embedding Models & a few of our proprietary tools to discover more subdomains than anyone else.”)

Runtimes

Runtimes are all over the place. Subfinder and Findomain roughly tie for the fastest tool, both finishing in less than 15 seconds. These tools are not performing any brute forcing, only querying APIs. But damn, are they fast! A fun side note: Subfinder is written in Golang, and Findomain in Rust. Always nice to see some friendly competition between Gophers and Rustaceans. :)

Amass and Spiderfoot are the big offenders here. I actually chose to shrink their footprints in the graph because they were dwarfing the other tools' results. In the case of delta.com, both Amass and Spiderfoot had to be cancelled after 6 hours.

Subdomains

But enough about runtimes. Give me subdomains, you say! Give me as many subdomains as humanly possible!

In that regard, BBOT has you covered. As the creator of BBOT, I may be a little biased, but regardless of how you slice it, it's the clear winner in this category. BBOT found the most subdomains for both spirit.com and delta.com, gathering 44% more subdomains on average for Spirit, and 118% more for Delta than the other tools.

Conclusion

Most Subdomains: BBOT

Fastest: Tie between Subfinder and Findomain

Honorable Mention: theHarvester

Details

BBOT

Version: 1.1.0.2001

Command:

bbot -t <domain> -f subdomain-enum -c modules.massdns.max_resolvers=5000

spirit.com:

• Subdomains: 235

• Runtime: 5 minutes, 15 seconds

delta.com:

• Subdomains: 1964

• Runtime: 30 minutes, 18 seconds

theHarvester

Version: 4.4.0

Command:

theHarvester.py -d <domain> --dns-brute --dns-lookup -b anubis,baidu,bevigil,binaryedge,bing,bingapi,bufferoverun,brave,certspotter,criminalip,crtsh,dnsdumpster,duckduckgo,fullhunt,github-code,hackertarget,hunter,hunterhow,intelx,netlas,onyphe,otx,pentesttools,projectdiscovery,rapiddns,rocketreach,securityTrails,sitedossier,subdomaincenter,subdomainfinderc99,threatminer,tomba,urlscan,virustotal,yahoo,zoomeye

spirit.com:

• Subdomains: 191

• Runtime: 3 minutes, 15 seconds

delta.com:

• Subdomains: 1607

• Runtime: 5 minutes, 1 second

Subfinder

Version: v2.6.1

Command:

subfinder -d <domain> -silent

spirit.com:

• Subdomains: 183

• Runtime: 4.9 seconds

delta.com:

• Subdomains: 696

• Runtime: 10.2 seconds

Amass

Version: v4.0.3

Command:

amass enum -d <domain> -active -brute

spirit.com:

• Subdomains: 185

• Runtime: 69 minutes, 58 seconds

delta.com:

• Subdomains: 1598

• Runtime: Cancelled after 6 hours

OneForAll

Version: git clone 2023-07-25

Command:

oneforall.py --target <domain> run

spirit.com:

• Subdomains: 169

• Runtime: 2 minutes, 28 seconds

delta.com:

• Subdomains: 811

• Runtime: 7 minutes, 26 seconds

Spiderfoot

Version: git clone 2023-07-25

Command:

sf.py -s <domain> -t INTERNET_NAME -n

spirit.com:

• Subdomains: 175

• Runtime: Cancelled after 6 hours

delta.com:

• Subdomains: 712

• Runtime: Cancelled after 6 hours

Findomain

Version: v9.0.0

Command:

findomain -t <domain>

spirit.com:

• Subdomains: 174

• Runtime: 4.0 seconds

delta.com:

• Subdomains: 721

• Runtime: 13.6 seconds

Sublist3r

Version: git clone 2023-07-25

Command:

sublist3r.py -d <domain> --bruteforce

spirit.com:

• Subdomains: 68

• Runtime: 12 minutes, 49 seconds

delta.com:

• Subdomains: 172

• Runtime: 17 minutes, 11 seconds

BBOT (Bighuge BLS OSINT Tool) is Black Lantern Security's flagship OSINT tool. We use it every day on penetration tests and as the backend for our Attack Surface Management (ASM) offering. Some of us also leverage it for bug bounties in our off time (we're not double-dipping, you're double-dipping!).

BBOT gets a lot of testing. Continuous execution against such large fortune-500 targets is sure to uncover every kind of horrible edge case imaginable, and rest assured it has. As the creator and primary maintainer of BBOT, I've taken part in more than a few tense debugging sessions and frantic troubleshootings. It's been really challenging, and sometimes even grueling (our testing has so far uncovered two nasty race conditions in well-established networking libraries). But what doesn't kill you makes you stronger! And it's exactly this cycle of testing and improvement makes BBOT the powerful tool that it is.

As we round out this phase of dev, we are proud to announce the arrival of BBOT 1.1.0. And since we'll be presenting it at DEF CON's Demo Labs, it is hereby dubbed - “DEF CON Release”!

(For those attending DEF CON, we will be presenting BBOT on Saturday August 12th from 12 p.m. - 2 p.m. in the Caesars Forum Boardroom - official forum link.)

New Feature Highlights

Documentation

BBOT now has full-fledged, searchable documentation! Below is a table of contents:

• Basics

  • Getting Started

  • How It Works

  • Comparison to Other Tools

• Scanning

  • Scanning Overview

  • Events

  • Output

  • Tips and Tricks

  • Advanced Usage

  • Configuration

  • List of Modules

• Contribution

  • How to Write a Module

• Misc

  • Release History

  • Troubleshooting

Asyncification

BBOT's threading system has been completely overhauled to use asyncio. What used to be a complex system of thread pools and threading locks is now one clean, well-oiled event loop.

What does this mean? Mainly it means BBOT is leaner and meaner. Its memory footprint is smaller, it’s more efficient, and most importantly, it's fast. Thanks to asyncio (and other small tweaks and optimizations), BBOT is now roughly 40% faster.

A BBOT Scan in Real-Time - Visualization with VivaGraphJS

Other

Features:

• Better handling of DNS wildcards.

• New and improved subdomain mutations (massdns module).

• Ability to list flags and their descriptions (-lf).

• Precise rate-limiting for HTTP and DNS.

• Better tests (one for each individual module, 91% test coverage).

• New and improved paramminer modules.

New Modules:

• Git (detects exposed .git folder on websites)

• Subdomain Center (subdomain enumeration)

• Columbus API (subdomain enumeration)

• MySSL (subdomain enumeration)

• Sitedossier (subdomain enumeration)

• Digitorus (subdomain enumeration)

• Nmap (port scanner, more reliable than naabu)

  • naabu has been removed due to reliability issues.

• NSEC (DNSSEC zone-walking for subdomain enumeration)

• OAUTH (enumerates OAUTH / OpenID-Connect, detects sprayable endpoints)

• Azure Realm (detects managed/federated Azure Tenants)

• Subdomains output module

Conclusion

We've been hard at work on BBOT, and we hope it serves you well in your exploits! If you have questions or comments, please come talk to us in Discord. If you have an idea for a new feature or find a bug, please open an issue on our Github.

Thanks for reading, and we hope to see you at DEF CON!

We all know how much developers love to copy and paste things from Stack overflow. 

But, what happens when a cryptographic secret is part of what gets copied? What if a project is forked from another project on GitHub and contains a pre-defined secret? What about when an official example code contains pre-filled in secrets? Looking at you, Microsoft. 

Let’s keep picking on Microsoft and look at the Machine Key. 

If someone copies this configuration, they are going to be using a Machine Key which is freely available on the internet. Without diving into the details, possession of the Machine Key with .NET apps is equivalent to code execution (if you want to dive into the details, go here).

To exploit this situation, we have used the tool Blacklist3r in the past. Blacklist3r will take a viewstate (a cryptographic product of the Machine Key), and attempt to decrypt/validate the viewstate using a collection of known keys. The key shown in the Microsoft documentation is in Blacklist3r’s key list, so using it would likely lead to someone getting RCE on your application. It’s also interesting to just Google one of the keys (like FBF50941F22D6A3B229EA593F24C41203DA6837F1122EF17) and see just how many results it shows up in. That key even appears in physical books published almost a decade ago. 

Diving a bit deeper into Blacklist3r for a moment - it is not without its drawbacks. The main annoyance is that because it is a C# application, it is Windows dependent; unless you want to run Mono which is not without its own pitfalls. It’s also relatively slow; and although slowness is not a big deal when attacking one application, when doing things at scale, it can be very inefficient. 

We created a BBOT module (if you do not know about BBOT, stop and go here) which was a wrapper around Blacklist3r to detect known Machine Keys. It worked, but the headaches around having Mono as a dependency got to be too much, and thoughts of making a pure Python Machine Key checker started to materialize. 

Recreating C# encryption functionality in Python IS as painful as it sounds, but it would be worth it to remove that dependency? But wait – isn't this a problem on other platforms? There must be a ton of situations where known (or just painfully weak) secrets get used and create security vulnerabilities. ASP.NET Machine Keys were one of the few cases where a tool even existed to exploit this, and Python-based tools for non-Python frameworks just did not exist. 

This is the vision of Badsecrets: a 100% pure Python library, which can facilitate checking the cryptographic products for known secrets across many platforms. It has a module-based design, which will make adding additional frameworks later a more straightforward process. And, since we are also the creators of BBOT, we have created an accompanying BBOT module to make finding this type of security weakness efficient at “bighuge” scales.  

Currently, there are ten eleven twelve modules:

• ASPNET_Viewstate - Checks the viewstate/generator against a list of known Machine Keys. 

• Telerik_HashKey - Checks patched (2017+) versions of Telerik UI for a known Telerik.Upload.ConfigurationHashKey.

• Telerik_EncryptionKey - Checks patched (2017+) versions of Telerik UI for a known Telerik.Web.UI.DialogParametersEncryptionKey. 

• Flask_SignedCookies - Checks for weak Flask cookie signing passwords. Wrapper for flask-unsign.

• PeopleSoft_PSToken - Can check a PeopleSoft PS_TOKEN for a bad/weak signing password.

• Django_SignedCookies - Checks Django's session cookies (when in signed_cookie mode) for known Django secret_key.

• Rails_SecretKeyBase - Checks Ruby on Rails signed or encrypted session cookies (from multiple major releases) for known secret_key_base.

• Generic_JWT - Checks JWTs for known HMAC secrets or RSA private keys.

• Jsf_viewstate - Checks both Mojarra and Myfaces implementations of JavaServer Faces (JSF) for use of known or weak secret keys.

• Symfony_SignedURL - Checks Symfony "_fragment" URLs for known HMAC key. Operates on Full URL, including hash.

• Express_SignedCookies - Checks express.js signed cookies and session cookies for session secret

• Laravel_SignedCookies - Checks 'laravel_session' cookies for known laravel 'APP_KEY'

Just the ASPNET_Viewstate module alone is already a full-blown replacement of Blacklist3r, which is faster and has no non-Python dependencies (we’re not knocking the guys at NotSoSecure who built it – they inspired all of this!).

There are other cases where a Badsecrets module can replace existing tools. The PeopleSoft_PSToken module can fully replace (at least for detection) the now homeless and hard to find TockenChpoken tool from 2015.

Previously, for JavaServer Faces (JSF) Viewstate exploitation, your best bet was one of a handful of random Python scripts floating around which only worked against a specific implementation and version of JSF, which were apparently created for a particular HackTheBox box.

Limitations 

The consequences of using known cryptographic keys vary widely across the modules. In some cases, it will result in an almost 100% chance of an RCE. In other cases, it may merely facilitate a privilege escalation by allowing control of a secure cookie. One thing Badsecrets does not much with is the actual exploitation of these vulnerabilities. It will help you find them, but you are generally on your own from there. Sometimes exploitation will be very straightforward, and in other cases it might require a lot of follow-on work or chaining with other vulnerabilities. This probably won’t change, as we do not really want to enable people to get RCE on systems when they have not put in even basic research to understand the vulnerabilities which they want to exploit.  

Use Cases 

There are some included “example” scripts. These include a general “CLI” utility (cli.py) which can accept any cryptographic product and try it against all modules at once. Blacklist3r.py is essentially a CLI recreation of Blacklist3r. Telerik_knownkey.py is a brute force tool that utilizes cryptographic functions within the Telerik-based Badsecrets modules.  Symfony_knownkey.py can identify known Symfony HMAC keys, even when a sample hash can not be identified.

Despite the provided examples, Badsecrets is designed to be a library used by other tools. The most immediate example of this is the Badsecrets BBOT module, which makes much of its functionality immediately accessible in a way that can identify critical security vulnerabilities at scale. 

Badsecrets has a couple of different “levels” it is designed to be used at. The most basic way is to load up a particular module, then submit a corresponding cryptographic product to it, and find out if that product was created with a known or weak secret. 

It can also be used to “carve” data out of HTML content. For example, you can hand the carve functionality a page with an ASP.NET viewstate in it, and let it automatically find and test the viewstate without bothering with manually grabbing it.  

The way our BBOT module interacts with Badsecrets is by taking advantage of the “carve_all_modules” functionality. Modules can include a special regex which helps the carve functionality find a particular type of secret. The carve_all_modules function checks an HTTP response against every available Badsecrets module. If it finds a matching secret, it moves on to trying to use all its known keys against it, as defined by the detecting module. Any matches get forwarded to BBOT’s event system, and just like that, you have yourself a confirmed critical vulnerability – all from merely parsing HTML content.  

This can also be accomplished with the cli.py example script. This is not very fancy, but it is meant to be an example implementation of a CLI-based interface with Badsecrets. You can supply the “product” directly or use the –url mode to actually visit a page and try to carve for one.  

Some of the bad secrets detected by Badsecrets naturally lend themselves quite nicely to massively-scaled detection. This is because the cryptographic product in question is automatically presented on the page, and most or every page within the application. This applies to the ASPNET_Viewstate module, to the Jsf_Viewstate module (looking for JavaServer Faces viewstates), and to a much lesser extent - the Generic_JWT module.  

However, not all the modules are going to work well with BBOT because the cryptographic products don’t just automatically appear on their own. In most cases, this is because the product in question is a cookie, which is usually only assigned after authentication. In these cases, it may be easier to manually check the secret, either using cli.py or manually from a Python console. This applies to the Django_SignedCookies, Rails_SecretKeyBase, and Flask_SignedCookies modules. This is why Badsecrets was started as a stand-alone project and later integrated into BBOT, and not just a BBOT component. BBOT can take parts of Badsecrets and make them scale beautifully, but is much less helpful in other cases.  

In the case of the Telerik Badsecrets modules, finding a page which directly displays the `DialogParameters` value might be difficult. It will only appear on a page that utilizes the Telerik UI text editor utility.  Without diving too far into the technical details of Telerik UI vulnerabilities (we’ve already done that elsewhere), it is the kind of thing that you’d be more likely to spot when looking through your Burp Suite history after testing an application, as opposed to being able to scan a lot of targets for it at once. 

However, our included example utility (Telerik_knownkey.py) only requires the Telerik.Web.UI.DialogHandler.aspx endpoint and will brute force with all of the Telerik encryption and/or hash keys, even if a page containing the editor cannot be located or does not exist. This is the only public tool capable of exploiting fully patched versions of Telerik UI!

This is a good example of how one of the biggest benefits of Badsecrets: it’s a repository of various cryptographic implementations which might be otherwise not available in Python. For example, to make the telerik_encryptionkey module work with all known versions of Telerik UI, a Python implementation of C#’s specially modified pbkdf1 key derivation function had to be implemented, which deviates from the standard used by every other language. If anyone else should be unfortunate enough to need this in Python, it is available as a standalone class in helpers.py.  

Hopefully, others will find these individual components useful and use them in other tools. 

Populating Keys 

To get the known keys we check against, we used a combination of sources. One is just grabbing what is already out there in the community, such as with Blacklist3r’s existing Machine Keys. We also took a queue from Assetnote and used Google BigQuery to scrape all of GitHub for keys when we could. They have a database which includes all the code on GitHub, which is astounding, and incredibly useful (for both good and evil). This ended up letting us add on to existing collections of keys for some modules and build a good starting set for others which have not had one. But, be cautious with BigQuery – you can rack up hundreds of dollars in charges quickly if you are not careful! 

Future 

The goal for Badsecrets is to become the standard bearer for this classification of ‘vulnerabilities’ (really, misconfigurations). Hopefully, there will be community contributions which can continue to grow the available modules and cover more web frameworks and utilities. We would LOVE it if someone just made a brand new module and submitted a pull request! But, a fantastic way people can contribute is to add to the known keys lists if they encounter one that we do not have that are also publicly exposed. Even just requests for modules to cover a specific framework would be immensely helpful!  

Feature Set

For starters, the BLS-Bible is packed with features:

• Multiple deployment types to suit your operational needs

• Markdown rendered pages

• In-app editing

• Tag-based, filterable searching

• Regular expression searching with optional context

• Threat profiles

  • Exportable to PDF, ATT&CK Navigator

  • Calculate percent-match to known APTs

• MITRE ATT&CK mapping for guides via tags

• Version control thanks to Git

• Apochrypha - Git sub-modules so you can pull in your favorite repositories of knowledge

• Assessalonians - Git sub-module specifically for your organization’s private repository of knowledge

• Apostles - A leaderboard to rank the entire community’s contributions to the BLS-Bible

• Developer tools - A collection of utility functions to help maintain the knowledge-base

• Themes - Easily switch between premade color schemes or make your own

Instead of writing at length about each of these, it is easier to demonstrate with images.

Markdown Rendering

All files under the /Data directory can be rendered to screen in a human readable format. This includes programs/scripts as well with full syntax highlighting. The reading window has the table of contents on the left pane and has custom history management as well as navigation at the top. Clicking a link within the page will take you to that page. The arrow buttons allow you to traverse forward and backward through your reading.

In-App Editing

On specific deployments (dev, ops) you can edit pages within the application itself. The syntax and functionality available are nearly equivalent to what you’d expect when using GitHub. If you want to make a quick edit on your local system or deploy a temporary ops server to edit on collaboratively during an assessment, you can. Once you’re ready to push your content additions, you can commit your changes to a new branch and request a pull into the development branch.

Tag-Based, Filterable Searching

The basic search functionality is built around tags (#@tag) that are included within each page, as well as the naming of the folders and pages themselves. These tags are indexed to provide a very responsive list of results.

You can further filter down the results shown to you in your search results, as well as the main screen. Selecting these filters will show you those resources containing the relevant tags. Selecting known threat profiles will filter to the techniques associated with the threat profiles.

As you can see above, according to MITRE’s data, APT41 is known utilizing the listed techniques, and those techniques happen to contain AD.

Regular Expression Searching with Context

While tagging is helpful, not everything is going to be tagged perfectly. Additionally, we include content from other amazing public projects and can’t expect them to adhere to our tagging system. For those reasons, you can also perform a regex or advanced search for the thing you’re looking for. This will take a regex pattern and search through every file within the project (including external projects) and provide you with a list of files containing the pattern match. You can also bump up the context setting to see for sure if that’s the file you are looking for.

Threat Profiles

It made sense to allow end users the ability to create their own threat profiles within the application. With threat profiles, you can add techniques to your custom threat profile as you proceed through your assessment. At the end of your assessment, you’ll have a list outlining the techniques you used against the target environment.

Exporting Threat Profiles

If your client is interested in learning more about the techniques used, you can export the threat profile directly to a PDF document that you may share with your client.

You can also export your profile or profiles directly to an ATT&CK Navigator file to be ingested into this widely-used application.

Matching Threat Profiles to APTs

Another helpful feature is the ability to compare your custom threat profiles to known advanced persistent threats (APTs) as tracked by MITRE. This gives you an idea of how well you are emulating known attackers.

MITRE ATT&CK

Since we are including the MITRE ATT&CK framework into the application, it also made sense to give a visual representation of what techniques each guide was employing. This is handled through placing tags within the guide for the individual techniques being used.

Additionally, if you are trying to recreate a specific ATT&CK technique, it is helpful to quickly see which guides you can use to help you execute your actions.

This isn’t just restricted to offensive security. While the Blue Testament isn’t well built out currently, the goal is to have full coverage for offensive and defensive security professionals alike. With greater contributions to the Blue Testament, we will start to see overlap (in purple, of course) in the tactics, techniques, and procedures (TTPs) where we have mapped both the offensive and defensive strategies.

Apocrypha

It is not our goal to reinvent the wheel or reproduce what is already out there. At the same time, we want to make sure we have access to the materials we rely on as security researchers. For these reasons, we’ve included Apocrypha which utilizes Git sub-modules to pull in high-value repositories like PayloadsAllTheThings and HackTricks. If you stand this up on your own attack box or op-specific server before entering an unknown network, you will be sure that you will have all the resources you need to get the job done.

We take advantage of the fact that most (if not all) knowledge-base repositories are written using Markdown. This allows us to render their contents in the same way as our own content.

Apostles

To give everyone their fair shake and some public bragging rights, we included the Apostles. This is a leaderboard that ranks contributors to the project based on the number of pull requests submitted, and the number of files changed. This feature will require you to use your own GitHub API key (public read-only) to properly function. We hope this becomes a fun way to add some competition into spreading quality knowledge throughout the community.

Developer Tools

This block of features is primarily aimed at those who want to help maintain the repository. The endpoints are only accessible on dev deployments but will give you quick readouts for things that may need to be addressed or updated as the project continues to grow in content.

Themes

Lastly, what is a good application without some ability to change how it looks. Included are five dark mode themes that can easily be switched between. Thanks to the simple way the colors are defined, it is very easy to create your own custom themes and have them submitted for general use.

For the Community

We sincerely hope this tool finds those who are experiencing the same pains we were without knowledge-base management. We welcome contributions and suggestions to the project at the GitHub repo (one more time in case you missed it). Please feel free to reach out to anyone at BLS with any questions or ideas you may have about the project on our Discord server or directly over Twitter (@codymartin, @blacklanternllc).

Black Lantern Security (BLS) is happy to announce a new milestone has been achieved in the development of enter_the_matrix (ETM). A full CRUD API has been introduced that gives users the ability to integrate ETM into their workflows and reporting capabilities.

The API is available with full Swagger documentation to help you test and create your integrations as easily as possible. Authorization is required on all API endpoints and is handled by supplying the X-API-Key custom header and a key generated within ETM.

Each API key has granular permissions that are controlled within the administrative section of the application. Keys can be limited to specific resource types, specific CRUD operations, and specific assessments.

Through the new API, you can pull out data to produce interesting metrics about yourself as an organization as well as your client’s organizations. Create reports using tools like PowerBI to present a history of attack scenarios used against your client or show which vulnerabilities you’ve used as a consultant to cause business impact. The metrics you create through the general use of ETM also paint a picture of how you as a consultant operate. Understanding this information can help you improve areas you may not execute in often, or simply show how well you match up to the adversaries you are emulating.

To learn more about the ETM API and its capabilities, head over to https://github.com/blacklanternsecurity/enter_the_matrix, deploy ETM, and navigate to the /swagger endpoint for full documentation. We hope you find these updates useful, and we look forward to continuing to improve ETM in the future. If you have any questions or ideas for future development work, please feel free to reach out over in our Discord server, by submitting an issue on GitHub, or directly over Twitter (@blacklanternllc, @codymartin)

Several vulnerabilities with the popular ASP.NET web application add-on Telerik UI for ASP.NET AJAX have become a frequent source of “easy-wins” for operators at BLS. Discovery and exploitation are usually straightforward, and they result in remote code execution on public-facing IIS servers.

Although use of the Telerik UI library has declined somewhat in the wake of several severe vulnerabilities, it’s hard to find an organization with IIS servers that doesn’t have at least an application or two using it. Even though patches have been available for years, we still encounter vulnerable versions on a regular basis in 2022.

There has been a significant amount research into this particular library already, and there are existing tools to detect and exploit it. However, after finding some unusual edge cases where existing tooling failed, we decided to take a deep look into the library for ourselves.

Vulnerable Endpoints

The vulnerabilities revolve around a couple handler endpoints that interface with the Telerik.Web.UI.dll library. The vulnerable .dll can be found in the /bin folder of the application it is being utilized in. The URL to .dll mapping occurs in the application’s web.config, and looks something like this:

<handlers>
    <add name="Telerik_Web_UI_DialogHandler_aspx" verb="*"       
        preCondition="integratedMode" path="Telerik.Web.UI.DialogHandler.aspx" 
        type="Telerik.Web.UI.DialogHandler" />
    <add name="Telerik_Web_UI_SpellCheckHandler_axd" verb="*" 
        preCondition="integratedMode"     
        path="Telerik.Web.UI.SpellCheckHandler.axd" 
        type="Telerik.Web.UI.SpellCheckHandler"/>
    <add name="Telerik_Web_UI_WebResource_axd" verb="*"   
        preCondition="integratedMode" path="Telerik.Web.UI.WebResource.axd" 
        type="Telerik.Web.UI.WebResource"/>
</handlers>

The path variable in the config entry defines the URL that the the server will watch for, and the type parameter defines what class within the .dll the URL maps to.

Telerik.Web.UI.WebResource.axd?type=rau

The Telerik.Web.UI.WebResource.axd endpoint is the most well-researched and the most commonly exploited. It will not be the focus of this post, but it’s worth mentioning to provide context. The two main vulnerabilities here are CVE-2017-11317, an arbitrary-file upload made possible by a hard-coded default key. The next is CVE-2019-18935, an unsafe deserialization vulnerability. The deserialization vulnerability typically depends on the file upload; they need to be chained.

The real advantage CVE-2019-18935 provides is that the uploaded file can go anywhere on disk, whereas getting an RCE from a file upload usually requires write access to the web root. This increases the number cases where the 2017 CVE is exploitable.

For this endpoint, a blog post by Bishop Fox has really become the definitive guide for understanding and exploiting it. If you want to know more that should be your next stop. It’s also worth noting this blog post talking about the research around the 2019 deserialization vulnerability.

Telerik.Web.UI.DialogHandler.aspx

That leaves us with Telerik.Web.UI.DialogHandler.aspx. Note that it is deceptively not an .aspx file but just another handler mapping to the Telerik.Web.UI.dll library.

Note: Some web frameworks that include Telerik UI map this functionality to Telerik.Web.UI.DialogHandler.axd instead.

The dialog handler exploit is the less exploited but probably more fun little brother to the “rau” endpoint. The central issue is some poorly designed/implemented cryptography “protecting” a set of parameters that are used to initialize a file manager interface. It’s designated as CVE-2017-9248, and here’s the official CVE description:

Telerik.Web.UI.dll in Progress Telerik UI for ASP.NET AJAX before R2 2017 SP1 and Sitefinity before 10.0.6412.0 does not properly protect Telerik.Web.UI.DialogParametersEncryptionKey or the MachineKey, which makes it easier for remote attackers to defeat cryptographic protection mechanisms, leading to a MachineKey leak, arbitrary file uploads or downloads, XSS, or ASP.NET ViewState compromise.

This description is somewhat lacking, and doesn’t give a good sense of what’s going on. The big prize is getting access to the file browser, from which you can look around the file system and upload files. Although you can see directory listings and filenames, to our knowledge you can’t download anything so we’re actually not sure what the official description is referring to there. Regardless, as you may be aware, uploading a malicious .aspx to the webroot will result in code execution in most cases.

Unpatched Telerik UI Encryption

To get to the file upload, we’ve first got to get around the “encryption” protecting the dialog parameters. How does it work?

String with Dialog Parameters -> Base64 -> Rotating XOR -> Base64 (again).

Decryption is the opposite:

Un-base64 -> Rotating XOR -> Un-base64 again -> Parse the string for dialog parameters.

Needless to say – this is very unusual, and well… not good. Not only is a notoriously weak encryption scheme in use (rotating-key XOR), but it’s being used essentially as a form of authentication.

During decryption, the interaction between the XOR and the second base64 operation has some very interesting effects and is the source of the exploit as we’ll see soon.

At a high level, a couple basic cryptography principles explain where this encryption goes wrong:

Never ‘roll your own’ cryptography. This is a good example of the unexpected ways cryptography can go sideways when it’s deployed incorrectly. There’s almost no better example of breakable encryption than rotating key XOR, but that was even further undermined by the error messages leaking details about the decryption process. There’s a pretty large skill-gap between knowing enough to make cryptography functional and knowing enough to make it truly secure. It’s best to leave as much of the implementation as possible to the web framework or language being used.

Encryption is not authentication. Encryption is only meant to protect confidentiality, and any limited protection to integrity is an incidental side-effect of it. The success or failure of a decryption operation should not be used as a form of authentication.

To protect integrity, utilize hashing and signing. There are also encryption schemes that deliberately incorporate integrity protection alongside the encryption. A great example would be AES-GCM, which is encryption with built-in authentication.

The patched version of Telerik UI utilizes AES in CBC mode paired with HMAC256 to validate the integrity of the message before attempting decryption, which is mostly driven by encryption libraries built into C#. Although the implementation wasn’t perfect, this is a dramatic improvement.

Exploit Details

When we send a request to Telerik.Web.UI.DialogHandler.aspx, our encrypted dialog parameters get sent via the dp GET parameter. When they are decrypted, if something is wrong, we will receive an error message with the specific reason why. Since we are base64 decoding after we decrypt, we get a little information leak that tells us if what was decrypted is valid base64 or not.

It turns out, all these different error messages leak enough information about the process to completely decrypt the message and discover the encryption key. It is possible to use this information to continually reduce the possible values for the key through a series of systematic requests, and ultimately discover the entire key. In many ways, this closely resembles a padding oracle attack, but instead of abusing the AES block padding we are abusing the properties of base64 encoding.

A brief primer on base64 padding

Base64 encoding is the practice of mapping data, usually 8-bit characters, into sequences of 24 bits, which are then represented by a series of four 6-bit characters.

Storing text in base64 comes with some overhead cost. For each block of four base64 characters, we can represent (at most) three 8-bit characters (or 8-bit chunks of binary data). Base64 data exists at a 4:3 ratio compared to its unencoded form.

We also might have a situation where we need to represent just one or two characters. This is where padding comes in. The “=” character is used to represent padding in base64. If one character is being represented, “==” will be appended as the padding. If the base64 block is representing two characters, “=” will be appended.

Note: Not all base64 implementations use padding, but the one used by Telerik UI does.

dp_crypto

The existing tool for cracking the key is called dp_crypto. We have used this many times in the past, and when it works, it works well. However, we eventually discovered an instance where dp_crypto could not solve the whole key. It would get about half-way through and just get stuck. One thing we noticed about this key after solving it later, was that it wasn’t only hex characters like the others we’d seen. Instead, it appeared to be comprised of random characters within the ascii-printable range.

After extensive testing our conclusion was that for hex-only keys, the tool worked great, but for random ascii keys, it was a bit of a crap-shoot. The tool is making assumptions about the key and doing some optimizations that would occasionally cause it to follow a false branch that led to a dead-end. These optimizations could be turned down, and in some cases this would result in finding the key. Still others were completely unsolvable. In addition, even when it worked, the process was slow and made a significant number of http requests in the process.

We give a lot of credit to the tool’s author, there are some very clever things going on. To come up with what he did with nothing else to work from is notable. We’re spoiling the punchline a little, but building our tool relied heavily on a lot of the existing logic in dp_crypto.

SR Labs Blog Post

Confused by the strange half-solved key we set out to see if anyone else had encountered this or had another solution. That quickly led us to the blog post Achieving Telerik Remote Code Execution 100 Times Faster by Security Research Labs.

We were very impressed by the research they did. They, in fact, did identify a much more efficient technique for deducing the key. The blog post is well written, complete with lots of easy to understand graphics. They step through a tool they built and walk through the difference in the exploit technique compared with dp_crypto in detail.

However, they opted to not release the tool. Going through the details of a tool but not releasing it seemed a little odd to us. In their post teased that they used a “little trick” to get one of the more difficult obstacles of this exploit to work, but declined to describe how they did it, and we were interested to know.

“Note: If password includes “=” sign (which is a valid base64 character), there is a little trick to be made, which will not be covered in this blog post.”

We did eventually figure out how to deal with “=” in the password with a extra pain. We nevertheless give the authors a ton of credit for the concepts they come up with and their detailed descriptions of them, which we leaned on heavily.

dp_cryptomg

That brings us to the tool we are releasing: dp_cryptomg. Our goal when we started writing it was to attempt to implement the techniques described in the SR Labs blog post, which would hopefully help to retrieve our previously irretrievable key.

Although we never wanted to make a new tool (especially in the midst of an engagement), it seemed worth it given we’d net an RCE for the engagement and it’s a great opportunity to dive into a really unique and interesting cryptography problem.

Let’s take a closer look at the technical details of the tool. Our goal is to deduce the original key, which we do this one base64 “block” at a time. In the context of each block, we can solve individual characters of the key one at a time.

For each character, we can send a series of “probes”. The goal of each probe is to answer the following question:

Given these 4 bytes we’re sending you, after you decrypt them using your rotating XOR key, does the result equal valid base64 or not?

The final result for each probe is a Boolean value, which reveals a little more information about the key for that position. Specifically, we can narrow down the possible candidates for what the key at the same position could be.

By sending the probe and checking for the “Index out of range” error message, we will know whether the bytes in our probe end up being valid base64 or not after being XOR’d with the key.

We can determine ahead of time which key characters will produce a true result and which will produce a false result for a given probe and use this data to reduce the number of candidates of characters which could be the key. This is the essence of the exploit.

The following is a simplified simulation, which has been slowed down to help conceptualize the process.

As we continue to send more probes, each “true” result will split the remaining set of possible characters. Eventually, we end up with a single possible character left, which we can be confident is the key character for that position.

We apply our partially solved key and move to the next character position and repeat the process for the rest of the block. One of the nice things about an XOR operation, is that sending 0x00 in a given position means we aren’t changing anything there. Therefore, we can effectively target the character we want to solve by sending 0x00 to the three positions we don’t want to affect.

The following chart breaks down the process that takes place for each individual probe as the server receives it.

The SR Labs blog post also describes this process in great detail and is worth a read if you still haven’t fully grokked the concept. They go on to describe how they found a few specific probe bytes that can be used to efficiently triage the characters into initial groups. However, the blog is less clear on how to select the correct probe bytes to take the process to a conclusion.

Choosing the Probes to Send

The SR Labs research discusses their strategy for choosing probes based on the likelihood of a given key character appearing in the key. They discuss the specific probe bytes that their research suggests are the most efficient in terms of doing some initial triage to what “bucket” the key character belongs to.

But what about after that? How do we keep determining the right bytes to send, all the way to the end where we end up with the solution? Our solution diverged from the SR labs technique here. The technique is not particularly elegant but was very effective: try every possible probe byte in an offline simulation and see which one splits the remaining possible values the most evenly.

The computational cost of “brute forcing” the optimal probe is negligible, and insignificant when compared with the network delay to the victim server.

The “=” Problem

It is worth noting that we only really learn something actionable on ‘true’ results. This is counter-intuitive, instinct would suggest that regardless of the result we can split them, selecting one bucket or the other. However, if we get a negative result, we must simply throw it away. Why? We can’t trust it because of the small possibility that are negative result was caused by the XOR randomly decrypting to an “=” in the wrong place. Only with a “true” result, which reaches down to where the plaintext is being parsed, can we make any definitive determinations about the key. This little annoying property of the “=” is easy enough to deal with, although it does reduce efficiency significantly.

The most challenging consequence of the unique properties of the “=” character occurs when the key itself contains one. This is because whenever it is used as a key in the same position as one of the \x00 bytes in our probe, it will result in a “=” (an XOR operation when one side is a null byte does not change anything).

So why exactly does that matter? Well, depending on at which position of the four byte base64 block the “=” key character is present in, the rules about whether “=” makes valid or invalid base64 change in according with base64 padding. For example, a “=” is always okay in the fourth position, sometimes ok in the 3rd position (only if the fourth is also a “=”) and never ok in the 1st or 2nd positions.

We eventually discovered that there are a special very specific series of probes than can help us find out if there are “=” characters in the key. We can use them to identify any equals signs in the key before we proceed as normal with the rest of the technique.

Note: The following section has been updated since release as we later discovered a rare edge case that can cause a false-positive when it comes to detecting a key byte being an equals.

If we send the following probes:

\x00\x00\x00\x01 - Result = False

\x00\x00\x00\x02 - Result = False

\x00\x00\x00\x00 - Result = True

\x00\x00\x00\x05 - Result = True

\x00\x00\x00\x16 - Result = True

\x00\x00\x00\x71 - Result = True

If the x01 and 0x2 probes are both they are both false (they both produce invalid base64), and the 0x00,x05,x16, and x71 probes are true, the key byte in question is a “=”. We can provably claim no other character will have the same combination of probe results.

With this pre-calculated set of probes, we can cover every possibility when it comes to an equals character being in the portion of the key we are trying to solve. This is best illustrated by looking at the functions implementing this.

With this special case out accounted for, the block can be solved using probes generated by the findSplittingProbe function.

When all blocks finish, the key will be revealed and saved to a .txt file. Just as with dp_crypto.py, a link will also be generated with a pre-populated dp GET parameter, which is set up to load the file manager tool and is encrypted with the newly discovered key.

Note: There was a bug in versions before 0.1.3 where pre-2010 versions of Telerik where the key could be retrieved but could not be exploited because of subtle differences in how the dialog parameters were parsed. This has now been fixed. It may be the case that this is the first public tool that has ever been exploit exploit these versions of Telerik, as admittedly we did not have a pre-2010 .dll to test with during development.

A note on the fancy interface: There’s no particular reason it needed to be built this way, however it can be really helpful for understanding when doing exploits against cryptography to get some kind of visual indication of what’s going on. It is also just more fun to look at.

That said, if you want a more simplistic view, just run it with -s. This will provide a more traditional command-line output. Running with -S will even further reduce the output shown. Using these modes will also increase the speed of the exploit.

Telerik.Web.UI.SpellCheckHandler.axd

While our minds were deep inside the Telerik UI Library, we wondered about the third endpoint, shown in the configuration example at the beginning of this post, of which we had seen next to nothing written about. The Telerik.Web.UI.SpellCheckHandler.axd endpoint appeared to use the same DialogParameters scheme as the DialogHandler endpoint, with the same Base64 -> Rotating XOR -> Base64 encryption routine.

With some very minor adjustments to the existing tool (namely, the Telerik.Web.UI.SpellCheckHandler.axd endpoint wants a POST request, where certain other parameters must be present), we quickly realized we could easily extract the exact same key by reusing the same technique. dp_cryptomg will automatically detect if the provided URL is for the SpellCheckHandler.axd endpoint and adjust its behavior accordingly.

The DialogHandler endpoint is mostly dangerous because it allows for file uploads, which (usually) lead straight to RCE on web servers. What could the SpellCheckHandler offer? Well, to begin with the key used is exactly the same. You could use the SpellCheckHandler to get the key, and then exploit the DialogHandler with it. Of course, you also could have just used the DialogHandler so not is much gained there.

With that limited utility in mind, we set out to see what we could do if we only had access to the SpellCheckHandler endpoint. Such a scenario is not so far-fetched. The other two endpoints are very well-known, and some web application firewall security vendors have chosen to address the vulnerabilities by simply blocking repeated attempts to access them. In other cases, a developer might be made aware of the vulnerable Telerik endpoint and simply opt to remove their handlers and replace the functionality they were using, while neglecting the SpellCheckHandler endpoint because it is not mentioned anywhere.

The results of our efforts were admittedly somewhat disappointing but still worthy of discussion. We are still pulling on a few interesting threads that are not quite ready, but there is at least one we have ran all the way to ground.

Telerik.Web.UI.SpellCheckHandler.axd Arbitrary .txt file write

Once you know the Telerik.Web.UI.DialogParametersEncryptionKey key, it is simple to decrypt and re-encrypt dialog parameters. With the SpellCheckHandler.axd endpoint, the encrypted dialog parameters are sent in the Configuration POST parameter. We have included a simple utility in our GitHub repo (dp_manual_crypt.py) which can be used to manually encrypt, decrypt, and modify the encrypted dialog parameters for both endpoints, as depicted in several screenshots to follow.

As an example, with the key set to DEADBEEFDEADBEEFDEADBEEFDEADBEEF our Configuration parameter value ends up as follows:

FgItLiYCKTAmKAc9JxMHLiACJjcQKAM1J3cUNw8GPRQhKwMuGAAhESd0MR0RKwcuCXQLNxs/CxUddAcdEyshHwkDCysYACEBHXQXMBAoMRAJdQs3Gy4hch0/NQYgAj0wIHUHLxgAC3cndhMyIBY9AR0SOT4YFjI8CAMTPSYSEHERdgMoIAI9AiUCFy4jdAc/JnYbNBgCEz8IABssIA0LKggBCDcPLzEEJSgHcBQdDzUIABssIA0LKggBADcULiERJ3QxHRErBy4hERcdFSkhDCATGxIjdhMQCXULNxsuIXIWAgcMFCg1LgkCKSsbKHQVJ3QxHREdExwTAik2

When we decrypt this with the DEADBEEF key, we can see how the parameters are constructed:

DictionaryPath,False,0,QzpcdGVsZXJpa3Rlc3RcQXBwX0RhdGFcUmFkU3BlbGxc;AllowAddCustom,False,3,True;SpellCheckProvider,False,2,2;AjaxUrl,False,0,VGVsZXJpay5XZWIuVUkuU3BlbGxDaGVja0hhbmRsZXIuYXhk

The format for each parameter being used is as follows:

ParameterName,Boolean,Integer,Base64EncodedValue;

Then, each parameter is separated by a semicolon.

We can safely ignore the Boolean value; it is just used to defined whether the parameter is an array or not. The integer defines what data type the parameter is:

• 0 for string

• 1 for int

• 2 for Enum

• 3 for Bool

• 4 for DateTime

Note: These particular base64 decoded values end up being C:\teleriktest\App_Data\RadSpell\ for DictionaryPath and Telerik.Web.UI.SpellCheckHandler.axd for AjaxUrl.

These are not the only parameters that can be used, and by having a quick look at the decompiled Telerik UI .dll we can see what our options are for the SpellCheckHandler endpoint.

The one we are interested in here is the CustomDictionarySuffix. This parameter is used to help define where custom word lists get saved on the file system. These word lists are created or appended to when a user uses the “add to dictionary” functionality within the spellcheck editor.

This value in this parameter is concatenated into the path of the custom dictionary file. There is no sanitization or validation of the encrypted parameters, as a result we can use directory traversal characters to erase the beginning of the path and choose both the file path and name of the file. The only thing which can’t be changed is the .txt extension, which is appended onto the end of the string.

We then base64 encode this value and encrypt it back into the dialog parameters along with all the existing values.

The encrypted dialog parameters are added to a request to the SpellCheckHandler endpoint with CommandName set to AddCustom and CommandArgument set to the text we wish to write to the file. Note that it is also possible to write binary data using this method, by simply URL-encoding any non-standard bytes.

If the file is not already present, it will be created. If it exists, the content will be appended to it.

Of course, the fact that we can only write .txt files is a huge caveat and significantly reduces the impact. By itself, it is of little to no value outside of a denial of service attack by way of filling the server’s disk with junk. However, it is important to remember that getting arbitrary content onto the disk of a system is often a critical step in larger attacks. Consider a local file include (LFI) vulnerability; in such a case the .txt file can elevate the LFI into remote code execution.

There may also be specialized applications running on a server which is also using Telerik UI that performs some special action with .txt files in a particular directory.

Summary and Conclusions

We have improved on existing tooling surrounding CVE-2017-9248, increasing the scope of the exploit to cover vulnerable but previously unexploitable systems. We took a deep-dive into a few of the more challenging aspects of making the exploit work properly.

The Telerik.Web.UI.SpellCheckHandler.axd finally gets some attention, and with dp_cryptomg it can now be used to retrieve the DialogParametersEncryptionKey as well. We highlighted an interesting abuse specific to the SpellCheckHandler, albeit one with a limited use case.

It is worth mentioning that, although all of the issues discussed in this post are patched, many of the underlying coding mistakes were not. For example, rotating XOR encryption was replaced with a standard AES-CBC implementation, but it was implemented with a static initialization vector. This is still a vast improvement but is a pretty clear violation of accepted best practice and potentially opens the door for some fascinating exploits.

All of lack of sanitization of user-input, and path-traversal bugs are still present even in fully patched versions, they are just locked behind the new encryption. We believe there are more bugs to discover in this library, including within versions fully patched today. In fact, based on our current research we believe this blog will likely end up with a couple sequels. We cannot divulge details yet, but there is certainly more research to share in the near future, stay tuned.

What is the best subdomain enumeration tool in 2022?

The goal of this face-off is to answer this question, ranking the top subdomain enumeration tools based on:

1) The number of subdomains they're able to find

2) The time it takes to find them.

Tools being tested:

• Amass

• Subfinder

• TheHarvester

• Sublist3r

• Lepus

• OneForAll

• Spiderfoot

• BBOT

If you're a veteran OSINTer, you're probably familiar with most of the tools on this list — with the exception maybe of BBOT. BBOT is a new OSINT tool inspired by Spiderfoot, written here at Black Lantern Security, and released a little over a month ago. Like Spiderfoot, BBOT isn't exclusively a subdomain enumeration tool, but we designed it with subdomain enumeration in mind, which is a reason why we chose subdomain enumeration for its first real test. A subdomain enumeration benchmark seems like a good “christening” that will either mock or (hopefully) validate our efforts on the tool.

After sharing the results, we'll go over the exact command we ran for each tool, and details on any unique subdomains it uncovered.

Rules

Target: tesla.com

• Active enumeration is allowed (HTTP/SSL)

• Free APIs only. No paid APIs will be used in this test.

  • The purpose of this rule is to gauge the effectiveness of a tool in gathering FREE and OPEN SOURCE information without any tedious/expensive preconfiguration.

• Wildcards and unresolved subdomains don't count. Subdomains must have at least one valid DNS record of type A, AAAA, MX, TXT, NS, SOA, SRV, or CNAME. The output from every tool will be cleaned using the same method.

• DNS brute-forcing is allowed. However all tools will be configured to use the same base subdomain wordlist. This is intended to show off each tool's unique capabilities instead of only its wordlist quality. Also, since runtime is a factor in the results, this helps keep the scan durations more comparable.

• Default settings only —no weird config changes.

  • With the exception of 1) the common brute wordlist and 2) bumping the thread count (because we have blazing fast internet), we will be using tools' default settings. Tool defaults should always be reasonable and we will avoid messing with them as giving more attention to the configuration of a single tool may give it an unfair advantage over the others.

Setup

The benchmarks will be performed on a modest Linode VM with the following specs:

• 2 dedicated CPU Cores

• 4GB RAM

• ~3,000Mbps download / ~2600Mbps upload according to speedtest.net

Each tool will be run separately, with ample pause between runs to account for rate limiting, etc.

Results

Analysis

The true winner of this benchmark may differ depending on whether speed or thoroughness is more important for your OSINT process. For example, BBOT found the highest number of subdomains, but Subfinder found 90% of what BBOT did, and in about a tenth of the time.

BBOT uses a recursive model similar to Spiderfoot which is one of the reasons for its higher subdomain yield and subsequently higher runtime. But even considering the higher runtime, it severely outperformed Spiderfoot for the purposes of subdomain enumeration, as seen in both of the above charts. In our testing, we let Spiderfoot run for 48 hours, after which we were forced to cancel it.

One interesting data point which we've included below is the number of unique subdomains found by each tool. This number is calculated by comparing each tool's output to the combined output of every other tool, and asking which subdomains it found that none of the other ones did.

BBOT’s massdns module, which pairs its recursive methodology with smart mutations, ensured that BBOT claimed the highest number of unique subdomains. Amass found several thanks to its unique Maltiverse module, and Lepus' Markov Chain / Permutation functionality was able to uncover a few as well.

Details

# Note: Each tool's default resolver thread count was multiplied by 10

bbot -t tesla.com -f subdomain-enum -m httpx -c modules.massdns.max_resolvers=5000

https://github.com/blacklanternsecurity/bbot

Version: v1.0.3.736 (04 October 2022)

Subdomains: 409

Runtime: 12 minutes 19 seconds

Unique subdomains: 13

# Note: theharvester provides no way to specify custom wordlist, so its wordlists were manually modified
# theharvester did not allow for increased thread count

theHarvester.py --domain tesla.com --dns-lookup --dns-brute --source anubis,baidu,bevigil,binaryedge,bing,bingapi,bufferoverun,censys,certspotter,crtsh,dnsdumpster,duckduckgo,fullhunt,github-code,hackertarget,hunter,intelx,omnisint,otx,pentesttools,projectdiscovery,qwant,rapiddns,rocketreach,securityTrails,sublist3r,threatcrowd,threatminer,urlscan,virustotal,yahoo,zoomeye

https://github.com/laramies/theHarvester

Version: v4.2.0 (13 August 2022)

Subdomains: 376

Runtime: 7 minutes 10 seconds

Unique subdomains: None

# Note: subfinder does not support DNS brute-forcing

subfinder -domain tesla.com -all -t 100

https://github.com/projectdiscovery/subfinder

Version: v2.5.3 (03 August 2022)

Subdomains: 373

Runtime: 1 minute 17 seconds

Unique subdomains: None

# Note: Amass did not allow for increased thread count

amass enum -d tesla.com -active -brute -w subdomains-top1million-5000.txt

https://github.com/OWASP/Amass

Version: v3.20.0 (22 September 2022)

Subdomains: 342

Runtime: 8 minutes 42 seconds

Unique subdomains: 5

# Note: oneforall.py provides no way to specify custom wordlist, so its wordlists were manually modified
# oneforall.py did not allow for increased thread count

oneforall.py --target tesla.com run

https://github.com/shmilylty/OneForAll

Version: v0.4.5 (10 July 2022)

Subdomains: 312

Runtime: 2 minutes 4 seconds

Unique subdomains: 1

# Note: Each tool's default resolver thread count was multiplied by 10

lepus.py tesla.com --permutate --reverse --ripe --portscan --markovify -w subdomains-top1million-5000.txt --threads 1000

https://github.com/gfek/Lepus

Version: git clone (05 October 2022)

Subdomains: 171

Runtime: 15 minutes 59 seconds

Unique subdomains:

# Note: Spiderfoot's dnsbrute module doesn't support custom wordlists, so its wordlists were manually modified
# Spiderfoot's command line interface does not support increased thread count

sf.py -t INTERNET_NAME -n -s tesla.com

https://github.com/smicallef/spiderfoot

Version: v4.0 (07 April 2022)

Subdomains: 129

Runtime: 48+ hours (cancelled)

Unique subdomains: None

# Note: Note: Each tool's default resolver thread count was multiplied by 10
# Sublist3r doesn't support custom wordlists, so its wordlists were manually modified

sublist3r.py --domain tesla.com --bruteforce --threads 300

https://github.com/aboul3la/Sublist3r

Version: git clone (04 October 2022)

Subdomains: 46

Runtime: 3 minutes 39 seconds

Unique subdomains: None

Conclusion

Comparing these OSINT tools was a fun and educational exercise, and we hope you find the results helpful.

The best subdomain enumeration tools, by the standards of this benchmark, are:

• BBOT — MOST SUBDOMAINS

• SUBFINDER — FASTEST

• THEHARVESTER — Runner-up for both categories

Happy hacking!

BBOT is the OSINT tool you’ve been waiting for. In a single command, it can execute subdomain enumeration, port scanning, web screenshots, vulnerability scans, and more.

Install and Run

At Black Lantern Security, we do a lot of OSINT. In a way, OSINT is the foundation of everything we do. It's the common denominator between every type of engagement, whether for a red-team, attack surface evaluation, or the usual pentest. If you want to hack something, you first have to find it.

Historically, when it comes to OSINT, each of us have our own tools and our own processes that we like best. For a long time, we stuck to our individual methods because none of us could agree on which tools were best, and because old habits die hard.

But eventually, we began to see that our OSINT was suffering because of this fragmented approach. Some tools were good at some things and some were good at others, but no tool or tools were good at everything, and none of them fit together in a cohesive way.

So we began to envision a way of improving our capabilities by pooling our efforts into a tool that we could all use and trust -- a tool that would replace everything else. This is what we set out to create with BBOT.

But there are already plenty of OSINT frameworks available. Why choose BBOT?

BBOT is the culmination of years of manual OSINT-gathering experience. In short, it solves quite a lot of problems. But here I'm going to try and stay as brief as possible, hitting the main points that differentiate BBOT from other tools.

BBOT Features

• Recursive

• Graphing

• Modular

• Multi-Target

• Automatic Dependencies

• Smart Dictionary Attacks

• Scope Distance

• Easily Configurable via YAML

Great. Let's get into it.

Recursive

Most tools take a Phased Approach to OSINT. Combine the output from a bunch of miscellaneous command-line tools, sort, clean, and uniq it, then feed it into the next set of tools, sort, clean, and uniq it, and repeat.

What's the problem with doing it that way?

The problem is that a Phased Approach has a tendency to miss things.

Imagine you're enumerating subdomains for evilcorp.com. Your phases may look like this:

1. Query a bunch of subdomain APIs and do a big DNS brute-force

2. Combine the subdomains from the previous two steps, resolve them to IP addresses, and resolve the IP addresses back to domains again

3. Perform a port scan on every host

4. Visit the open ports on HTTP/HTTPS and parse results for more subdomains

5. Visit the open ports for SSL certs and parse results for more subdomains

6. Finally, clean and dedupe into a final list, making sure to filter out troublesome garbage like wildcard DNS entries.

If you've done any OSINT yourself, you may already see the problem. What if Step 5 yields a unique subdomain that you didn't have in Step 3? It's possible that subdomain has additional goodies such as PTR records, open ports, and web pages. Should you go back to Step 3 and run your port scan again? Should you go back to Step 2 and resolve it again? Or should you go all the way back to Step 1 and run the brute-force again?

The problem is that each of these steps rely on the output from the step before, which means that if your goal is to find as much as possible, it's not enough to only do this once. You have to repeat these steps again and again, each time feeding their output back into the beginning.

The point is that OSINT is simply not well-suited to a linear workflow. BBOT solves this with Recursion, which is its characteristic feature.

Instead of working in phases, BBOT's modules continually feed results to each other in real-time as they are discovered. Phases are not used because each newly-found piece of information is acted upon immediately, being fed back into the machine and used to continue the discovery process. This allows for the discovery of distant and well-hidden nuggets that a phased approach would not uncover.

You may recognize this recursive model from Spiderfoot. It is worth mentioning that before BBOT, Spiderfoot was my tool of choice, and it's where I learned the value of a recursive approach to OSINT. Spiderfoot is a brilliant tool, and I wanted it to be the one-stop OSINT tool at Black Lantern Security. But, ultimately, it couldn't stand up to our demands, and my efforts led, instead, to the development of something entirely new.

Graph Output

BBOT natively supports output to Neo4j. Other output formats include JSON, CSV, TXT, HTTP, Websockets, and more. You can even output to multiple destinations at once.

Modules

BBOT has over 50 modules and counting. Modules are written in Python, and each one is its own .py file. Modules are easy to write, and they have an arsenal of helper functions at their disposal to help make them the best they can be:

• Built-in threading and parallelization

• Zero-effort data sanitization and deduplication

• Automatic dependency installation (more on this later)

• Interact.sh integration for finding SSRFs and other web goodies

• Smart target-specific wordlist for DNS enumeration, bucket brute-forcing, dirbusting, etc. (more on this later)

• Configurable options via the CLI or BBOT's YAML config file

A sample module (mymodule.py):

Multi-Target

BBOT accepts unlimited targets, both from files and directly via the command line. Targets can be of differing types, e.g. IP addresses, DNS names, Subnets, etc.

Whitelists and blacklists are also supported, enabling granular scope control for pentest and bug bounty targets.

Dependency Handling

BBOT automates module dependencies with Ansible. When you install BBOT, you pipx install, and that's it. There's no fiddling with third-party tools and dependencies. Even if a module requires a special binary or a specific OS package, BBOT will install it for you.

Word Cloud

During each scan, BBOT gathers target-specific keywords from DNS names, web pages, etc., and compiles them into a shared wordlist that is accessible to all modules. This wordlist is saved at the end of a each scan, and can be used for password cracking, etc., or reused in subsequent scans.

BBOT's massdns module makes extensive use of the word cloud for subdomain brute-forcing. But this type of data is useful for all sorts of other tasks, such as dirbuster and storage bucket enumeration.

Scope Distance

Scope Distance is a unique feature of BBOT that allows you to control how far out BBOT will explore. Since BBOT is recursive, it needs to have an "exit condition" (i.e., a mechanism that tells it when to stop searching). This is where Scope Distance comes in. Each newly-discovered piece of data—an "Event" in BBOT terms—gets assigned a scope distance that represents how many hops away it is from the main scope.

By default, BBOT searches up to one hop away from your defined target, and although its DNS resolution spiders out to three hops, it will only output the data if it finds something that's in scope. Of course all of these settings are configurable via bbot.yaml.

YAML Config

BBOT's scanner and modules are configurable via a single YAML file. This is where you put things like API keys.

Conclusion

We hope you're as excited about BBOT as we are. But, why are you still reading about it? Go try it out!

https://github.com/blacklanternsecurity/bbot

Be sure to stay tuned for more BBOT content, including live demos and head-to-head comparisons with other OSINT tools.

Share

Subscribe now

This brings us to the Offensive-Azure toolkit. Our aim is to create or re-create tooling that is beneficial to the red team professional in a way that is platform agnostic. One of the main goals of this project is to keep the tools as open and loose as possible. We are publishing the toolkit in its infancy, and will continue to develop and release more tools under this umbrella project. In this initial release, we are releasing two tools:

• device-code-easy-mode.py

• token-juggle.py

The inspiration for these tools comes directly from the work done on AADInternals and TokenTactics. They are amazing tools that deserve recognition.

device-code-easy-mode.py

Original inspiration comes directly from Dr. Azure AD and his AADInternals project. He developed a workflow in PowerShell for creating the device code flow authentication process that required you to stand up and supply an SMTP server for the cmdlet to interact on.

The workflow present in AADInternals didn't fit with BLS operations, so we decided to make a simpler tool that requests the device code for you, presents it to you, and polls the endpoint for any authentication events. It is up to you to stand up your own email infrastructure and conduct this phish in a successful way. Like the cmdlet in AADInternals, we use the application ID for Microsoft Office. Presenting the victim with an authentication request for "Microsoft Office" helps reassure the victim that they are interacting with a legitimate process.

You have the option to set the targeted resource within the script; just choose from the URIs presented. For AzureAD usage, you'll want to use graph. This is supposed to be going away sometime in April 2022 in favor of ms-graph.

For use with all of the Az cmdlets, you'll need both graph and azure_management tokens. To request the other necessary tokens, you'll need to use our other new tool, token-juggle.py, with your refresh token to request additional tokens once the device code flow authentication is completed.

Usage

python3 ./device-code-easy-mode.py

• Send your phish with the code you are presented with as well as the devicelogin endpoint shown

• Wait for the target to perform the required steps

  • The device code authentication flow expires after 15 minutes. Note that social engineering may help you prep your target

Installation

git clone https://github.com/blacklanternsecurity/offensive-azure.git

cd ./offensive-azure/Device-Code/

pipenv shell

pip install -r requirements.txt

token-juggle.py

Inspiration for token-juggle.py comes directly from rvrsh3ll and his project TokenTactics. token-juggle.py requests a new access token for a Microsoft/Azure resource using a refresh token.

This script will attempt to load a refresh token from a REFRESH_TOKEN environment variable if none is passed with -r or -R.

After a successful refresh to a new access and refresh token pair, the response output will be saved to where you specify with -o|--outfile. If you do not specify an outfile, then it will be saved to ./YYYY-mm-DD_HH-MM-SS_<resource>_token.json. These can be passed back to the script for further use.

Usage

Using the environment variable:

export REFRESH_TOKEN=<refresh-token>
python3 token-juggle.py teams

Using a refresh token as input:

python3 token-juggle.py outlook -r <refresh-token>

Using an already saved token response from this script:

python3 token-juggle.py ms_graph -R <path-to-refresh-token.json>

Installation

git clone https://github.com/blacklanternsecurity/offensive-azure.git

cd ./offensive-azure/Access-Tokens/

pipenv shell

pip install -r requirements.txt

The Next Steps

We encourage everyone to watch the Offensive-Azure repository as we will be adding many more scripts in the near future that will include Azure Active Directory enumeration as well as scripts that will target the other major Microsoft applications.

Share

Subscribe now

Classically, password spraying has been the single lowest-effort and highest-yield technique for gaining an initial foothold in an organization. This made it pretty fun. You start by gathering up a big list of emails, then you kick off a spray with a stupid password like "Spring2022!", and spend the next ten minutes getting disproportionately large and debatably undeserved hits of dopamine as you discover just how many employees are using that stupid password.

But alas, with increasing Multi-Factor coverage and defensive countermeasures like Smart Lockout, password spraying is becoming more and more of a chore.

As pentesters, we've been forced to dial back the intensity of our password sprays so that they take hours or days to finish. And even when we find a valid credential, it sometimes doesn't lead anywhere thanks to security policies like MFA. Overall, it's a similar upward trend to what's happening in the phishing space, which is a whole different blog post. But I digress.

I suppose that, since we work in cybersecurity, we should be happy about these changes, since it means better security for organizations. After all, the goal of our industry is to make hackers' jobs harder. But since we're hackers and it's our job to hack stuff, it's hard to sit idly by and let our favorite pastime of password spraying go the way of the dodo.

What I'm trying to say is that we're frustrated. And when hackers are frustrated, they write code. So it is with great delight that we are open-sourcing some new tools, which are the product of our frustration, and will hopefully help to make password spraying fun again.

Introducing TREVORproxy and TREVORspray 2.0

When I set out to write these tools, the biggest problem I wanted to solve was Smart Lockout.

Smart Lockout tries to lock out attackers without locking out legitimate users. So basically, it's a fancy word for a lockout mechanism that considers the source IP address when locking an account. There are nuances -- like how Smart Lockout is often powered by machine learning, which makes it inconsistent and unpredictable -- but this is the gist of it.

Smart Lockout at Work

TREVORproxy

TREVORproxy IPv6 Subnet Proxy Diagram

TREVORproxy is a simple SOCKS proxy that helps avoid Smart Lockout by load-balancing your requests between multiple IP addresses. It accomplishes this with built-in Linux features -- no complex OpenVPN setups or strange firewall configurations. You can use this proxy with Burp Suite, your spraying tool of choice, or even your web browser.

There are two techniques that TREVORproxy can use to spread your requests across multiple IP adressess: an SSH Proxy and a Subnet Proxy.

SSH Proxy

The SSH Proxy is pretty straightforward. You give TREVORproxy some hosts that support SSH, and it sends your traffic through them, making sure to balance equally between all the hosts.

trevorproxy ssh root@1.2.3.4 root@4.3.2.1

TREVORproxy SSH Proxy Demo

Subnet Proxy

The subnet proxy can be a lot of fun. If you have access to a /64 IPv6 subnet (Linode is perfect for this), TREVORproxy will load-balance your requests across eighteen quintillion (18,446,744,073,709,551,616) unique source addresses.

Note that if you're using the subnet proxy in IPv6 mode, your target must also support IPv6.

sudo trevorproxy subnet -s dead:beef::0/64 -i eth0

TREVORproxy Subnet Proxy Demo

TREVORspray

TREVORspray is a modular password sprayer with built-in TREVORproxy support. It has the following features:

• Threads, lots of threads

• Multiple modules

  • msol (Office 365)

  • adfs (Active Directory Federation Services)

  • okta (Okta SSO)

  • anyconnect (Cisco VPN)

  • custom modules (easy to make!)

• Tells you the status of each account: if it exists, is locked, has MFA enabled, etc. (when supported)

• Automatic cancel/resume (remembers already-tried user/pass combos in ~/.trevorspray/tried_logins.txt)

• Automatic infinite reconnect/retry if a proxy goes down (or if you lose internet)

• Spoofs User-Agent and other signatures to look like legitimate auth traffic

• Comprehensive logging

• Optional --delay, --jitter, and --lockout-delay between requests to bypass lockout countermeasures

• IPv6 support

• O365 MFA bypass support (disable with --no-loot)

  • IMAP

  • SMTP

  • POP

  • EWS (Exchange Web Services) - Automatically retrieves GAL (Global Address Book)

  • EAS (Exchange ActiveSync)

  • EXO (Exchange Online PowerShell)

  • UM (Exchange Unified Messaging)

  • AutoDiscover - Automatically retrieves OAB (Offline Address Book)

  • Azure Portal Access

• Domain --recon to list MX/TXT records, O365 tenant info, federation configuration, autodiscover, etc.

TREVORspray Example - O365 Password Spray + MFA Bypass

Note that the eight O365 MFA bypass checks listed above are automatically executed when a valid cred is found.

# --delay         Sleep for this many seconds between requests
# --lockout-delay Sleep for this many additional seconds when a lockout is encountered
# --jitter        Add a random delay of up to this many seconds between requests

trevorspray -u emails.txt -p 'Spring2022!' --ssh root@1.2.3.4 root@4.3.2.1 --delay 30 --lockout-delay 30 --jitter 10

TREVORspray Password Spray + MFA Bypass Demo

TREVORspray Example - Domain Recon

trevorspray --recon evilcorp.com

TREVORspray Domain Recon Demo

Conclusion

By combining the IP-shuffling capability of TREVORproxy and TREVORspray's customizable --delay, --jitter, and --lockout-delay options, you can confuse Smart Lockout and boost the speed and effectiveness of your password sprays. For more examples and in-depth explanations of these concepts, please see the projects' READMEs.

• https://github.com/blacklanternsecurity/TREVORproxy

• https://github.com/blacklanternsecurity/TREVORspray

Happy spraying!

Share

Subscribe now

During a penetration test, Black Lantern Security (BLS) attempted to pivot from a domain-joined Linux system to a Windows environment. By utilizing FireEye’s SSSDKCMExtractor tool, BLS Operators were able to extract the payload for a Ticket-Granting Ticket from the SSSD Samba Database. Unfortunately, in its extracted state, the ticket could not be recognized by a Windows system due to the SSSDKCMExtractor tool lacking the ability to properly format the ticket, instead leaving it as an exercise for the reader. Since we always do our homework at BLS, and in spite of our love for tedious hex editing, we decided to automate the process. KCMTicketFormatter (KCMTicketFormatter on GitHub) was created to take the output from the SSSDKCMExtractor tool and parse the output into a properly formatted TGT in the form of a Kerberos Credential Cache (CCACHE file).

Overview of System Security Services Daemon (SSSD) on Linux

The following list briefly describes SSSD and how SSSD integrates with the Kerberos Cache Manager (KCM):

• SSSD is used to join a Linux system to an Active Directory domain

• SSSD utilizes the Kerberos Cache Manager to store Kerberos tickets from the domain in a local Samba database

• The tickets are stored encrypted with the decryption key stored in the same directory

• SSSD works with KCM to store and deploy Kerberos tickets and enable normal function within the domain

Brief Synopsis of SSSDKCMExtractor

FireEye created SSSDKCMExtractor to decrypt the KCM database used by SSSD and to extract Kerberos payloads. The tools utilizes the following workflow:

• With root privileges, an attacker navigates to the /var/lib/sss/secrets directory on a domain-joined Linux system

• The attacker exfiltrates the Samba Trivial Database (.tdb) and decryption key (.mkey)

• The attacker executes the SSSDKCMExtractor tool while providing both the database and decryption key

• JSON output is returned featuring the user, domain, and payload containing the unformatted TGT

Usage of KCMTicketFormatter

The following code snippet describes the normal usage of KCMTicketFormatter:

usage: KCMTicketFormatter.py [-h] -f FILE [-o OUTPUT] [-v]

Format SSSD Raw Kerberos Payloads into CCACHE files for use on Windows systems.

optional arguments:
  -h, --help            show this help message and exit
  -f FILE, --file FILE  <Required> Specify path to the file containing SSSD Raw Kerberos Payload
  -o OUTPUT, --output OUTPUT
                        Specify name of file to output the ccache. Defaults to ticket.ccache
  -v, --verbose         Show debugging messages

The following steps describe how to format using the KCMTicketFormatter:

1. Ensure you have a working Python3 environment

2. Copy the payload from SSSDKCMExtractor and store it in a text file, which will be provided as input.

3. Execute the tool providing the payload file as input

After running the tool, you can validate you have a properly formatted CCACHE file using the klist tool. Export the CCACHE file as KRB5CCNAME, and then run klist -A. The following screenshot demonstrates normal usage of the tool.

Share

Subscribe now

References

1. https://github.com/mandiant/SSSDKCMExtractor

2. https://docs.pagure.org/sssd.sssd/design_pages/kcm.html

3. https://github.com/blacklanternsecurity/KCMTicketFormatter