Anyone trying to understand continuous red teaming usually gets the same high-level explanation: it is ongoing, attacker-informed, and designed to uncover risk between formal assessments. Useful as that description is, it still leaves most people with the same question, which is what the service actually looks like when a team is working against a real environment day after day.

A Vector Command pod answers that question more clearly than a list of features ever could. Five dedicated operators work against a customer environment continuously, each bringing a different specialty, while the pod as a whole simulates the range, coordination, and persistence of a real adversary. Over time, that gives the customer far more than a periodic snapshot. It gives them a team that keeps learning the environment, keeps pressure on the attack surface, and keeps surfacing the kinds of changes that can turn into incidents if no one catches them quickly.

Because the environment keeps changing, the value of the model shows up in motion rather than in theory. New services appear, controls drift, patching gaps open, and fresh advisories create short windows of risk. Working continuously allows the pod to validate whether those changes matter while they are still actionable, which is what makes the service useful to teams that want more than another point-in-time assessment.

How the Red-Teaming pod works across a normal day

Every day begins with a 30-minute standup, where operators compare notes on what is in motion, what has already been found, and where handoff is needed. That routine may sound simple, but it is what turns five specialists into a coordinated attack team instead of a set of separate testing tracks.

While one operator follows a foothold on a build server, another may be preparing a social engineering campaign tied to a real business event. At the same time, someone else is watching the external footprint for fresh exposures, an emerging threat specialist is validating a new advisory against active customer technology, and the customer interface lead is already helping a security team understand what yesterday’s compromise means in practical terms. The customer is not seeing isolated tasks. They are seeing multiple attack paths, exposure checks, and validation efforts develop at once, with the work feeding into a single picture of risk.

Because the pod works across multiple attack paths at once, the value comes through in more than the sheer volume of activity. Familiarity builds over time, and that accumulated knowledge changes the quality of the work by grounding the findings in how the customer’s environment actually behaves.

What customers are actually getting tested

One of the clearest examples in the draft comes from the lead operator, who receives a callback from a beacon on a customer’s build server and begins exploring what that foothold could reach. Because the build server holds CI/CD credentials, the question is no longer whether the server can be compromised. The more important question is whether that compromise could extend into the deployment pipeline and what persistence would look like from there. For the customer, that kind of work shows how a technical foothold could become a business problem, which is much more useful than a simple proof that access was achieved.

The social engineering work gives a different kind of visibility. Domains are warmed, pretexts are built around real events, target lists are researched carefully, and emails are tested against spam controls before launch. That means the customer is not just testing whether an employee clicks a link. They are testing the full defensive chain, including email filtering, web controls, endpoint visibility, and SOC response.

Continuous external testing tends to make the value especially obvious. In the draft, the network and vulnerability operator identifies two RDP endpoints that are brand new to a customer’s environment and gets them in front of the customer the same day they appear. He also finds a Confluence instance several versions behind and confirms unauthenticated remote code execution. Those are the kinds of issues that often emerge between scheduled assessments and create risk precisely because no one expected them to be there.

When a fresh advisory lands against an exposed technology, the value of the service becomes even clearer. Broad awareness of an industry issue only goes so far. What changes the customer’s decision is knowing whether the exposure is exploitable in their own environment and what an attacker could reach from there.

Where the customer benefit becomes tangible

A service like this becomes much easier to understand when the output is viewed through the customer’s side of the experience. Early visibility into configuration drift, newly exposed services, lagging systems, and fresh exploit windows helps teams focus on changes that are real rather than theoretical. Validation tied to the customer’s own environment gives them a stronger basis for deciding what needs immediate attention. Attack-path testing shows how one weakness could become a wider compromise. Practical remediation guidance helps leadership and technical teams respond while the timing still matters.

Because the customer interface lead is also an operator, the translation from technical finding to leadership action is grounded in hands-on work rather than abstract summary. When a foothold, exposed service, or confirmed compromise needs to be explained, the conversation can move quickly from what happened to what the customer should prioritize next.

Over time, customers get more than a stream of findings because the pod is building familiarity with the environment as it works. That continuity gives the team a stronger basis for identifying which exposures deserve urgent attention, which attack paths are credible, and which changes are likely to matter most if an adversary finds them first.

Why this model gives customers more than a snapshot

Point-in-time testing still has value, but it will always be limited by the fact that the environment keeps moving after the engagement ends. A continuous pod keeps pace with that reality more effectively because it maintains pressure on the environment as it changes, rather than returning periodically to rediscover what is there.

Customers who want a clearer view of what continuous red teaming looks like in practice are really looking for evidence that the model changes the quality of what they get back. A dedicated pod does that by combining sustained offensive pressure, environment familiarity, rapid validation, and practical remediation guidance in a way that helps teams act on real risk while the timing still matters.

For organizations exploring how to test more continuously against the way attackers actually operate, Rapid7’s Continuous Red Team Service offers a closer look at how Vector Command helps uncover attack paths, validate exposures, and strengthen resilience over time.

Threat actors are integrating AI into their exploit chains, accelerating reconnaissance, automating vulnerability discovery, and scaling social engineering in ways that compress the timeline between initial access and impact. The barrier to sophisticated offensive operations is dropping fast.

Rapid7's Red Team is doing the same. Over the past year we formalized our approach into a structured multi-agent system that follows our penetration testing methodology end-to-end from scoping an engagement to validating findings to generating reports. We built it as a production system, not a proof of concept, and the process of designing and operating it taught us as much about defending against AI-enhanced attacks as it did about conducting them.

The system also proved its value as part of Anthropic's Project Glasswing initiative. Glasswing is a program that gives leading security companies early access to frontier cyber models before they reach wider availability, enabling security research that stays ahead of malicious adoption. We infused our red team architecture with Claude Mythos, applying it across penetration testing, vulnerability research, and red team operations. The combination of our formalized multi-agent architecture with a frontier-class model produced exceptional results in vulnerability analysis and exploit chain development. This validated both the architecture's design and the importance of getting these capabilities into defenders' hands first.

This post covers the architecture, the key design decisions, and what we learned along the way.

Why Rapid7's Red Team built a multi-agent system

Penetration testing is labor-intensive by nature as a significant portion of any engagement is spent on structured, repeatable work like enumerating attack surfaces, tracing data flows through source code, checking security headers, documenting findings in a consistent format. The actual judgement — deciding what to test next, assessing exploitability, understanding business impact — remains deeply human.

The opportunity was straightforward: offload the mechanical work to AI agents while maintaining human insight at decision points where it matters most. Those decision points are where engagements succeed or fail: scoping what's in and out of bounds, choosing which attack paths to pursue based on business context, assessing whether a vulnerability is genuinely exploitable in a given environment, deciding when a finding is significant enough to escalate, and interpreting results in ways that translate to actionable risks. None of that is mechanical, it requires experience, judgement, and context that models routinely get wrong. And as an internal security team, we don't just report vulnerabilities, we're accountable for coverage. If something ships with an exploitable flaw we missed, that's on us. The bar for confidence is high, and that's why humans stay in the loop at every point that matters.

We also had a secondary motivation. Building a system that follows a structured offensive methodology gives us direct architectural insight into how AI agents behave in adversarial contexts including the capabilities, the limitations, and the failure modes. That understanding now informs how we assess and secure Rapid7's own AI-powered products.

The architecture: Orchestration, not autonomy

The system isn't a single monolithic agent but a team of specialist agents coordinated by an orchestrator that mirrors how human red teams operate. The orchestrator doesn't test anything. It assesses the current state of the engagement, determines what needs to happen next, routes work to the appropriate specialist, and processes the results. Specialist agents handle enumeration, code review, dynamic testing, and reporting.Each with defined inputs, outputs, and constraints.

The architectural choice to use supervisor-style orchestration rather than a monolithic agent separates routing decisions from execution. This makes the system more predictable, auditable, and controllable,properties that matter when the agent is operating in sensitive environments.

The key design decision that made this work was methodological, not technical. We reverse-engineered the agent's architecture directly from our team's daily task lists. The to-do items our testers tracked during real engagements became the specification: which tasks repeat, in what sequence, where decisions branch, and what triggers a return to an earlier phase. The methodology we'd built over years of engagements became the orchestration logic.

Scope decomposition: Giving every target full attention

One of the earliest lessons we learned was that throwing an entire engagement scope at an AI agent produces shallow, scattered results. LLMs have finite context windows and finite attention. A complex application with dozens of endpoints, multiple authentication flows, and layered business logic overwhelms a single-pass analysis and important details get lost in the noise.

The solution was deliberate scope decomposition. Before the agent begins any technical work, the engagement scope is broken into discrete, manageable chunks.  The scope includes individual components, feature areas, or functional boundaries. Each chunk flows through the full architecture independently: enumeration, code review, dynamic testing, and reporting. The orchestrator tracks which chunks are complete, which are in progress, and which are queued.

This achieves two things. First, it ensures depth over breadth as each component receives the agent's full analytical attention rather than competing for context space with everything else. Second, it creates natural parallelization opportunities and clear progress tracking. A tester can see exactly which areas have been thoroughly assessed and which remain.

The principal maps directly to how experienced pentesters already work by breaking the target into logical units, going deep on each one, then synthesizing across them. Making the principal explicit and enforceable in the orchestration logic was the design contribution.

Feedback loops: Why linear pipelines fail

Real penetration tests don't follow a straight line. Code review reveals new endpoints that need enumeration. Dynamic testing uncovers an attack surface that wasn't visible from source alone. Validated findings sometimes expose entirely new subsystems.

The agent handles this natively. The orchestrator maintains a routing table with progression gates — criteria that must be met before advancing — and feedback triggers that route the engagement backward when new actionable data emerges. This creates a directed graph with re-entry points, not a waterfall.

Guardrails: Maintaining safety in a malicious context

Building an AI agent that can hack is relatively straightforward but building one that operates safely within defined boundaries is a challenge. So it was an area where we invested significant design effort.

The system uses a tiered safety model:

• Scope enforcement — every action is validated against the engagement's authorized scope before execution. Out-of-scope discoveries are reported but never probed.

• Action classification — before execution, every proposed dynamic test is categorized as non-destructive, destructive, or ambiguous. Destructive and ambiguous actions require human approval.

• Human-in-the-loop by default — in our current deployment, a tester reviews and approves every dynamic test. The agent proposes; the human decides.

The system is designed with a path toward semi-automated operation where low-risk, read-only actions execute autonomously while state-modifying operations still require human approval. The decision about where to sit on that spectrum is context-dependent. Internal labs can tolerate more autonomy while client engagements demand more oversight.

Token efficiency: Making AI practical

AI agents are expensive to run at scale. Every enumeration step, every code block analyzed, every HTTP request reasoned about will consume tokens. It is a practical concern that shaped several design decisions. 

The approach was to identify mechanical tasks that don't require LLM reasoning and replace them with deterministic scripts and MCP servers. DNS lookups, header checks, input field probing, and certificate enumeration produce structured data that the agent consumes, but the data collection itself doesn't need intelligence. This reduced token consumption dramatically for enumeration-heavy phases while letting the AI focus its reasoning budget on analysis, correlation, and judgement.

Not every step in an AI workflow needs AI. Knowing where to draw that line was the difference between a demo and a production system for us.

Securing AI from the inside out

There's a dimension to this work that goes beyond offensive operations. Rapid7 builds AI-powered products. As the internal security team, we're responsible for securing those systems and building a complex multi-agent architecture gave us direct insight into where the weak points live.

Designing the orchestrated system taught us exactly how prompt injection can propagate between agents, where trust boundaries blur when one agent's output becomes another's input, how guardrails can be bypassed through indirect manipulation, and what happens when scope enforcement relies on instruction-following rather than programmatic controls.

We now test Rapid7's AI features with the same architectural intuition we developed building this system. We know where to look because we've built the same patterns and felt where they flex. When we assess an AI system's safety, we're thinking like the orchestrator — looking for the routing decision that can be subverted, the progression gate that can be skipped, the feedback loop that can be poisoned.

Building offensive AI made us materially better at defending the AI we ship to customers.

What we learned operating the multi-agent system

A few observations from our team:

Methodology is the differentiator

The LLMs are commodities. The orchestration patterns are emerging in open literature. What makes an AI agent effective at penetration testing is the methodology it follows and that's built from years of institutional knowledge. Formalizing our methodology into explicit, machine-executable logic was the most valuable part of the project.

Building AI builds intuition for securing AI

The architectural understanding we developed — trust boundaries, prompt propagation, scope enforcement failures — translates directly into more effective security assessments of production AI systems. This was an unexpected but significant return on the investment.

The automation spectrum is context dependent

Full autonomy isn't a goal; it's one end of a spectrum. The right level of automation depends on the context.Internal labs, client engagements, and product integrations each have different risk profiles. Designing for the spectrum rather than a fixed endpoint kept the system flexible.

What's next for Rapid7 Red Teaming in the age of AI

We're continuing to develop the system, refining the methodology mapping, expanding specialist capabilities, and exploring where purpose-built models could replace general-purpose LLM calls for specific tasks (such as severity classification, report writing, payload selection). We're also using what we learn from operating this system to inform how Rapid7 detects and responds to AI-enhanced offensive activity in the wild.

You can learn more about Vector Command, Rapid7's continuous red-teaming solution, here.

Red teaming has always played a role in testing defenses, but in 2026 its role is changing. Security teams are no longer asking whether an attacker can get in. That question has already been answered. The real challenge is whether teams can detect, validate, and respond before an incident escalates.

That shift sits at the center of this year’s Rapid7 Global Cybersecurity Summit, taking place on May 12-13. As part of the Continuous Threat Defense pillar, the summit will explore red teaming not as a standalone exercise, but as a core input into how modern security operations function day to day.

From validation to continuous feedback

In sessions like Using Red Teaming to Power Preemptive MDR, the focus moves away from point-in-time testing and toward becoming part of a continuous feedback loop. Detection logic is tested against real attacker techniques and gaps are exposed before they become incidents. Response workflows are refined in conditions that reflect how attacks actually unfold, rather than how they are expected to behave.

This represents a clear shift from traditional engagements. Instead of producing a static report, red teaming feeds directly into detection engineering and MDR operations. Many teams still rely on assumptions about coverage, but those assumptions often break down under pressure. Continuous validation helps close that gap.

Aligning red teaming with how attacks really happen

Modern attacks rarely follow a clean path. They move across identity, cloud, and endpoint, taking advantage of timing, visibility gaps, and delayed decisions. Red teaming has to reflect that reality.

At the summit, the conversation connects adversary behavior with how detection and response teams operate in practice. This includes how signals are correlated across environments, how escalation decisions are made, and where teams lose time during an investigation. The goal is not to simulate attacks for the sake of it, but to understand how those attacks would be detected, prioritized, and contained in a real environment.

Why red teaming matters now

The move toward preemptive security operations depends on confidence. Teams need to know that what they have built will hold up when it matters. Red teaming supports that by grounding security programs in evidence. It shows what works, highlights what does not, and gives teams an opportunity to improve before a live incident forces change.

This becomes even more important as organizations adopt MDR models, integrate AI into workflows, and operate across increasingly complex environments. Without continuous validation, complexity creates blind spots that are difficult to see until it is too late.

Rapid7's Cybersecurity Summit: A preview of what’s to come

Red teaming is one part of a broader shift happening across the summit. Sessions across detection, response, AI, and exposure management all point in the same direction: Security operations must move earlier in the attack lifecycle, reduce noise, improve prioritization, and support faster decisions with better context.

More sessions and speakers will be announced in the coming weeks, building out how this shift is being applied in practice. If you are responsible for detection, response, or validation of your security program, this is a conversation worth being part of.

Join us May 12–13 and see how teams are using red teaming to strengthen modern security operations.

Register now.

If it’s online, it’s a target

Web applications are no longer just business enablers, they’re often the front door to an organization. They can often generate revenue, enforce identity, connect systems and hold customer and business data.

“75% of successful Vector Command breaches were conducted through web apps.” –Principal Security Consultant, Vector Command Team at Rapid7

From SaaS platforms and identity providers to customer portals and internal tools, attackers increasingly rely on web applications as their initial access point. In fact, application-driven attacks account for a significant percentage of real-world breaches. But testing web applications for real risk isn’t the same as scanning for bugs; that’s where Vector Command (Rapid7’s continuous managed red team service) comes in.

How Vector Command approaches web applications

Vector Command evaluates web applications the same way real attackers do, by asking a single question: Can this application be used to meaningfully compromise the organization?

Rather than attempting to enumerate every possible vulnerability, Vector Command focuses on exploitation paths that lead to real outcomes, such as:

• Account takeover

• Session hijacking

• Abuse of SaaS trust relationships

• Access to internal systems through vulnerabilities, such as malicious file uploads, injection issues, or misconfigurations in common web frameworks

• Lateral movement across applications

• Exfiltration of source code, if found during a breach

Testing begins without authentication against externally facing applications, the external attack surface, or to put it another way, what a potential threat actor can see. If legitimate paths exist – self-registration, broken authentication and authorization controls, misconfigurations exposing unintended application functionality, or overall poor site hygiene leaking information that needs further research – those paths are pursued as part of a broader attack chain.

The result isn’t a long list of low-risk findings, but rather a clear picture of what actually works.

What Vector Command does not do

Vector Command is intentionally not a replacement for a full web application penetration test, although Rapid7 does offer this service.

It does not:

• Guarantee full application coverage.

• Perform DAST or SAST scanning.

• Enumerate non-exploitable low-severity or theoretical vulnerabilities.

• Review source code unless it’s obtained during an attack.

If your goal is to understand every potential flaw in an application, a dedicated web app penetration test is the right approach. However if your goal is to understand whether your sprawling stack of externally facing applications can be used to break into your organization, Vector Command is designed for that purpose.

A real-world example: when the ticketing system becomes the attack path

In one recent Vector Command engagement, attackers didn’t exploit a zero-day or complex vulnerability.

Instead, they targeted an externally accessible and very popular, SaaS ticketing portal used by IT. Through a well-placed social engineering attempt, they gained access to an internal support workflow. Any organization could register for the customer’s SaaS deployment, which was used to host IT documentation and their ticketing system.

The Vector Command team submitted a ticket to the customer’s IT team, seeking assistance to help fix an application installation issue. A SharePoint URL was provided to IT to view the software documentation, however… This SharePoint site was a proxy phishing portal, created by our Vector Command experts, designed to capture Office365 login sessions and the user’s MFA prompts. 

Hook, line and cookie: the result?

The unsuspecting IT help-desk employee had been phished and was convinced to run the Rapid7 payload, giving our Vector Command team access. The engagement demonstrated how easily trust relationships could be abused. From there, a malicious link led to session capture within a trusted collaboration platform.

• Account takeover

• Session theft

• Lateral movement using legitimate tools

• Access granted without triggering traditional defenses

No single “critical bug” caused the breach. It was the interaction between applications, identity, and trust that made it possible. That’s exactly the kind of risk Vector Command is designed to uncover and each one of our red team members has a particular speciality, when used together, they are formidable. 

Vector Command and web app pentesting: better together

Vector Command and web application penetration testing serve different, but complementary purposes. Web app pentests help teams build more secure applications, while Vector Command helps teams understand how those applications affect real-world security exposure.

One improves code; the other tests assumptions.

A final thought

Vector Command doesn’t try to answer “What could be wrong?”, answering instead, “What would actually succeed?”

Modern breaches rarely hinge on a single critical bug. They succeed because trusted systems interact in ways no one has validated. Vector Command tests those assumptions, continuously.

What is purple teaming?

Purple teaming is often described as the collaboration between red teams and blue teams. That definition is accurate, but incomplete. At its core, purple teaming is about exposure validation: deliberately testing whether the threats you believe you can detect and contain are actually visible in your environment.

Red teams simulate attacker behavior. Blue teams defend and respond. Purple teaming ensures those two functions operate in lockstep, sharing telemetry, assumptions, and findings to strengthen detection coverage and close control gaps.

⠀

Unlike traditional penetration testing, which is often point-in-time and compliance-driven, purple teaming is iterative. It is designed to measure, refine, and retest. The goal is not to “win” an exercise. The goal is to improve the organization’s ability to detect, investigate, and contain real attack paths.

Many security programs look mature on paper. Controls are deployed. EDR is in place. Logging is centralized. Dashboards show green indicators. Yet when realistic attacker behavior is exercised inside the environment, gaps often surface quickly. Telemetry may be incomplete. Detection rules may exist but lack tuning. Alerts may trigger without clear ownership or response workflow.

Purple teaming exists to close the gap between perceived protection and actual defensive capability. It replaces assumption with validation.

What purple teaming actually means in 2026

Purple teaming is often described as collaboration between red and blue teams. In practice, it is structured exposure validation conducted in an open-book format.

Offensive operators simulate real-world attack scenarios in coordination with defensive teams. The security operations or incident response team is aware of the exercise from the outset. Together, they define the threat scenarios to test specific response playbooks and detection coverage. The objective is not to surprise the SOC. It is to measure whether detection, telemetry, and response workflows operate as intended and to refine them in real time.

If defensive teams cannot follow a tactic or lack necessary telemetry, activities pause. Gaps are identified and corrected collaboratively. Purple teaming strengthens detection engineering, investigative workflows, and cross-team communication without the pressure of a live incident.

Beyond scorecards: Real-world context matters

Some organizations equate purple teaming with automated breach and attack simulation tools. A sequence of techniques is executed against an assumed compromised host, and a report shows which detection rules are fired. Those metrics can provide visibility into rule coverage. They do not show whether an attacker can exploit real exposures in the environment.

A more contextual approach begins with tailored threat scenarios based on the organization’s actual risk profile. Operators assess real vulnerabilities and misconfigurations rather than firing generic techniques. The focus is not simply to validate rules but to determine whether exploitable exposures exist that blend into legitimate functionality.

Attackers often operate within intended system behavior. They abuse excessive permissions, leverage trust relationships, and exploit architectural weaknesses that were never designed to generate alerts. In these cases, writing a new detection rule does not address the underlying issue. The exposure stems from posture and configuration.

Lateral movement is then executed using access that genuinely exists in the environment. The question becomes whether the organization can observe attacker progression through normal administrative pathways and whether defensive visibility extends beyond initial compromise.

Persistence techniques are established in ways consistent with how an adversary would maintain access in that specific configuration. Detection is measured continuously.

The engagement concludes with a collaborative hunt exercise. The breach lifecycle is recreated without triggering alerts, followed by the intentional generation of a single alert. Teams then work from that signal to reconstruct the attack chain. This phase often reveals how tooling, telemetry, and processes function under structured scrutiny.

Where red teaming fits: Vector Command

It is important to distinguish purple teaming from red teaming.

In a true red team engagement, the SOC and incident response teams are not aware of the breach. Operators attempt to remain undetected for as long as possible. The goal is to emulate a real adversary and test how the organization responds under live conditions.

This is how Vector Command operates. It functions as a continuous red team service, attempting to breach client environments and achieve defined objectives while avoiding detection. If detection occurs during a red team engagement, the SOC response is observed as it would be during a genuine incident. This tests process maturity, investigative speed, and real-world visibility. If and when a breach is detected, the engagement can transition into a collaborative purple team phase. At that point, operators work openly with the SOC to walk through the attack path, identify detection gaps, and refine telemetry and response workflows.

Red teaming measures whether defenses hold up under pressure. Purple teaming refines those defenses collaboratively.

The two approaches are complementary. A red team engagement may identify a successful breach path. After that breach concludes, organizations can transition into purple team activities. Offensive findings are shared openly with defensive teams, and gaps are tuned and remediated. When paired with managed detection and response services, this refinement can occur in coordination with both the customer’s security team and the managed SOC.

⠀

In this model, red teaming exposes real weaknesses. Purple teaming strengthens defenses against them.

What effective purple teaming delivers

Effective purple teaming produces operational improvement rather than a static report.

• Detection logic improves because it is tuned against real attacker behavior

• Telemetry gaps are identified and corrected

• Ownership of investigation workflows becomes clear

• Remediation is prioritized against validated attack paths rather than theoretical risk

For senior security leaders, the value is measurable control effectiveness. Purple teaming provides evidence that investments in tools and people translate into improved resilience. It also builds alignment between offensive and defensive teams. That alignment accelerates improvement and reduces friction across security, IT, and operations.

In an environment where attack techniques evolve and exposure surfaces expand, purple teaming offers something concrete: validated insight into how well the organization can detect, investigate, and contain adversary behavior.

Resilience should not be assumed. It should be tested.

Matthew Toussain// Join Matt Toussain as he talks about Mailsniper, a tool written by our very own Beau Bullock. Wouldn’t you like to START your pen tests knowing every username […]

The post WEBCAST: Testing G Suites with MailSniper appeared first on Black Hills Information Security, Inc..

John Strand // John is starting a new series of webcasts called Attack Tactics. This first part  is a step-by-step walk-through of an attack BHIS launched against a customer, with […]

The post WEBCAST: Attack Tactics Part 1 appeared first on Black Hills Information Security, Inc..

Lee Kagan* // Deploying an offensive infrastructure for red teams and penetration tests can be repetitive and complicated. One of my roles on our team is to build-out and maintain […]

The post How to Build a C2 Infrastructure with Digital Ocean – Part 1 appeared first on Black Hills Information Security, Inc..

John Strand // It’s odd, we try to push security forward through standards like NIST, the Critical Controls, and PCI, but most organizations strive to meet the bare minimum required […]

The post WEBCAST: Insurance & Ransomeware appeared first on Black Hills Information Security, Inc..

John Strand // There have been a few conversations at conferences and meet-ups over the past year or so about the validity of penetration testing. There are many things on […]

The post Pink Teaming: The Dilution of Pentesting appeared first on Black Hills Information Security, Inc..

Beau Bullock // TL;DR MailSniper is a penetration testing tool for searching through email in a Microsoft Exchange environment for specific terms (passwords, insider intel, network architecture information, etc.). It […]

The post Introducing MailSniper: A Tool For Searching Every User’s Email for Sensitive Data appeared first on Black Hills Information Security, Inc..

Beau Bullock // TL;DR I compared three single-board computers (SBC) against each other with a specific goal of finding which one would serve best as a “penetration testing dropbox”, and […]

The post How to Build Your Own Penetration Testing Drop Box appeared first on Black Hills Information Security, Inc..

Brian B. King // Red Teaming is one of those terms popping up all over the place lately, and it seems to mean different things to different people. Is it […]

The post Book Review: “Red Team – How to Succeed by Thinking Like the Enemy” appeared first on Black Hills Information Security, Inc..

Derek Banks // Yes, I date myself with reference in the title of this blog post.  I can be lame like that. A fair amount of my time at $last_gig […]

The post You Down With APP? (Yeah You Know Me) appeared first on Black Hills Information Security, Inc..