INSIGHTS | September 15, 2026

Cybersecurity Testing Methodologies Compared

By IOActive

Cyber defenses blocking attacks from organizations and infrastructure.

The global average cost of a data breach reached $4.44 million in 2025, the first decline in five years. IBM attributes this largely to faster detection and containment, driven by AI-assisted security tooling and more mature incident response programs.¹ That decline is meaningful, but it does not erase the underlying question that keeps security leaders up at night: if an attacker came for your organization today, would your security program catch it in time?

For buyers comparing cybersecurity testing methodologies, the answer depends entirely on whether the testing approach they have chosen is aligned with the questions they most need to answer. This article compares cybersecurity testing methodologies so security leaders can build testing programs that reflect their risk profile.

Cybersecurity Testing Methodologies Compared

Methodology	Primary Question Answered	Scope	Engagement Duration	Stakeholder Awareness	Best Suited For
Vulnerability Assessment	What weaknesses exist across our systems?	Broad, automated	Hours to days	High	Baseline hygiene, compliance inventory
Penetration Testing	Which weaknesses are actually exploitable?	Targeted, manual	Days to weeks	High	Targeted risk reduction, audit requirements
Red Team Exercise	How would a real attack on our organization play out?	Full-scope, adversarial	Weeks to months	Low (exec only)	Mature programs; resilience validation
Purple Team Exercise	How can offensive findings improve our detection?	Collaborative, controlled	Days to weeks	High	Detection engineering; SOC capability building
Adversary Simulation	Can a specific known threat actor breach our defenses?	Threat-actor specific	Weeks	Low to medium	High-risk sectors; critical asset protection
Security Validation	Are our controls still working the way we think?	Continuous, platform-driven	Ongoing	High	Control drift detection; continuous assurance
Full-Stack Security Assessment	How does our entire attack surface connect?	Comprehensive: hardware, firmware, software, AI	Weeks to months	Medium	Complex environments; hardware and embedded systems

Choosing the Right Cybersecurity Testing Methodology

The decision framework below matches organizational characteristics to the testing methodology most likely to answer the most pressing security questions. In practice, mature security programs combine multiple methodologies: vulnerability assessments for continuous hygiene, penetration testing for targeted risk validation, Red Team or adversary simulation for resilience measurement, and full-stack assessment where the attack surface extends into hardware and embedded systems.

If Your Organization…	Start With	Then Add
Has no formal testing program yet	Vulnerability Assessment	Penetration Testing
Needs to meet a compliance requirement	Penetration Testing	Vulnerability Assessment
Has a functioning security team and wants to test detection	Red Team Exercise	Purple Team Exercise
Wants to improve SOC detection engineering	Purple Team Exercise	Adversary Simulation
Operates in critical infrastructure or OT/ICS environments	Full-Stack Assessment	Red Team Exercise
Has hardware, embedded systems, or AI in production	Full-Stack Assessment	Penetration Testing (firmware/AI)
Needs to test against a specific known threat actor	Adversary Simulation	Red Team Exercise
Needs continuous visibility into control effectiveness	Security Validation	Penetration Testing (periodic)
Is building a multi-year security testing roadmap	Penetration Testing	Red Team, then Adversary Simulation

Vulnerability Assessments

A vulnerability assessment is the foundational layer of any security testing program. Automated scanning tools cross-reference an organization’s systems and software against public databases of known vulnerabilities, producing a ranked list of unaddressed weaknesses. The output is fast and broad: an organization can scan thousands of assets within hours.

What a Vulnerability Assessment Actually Measures

The key limitation is that a vulnerability assessment identifies weaknesses without confirming whether they are exploitable in your specific environment. A critical-severity CVE may be present on a system protected by compensating controls, making its real-world impact far lower than its CVSS score implies. Conversely, a medium-severity finding on a system with elevated privileges may represent a far more serious risk than any automated tool will flag.

When a Vulnerability Assessment Is the Right Choice

Vulnerability assessments are most valuable as a continuous hygiene practice and as a pre-engagement baseline before any manual testing. Organizations pursuing compliance frameworks, including SOC 2, ISO 27001, PCI-DSS, and FedRAMP, typically require documented vulnerability assessments at defined intervals. They are also useful after infrastructure changes for quickly identifying new exposures.

Where It Falls Short

A vulnerability assessment cannot confirm whether your security controls would stop a determined attacker. It produces a list of targets, not a realistic picture of how those targets could be chained into a damaging attack path. Organizations that rely on vulnerability assessments as their primary testing methodology have identified their weaknesses without knowing which ones matter most under adversarial conditions.

Attribute	Vulnerability Assessment
Primary output	Ranked list of CVEs and misconfigurations
Human expertise required	Low to medium
Detection and response testing	None
Compliance value	High
Organizational maturity required	Low
IOActive equivalent	Pre-assessment scanning embedded in full-scope engagements

Penetration Testing: Proving Exploitability

Penetration testing takes vulnerability assessment to the next level by adding the expert human element. A qualified ethical hacker is authorized to discover and exploit vulnerabilities within a defined scope, demonstrating how a real adversary might compromise systems, access sensitive data, or disrupt operations. The objective is not simply to find weaknesses but to confirm which ones carry genuine damage potential.

What Penetration Testing Measures

IOActive’s penetration testing methodology includes vulnerability scanning, brute-force testing, web application exploitation, and social engineering within the stated scope. Because exploitation is included, results show which vulnerabilities pose the most immediate risk, helping security teams prioritize remediation where it matters most. Unlike vulnerability assessments, penetration testing distinguishes confirmed risk from theoretical exposure.

When Penetration Testing Is the Right Choice

Penetration testing is the right methodology when your organization needs to address specific known risk areas, validate controls before or after a major deployment, satisfy a compliance requirement, or build an internal case for remediation investment. It is also the appropriate entry point for organizations that want to move beyond automated scanning but are not yet mature enough to benefit fully from Red Team exercises.

Where It Falls Short

Because internal stakeholders are generally aware that the test is occurring, penetration testing provides limited insight into detection and response capabilities. Security operations teams may respond differently during a known engagement than during an unannounced real-world attack. Penetration testing is also constrained by its defined scope, meaning attack paths that cross into hardware, embedded firmware, AI pipelines, or physical access controls are typically not evaluated unless the engagement is scoped to include them.

Attribute	Penetration Testing
Primary output	Exploitability-confirmed vulnerability list with remediation guidance
Human expertise required	High
Detection and response testing	Limited (scope-dependent)
Compliance value	Very high
Organizational maturity required	Low to medium
IOActive equivalent	Application, network, hardware, AI, and embedded systems penetration testing

Red Teaming: Testing Resilience, Not Just Vulnerabilities

A Red Team exercise is a full-scope adversarial simulation in which a group of expert ethical hackers emulates a real-world threat actor, attempting to compromise the organization’s most critical assets without detection. Unlike penetration testing, the Red Team operates covertly, its existence known only to select executives. It is not constrained by a predefined list of targets or a scoped attack surface.

What Red Team Exercises Measure

IOActive’s Red Team exercises use threat intelligence and threat modeling to create representative attack scenarios aligned to the organization’s industry, assets, and actual adversary landscape. The exercise tests not just whether vulnerabilities exist but whether your people, processes, and technologies work together to prevent, detect, and respond to a sophisticated, persistent attacker. The output is a realistic resilience scorecard, not a vulnerability inventory.

When Red Teaming Is the Right Choice

Red Team exercises deliver their highest value for organizations with mature security programs: those that already have a functioning vulnerability management process, a dedicated security operations function, and defined incident response procedures. Without this foundation, a Red Team exercise will surface the same basic issues that a penetration test would have identified at lower cost and in less time.

Where It Falls Short

Red Team exercises require significant time and investment, spanning weeks to months. They are also less effective at producing a comprehensive vulnerability inventory: the Red Team’s objective is adversarial impact, not exhaustive coverage. Organizations in earlier stages of security maturity often extract more value from a penetration test before committing to a full Red Team engagement.

Attribute	Red Team Exercise
Primary output	Attack narrative, detection gap analysis, resilience scorecard
Human expertise required	Very high
Detection and response testing	Comprehensive
Compliance value	Medium
Organizational maturity required	High
IOActive equivalent	Full-scope Red Team with threat intelligence, physical access, and social engineering

Purple Teaming: Turning Offense Into Defensive Improvement

Purple Teaming combines the offensive capabilities of a Red Team with the defensive knowledge of the organization’s security operations function in a structured, collaborative exercise. Rather than attacking covertly, the exercise operates transparently: the Red Team executes techniques, the Blue Team observes its own detection capability in real time, and both sides work together to improve visibility and response. The goal is to build detection capability directly from the findings.

What Purple Team Exercises Measure

Purple Team exercises answer the question: “Are our detection controls catching the techniques attackers are actually using against organizations like ours?” The output includes confirmed detections, confirmed gaps, SIEM tuning recommendations, alerting threshold adjustments, and an empirical measurement of SOC capability against specific attack techniques mapped to MITRE ATT&CK.

When Purple Teaming Is the Right Choice

Purple Teaming is the right methodology when your organization wants to improve its security operations capability, validate that new security tooling is correctly configured, or build internal detection engineering skills. It is particularly valuable as a structured follow-up after a Red Team engagement surfaces detection gaps, or as a more cost-efficient approach to testing specific threat scenarios without conducting a full covert Red Team exercise.

Where It Falls Short

Because the exercise is collaborative and transparent, it cannot test true detection capability under realistic conditions where defenders don’t know an attack is in progress. It also requires a sufficiently capable internal security team to be meaningful: organizations without a functioning SOC or detection engineering practice will find Purple Team exercises difficult to execute and difficult to learn from.

Attribute	Purple Team Exercise
Primary output	Detection gap analysis, control tuning recommendations, SOC capability benchmarks
Human expertise required	High (both offensive and defensive)
Detection and response testing	Focused and empirical
Compliance value	Medium
Organizational maturity required	Medium to high
IOActive equivalent	Collaborative red/blue exercises aligned to MITRE ATT&CK

Adversary Simulation: Testing Against the Threats That Target You Specifically

Adversary simulation is a targeted form of Red Teaming in which the testing team emulates the specific tactics, techniques, and procedures (TTPs) of a known threat actor relevant to the organization’s industry or threat landscape. Rather than operating as a generic attacker, the simulation team behaves as a specific threat group would: using the same initial access methods, persistence mechanisms, lateral movement techniques, and exfiltration approaches documented in real-world intelligence reporting.

What Adversary Simulation Measures

Adversary simulation answers the question: “Could the threat actors most likely to target our industry actually succeed against our defenses?” It is grounded in threat intelligence rather than generic attacker methodology, which makes the findings more directly actionable for security operations teams building detections and defenses against specific actor profiles.

When Adversary Simulation Is the Right Choice

Adversary simulation is the right methodology for organizations in high-risk sectors, including financial services, critical infrastructure, government, healthcare, and defense, where the threat actor landscape is well-defined, and the consequences of a successful targeted attack are severe. It is also appropriate for organizations that have completed multiple Red Team exercises and want to test against increasingly specific and sophisticated threat profiles.

Where It Falls Short

Adversary simulation requires high-quality, current threat intelligence to be effective. Simulations built on outdated or generic actor profiles may not reflect the organization’s actual threat landscape. Organizations operating in sectors where actor TTPs evolve rapidly need to ensure simulation frameworks are continuously refreshed to remain accurate.

Attribute	Adversary Simulation
Primary output	Threat-actor-specific attack narrative and detection coverage assessment
Human expertise required	Very high
Detection and response testing	Comprehensive and threat-specific
Compliance value	Medium to high (sector-specific frameworks)
Organizational maturity required	High
IOActive equivalent	Threat-intelligence-led emulation aligned to MITRE ATLAS and ATT&CK

Security Validation: Continuous Testing for Mature Programs

Security validation, often delivered through breach and attack simulation (BAS) platforms, is a continuous or high-frequency testing approach that regularly executes simulated attack techniques against an organization’s controls to confirm they are functioning correctly. Unlike periodic point-in-time assessments, security validation creates an ongoing signal about control effectiveness as the environment changes.

What Security Validation Measures

Security validation answers the question: “Are the controls we deployed still working the way we think they are?” Environments change constantly: new systems are added, configurations drift, patches create unexpected side effects, and threat actor techniques evolve. A control that was effective six months ago may have degraded without anyone noticing. Security validation surfaces that drift before an attacker exploits it.

When Security Validation Is the Right Choice

Security validation is the right methodology for organizations with mature, complex environments where control drift is a real operational risk, particularly those with large distributed infrastructure. It is most valuable as a complement to periodic manual testing, not as a replacement. Point-in-time penetration tests and Red Team exercises provide the depth and creative adversarial thinking that automated platforms cannot replicate; continuous validation fills the coverage gap between those engagements.

Where It Falls Short

Security validation platforms execute known, documented attack techniques. They cannot discover novel attack paths, evaluate physical access controls, test the human element, or assess the creative chained attack scenarios that skilled adversarial testers consistently identify. Treating security validation as a substitute for manual testing creates a significant and predictable coverage gap.

Attribute	Security Validation
Primary output	Control effectiveness dashboard, drift alerts, trend benchmarks
Human expertise required	Low to medium
Detection and response testing	Continuous, technique-specific
Compliance value	High for continuous monitoring requirements
Organizational maturity required	Medium to high
IOActive equivalent	Baseline reference tool within broader assessment programs

Full-Stack Security Assessment: When Surface-Level Testing Isn’t Enough

Most cybersecurity testing engagements operate within a defined layer: application security, network infrastructure, or cloud environments. Full-stack security assessment examines how vulnerabilities and attack paths span multiple layers simultaneously, including hardware, firmware, embedded systems, AI and machine learning pipelines, physical infrastructure, and enterprise applications. It is the methodology appropriate for organizations whose risk surface extends beyond the software-defined perimeter.

Why the Full Stack Matters

Modern enterprise environments are not purely software-defined. Connected devices, industrial control systems, SATCOM terminals, autonomous vehicles, medical equipment, AI-enabled workflows, and physical access infrastructure all create attack paths that single-layer testing does not examine. When an attacker who compromises a network edge device can pivot into an operational technology environment, or when a manipulated AI model can influence production decisions, a network-only penetration test leaves the most consequential attack paths untested.

IOActive’s Full-Stack Advantage

This is where IOActive’s approach diverges from most security testing providers. With physical hardware labs in Seattle, Madrid, and Cheltenham, and 25-plus years of research spanning cloud stacks, connected vehicles, integrated circuits, SATCOM terminals, embedded firmware, and AI systems, IOActive provides full-stack assessments that few firms globally can replicate.² The AMD Sinkclose vulnerability, the Tesla Model Y NFC relay attack, the Raspberry Pi RP2350 challenge win, and the Reviver digital license plate jailbreak are examples of research that reflects this depth across hardware, firmware, and software layers simultaneously.²

When Full-Stack Assessment Is the Right Choice

Full-stack assessment is the right methodology for organizations in manufacturing, automotive, aerospace, critical infrastructure, healthcare, and financial services, where the attack surface includes physical systems, proprietary hardware, embedded software, and operational technology alongside enterprise infrastructure. It is also appropriate for any organization whose AI-enabled applications interact with production systems, financial workflows, or sensitive data at scale.

Attribute	Full-Stack Security Assessment
Primary output	Cross-layer attack path analysis, hardware and firmware findings, remediation roadmap
Human expertise required	Exceptional, cross-disciplinary
Detection and response testing	Comprehensive across all tested layers
Compliance value	High for regulated industries
Organizational maturity required	Medium to very high
IOActive equivalent	Hardware, firmware, AI, embedded, network, application, and physical testing

With 25-plus years of independent security research and physical testing labs on three continents, IOActive brings the adversarial expertise and full-stack depth that complex security programs demand.

Schedule a Security Assessment Consultation with IOActive

Frequently Asked Questions

How often should organizations conduct penetration tests?

Most security frameworks recommend annual penetration testing at a minimum. Organizations with active development pipelines, frequent infrastructure changes, or strict compliance requirements may need semi-annual or continuous testing. IBM’s 2025 breach cost data confirms that faster detection and containment produce measurable cost reduction, which makes regular, rigorous testing a direct financial risk management investment.¹

Is a Red Team exercise always more valuable than a penetration test?

No. A Red Team exercise answers different questions, not better ones. For organizations in early security maturity stages, a Red Team engagement will surface the same basic issues a penetration test would have identified at a fraction of the cost and duration. Red Team exercises deliver their highest value when an organization already has a functioning security operations capability and needs to validate it under realistic, sustained adversarial pressure.

Can a single engagement combine multiple methodologies?

Yes. A well-scoped full-program assessment from a firm like IOActive can combine penetration testing, adversary simulation, hardware assessment, and elements of Red Teaming within a single engagement. The key is scoping around the organization’s most important security questions, not selecting a methodology and fitting the questions to it afterward.

What distinguishes a full-stack security assessment from a standard penetration test?

A standard penetration test evaluates exploitability within a defined scope, typically application code, network infrastructure, or cloud configuration. Full-stack assessment examines how vulnerabilities and attack paths connect across hardware, firmware, embedded software, AI pipelines, physical infrastructure, and enterprise applications simultaneously. It is appropriate for any organization whose risk surface extends beyond software-defined boundaries, which now describes most Global 1000 enterprises with connected devices, operational technology, or AI-enabled business processes.

Sources

IBM. “Cost of a Data Breach Report 2025.” ibm.com/reports/data-breach
IOActive. “IOActive Research Timeline.” ioactive.com/ioactive-research-timeline/

INSIGHTS | September 1, 2026

Offensive Security Best Practices for Modern Enterprises

By IOActive

Security professional reviewing server infrastructure in a data center as part of offensive security best practices.)

Annual assessments are not enough. A strong security program tests its defenses against realistic attack scenarios throughout the year. Can an attacker reach a critical service? Will the security team see the activity? Can the organization contain it before the business feels the impact?

The answers depend on people, processes, and technology working together. These offensive security best practices help security leaders build an ongoing, threat-informed capability.

Offensive Security Best Practices at a Glance

Best practice	What it does	What to do	Business value
Threat-informed objectives	Prioritizes relevant threats, assets, and risks	Select two test objectives: one high-value asset path and one critical service path	Better use of security resources
Adversary emulation	Recreates realistic attacker behavior and objectives	Map one chained attack path and define evidence for each step	More accurate risk insight
Red and Purple Team exercises	Challenges defenses, then improves them collaboratively	Run an independent Red Team exercise, then retest the highest-risk gap with the Blue Team	Measurable defensive learning
Continuous validation	Retests controls after change, remediation, and new threats	Define retest triggers and compare the original result with the new result	Ongoing assurance
Full-stack coverage	Evaluates people, processes, technology, and dependencies	Map one business-critical service and test an attack across at least two layers	Fewer blind spots
Enterprise risk integration	Connects findings to business priorities and decisions	Assign an owner, a treatment decision, and a 90-day remediation path	Better governance and investment

Use the table to plan the work. The sections below show how to implement each practice and choose reporting measures.

Set Threat-Informed Objectives

Effective testing starts with the threats and assets that matter most. Before choosing an assessment, identify critical services and sensitive data. Also identify privileged identities and operational systems, and map the dependencies that support them.

Mandiant’s 2025 data shows why this prioritization matters. Exploits were the most common initial infection vector in its investigations, accounting for 33%. Stolen credentials accounted for another 16%. Prioritize the attack paths most likely to affect the business.

Create a risk register using four fields: business service, high-value asset, likely threat scenario, and security question. Rank each scenario by business impact, then assess its exposure and the ability to detect and contain it. Turn the highest-ranked scenarios into test objectives.

What to do

Choose two objectives: test one path to a high-value asset and one path that could disrupt a critical business service.
Write the security question: for example, “Can an attacker with a compromised identity reach the payment environment without triggering a response?”

These objectives set a clear destination and make the result easier to measure. Next, model how an attacker might reach it.

Use Adversary Emulation to Test Real Attack Paths

Adversary emulation recreates realistic attacker behavior and objectives. Moving well beyond isolated weaknesses, it tests whether an attacker can join techniques, move through the environment, and reach a clear target.

A scenario may include initial access and privilege escalation. It may include lateral movement and persistence. It may end with access to a high-value asset. A Red Team approach uses threat intelligence to shape the scenario. It also uses attacker tactics, techniques, and procedures to model a real attack chain.

Turn each step into a control-validation action. Record the failed control and the evidence available, then record the owner, remediation action, and retest date. This keeps the exercise focused on reducing risk and assigning follow-up work.

Mandiant reported a global median dwell time of 11 days in its 2025 report. When an outside party found the intrusion, the median was 26 days. Use these figures as context for your own baseline. For each exercise, record whether the path was completed, along with detection coverage, time to detect, time to contain, business impact, and internal discovery time.

Emulation should show which improvement can reduce risk next.

What to do

Build one attack chain: map the path from the selected entry point to the target asset, including the control expected to stop each step.
Define the evidence in advance: agree on the alerts, logs, response actions, and timing measures that will determine whether each control worked.

With the path defined, pair independent attack pressure with collaborative defensive improvement.

Combine Red Team and Purple Team Exercises

Red Team exercises provide an independent challenge. Skilled operators try to bypass controls and follow realistic attack paths. They work toward a defined objective. Threat-emulation services include Red Team, Purple Team, physical security and breach assessment, and social engineering.

Purple Team work turns that challenge into measurable defensive improvement. The offensive and defensive teams examine alerts together. They tune detection logic, refine response playbooks, and rerun the highest-risk failed step. Red Team shows what an attacker may accomplish. Purple Team tests whether defenders can detect and stop it.

Start with the highest-risk failed step, and focus the first retest on the control that matters most. Have the Blue Team confirm the expected alert, then run the response action. Repeat the step until the result is measurable. Track time to detect, time to contain, technique coverage, and recurring false positives.

No single improvement percentage applies across Red Team and Purple Team exercises. Compare the baseline with the retest result to show whether the organization became faster, more visible, or more resilient.

What to do

Run two exercises: use an independent Red Team scenario to test the attack path, then use a Purple Team session to validate the highest-risk detection and response gaps.
Retest the failed step: after tuning the alert, repeat the technique and confirm that the response works under realistic conditions.

The resulting evidence feeds the next practice: continuous validation.

Use Security Validation to Continuously Test Controls

Controls can lose effectiveness after configuration changes, new technology, security incidents, or shifts in attacker behavior. Security validation provides a repeatable way to check priority controls over time.

Build validation into risk, change, and remediation workflows. A practical cycle is: test the control, identify gaps, remediate them, retest, and report progress.

Define a retest trigger for each priority control. Verizon’s 2026 Data Breach Investigations Report found that software vulnerabilities began 31% of breaches and ransomware appeared in 48% of breaches. The report also found that 15% of breaches involved attack techniques bolstered by generative AI. These findings support validation whenever the environment or threat picture changes.

What to do

Set five triggers: retest after a material configuration change, a new exposed service, a high-severity vulnerability, a relevant threat-intelligence update, or completed remediation.
Report one outcome: record whether the original failure was reproduced, contained, or resolved, and attach the evidence.

Continuous Validation Triggers and KPIs

Validation trigger	Minimum response	KPI to report
Material configuration change	Rerun the affected attack step	Detection coverage before and after the change
New exposed service	Test access, authentication, and monitoring	Unauthorized paths found
High-severity vulnerability	Validate exploitability and containment	Exploit success and time to contain
Relevant threat-intelligence update	Add or revise an emulation scenario	Techniques covered
Completed remediation	Retest the original failure and record evidence	Failure reproduced: yes or no

When a failed control crosses a system boundary, extend the test across the full stack and verify the handoff.

Test the Full Stack

Attack paths cross security teams and technology layers. A weakness in identity management may expose an application. An application compromise may then provide access to cloud infrastructure, operational technology, or sensitive data.

A mature program tests people and processes as well as technology. The scope may include applications, APIs, cloud environments, endpoints, connected devices, AI systems, supply chains, hardware, and firmware. Shape the assessment around business risk and the dependencies that could change the outcome.

Full Stack Security Assessments cover physical security, hardware, embedded systems, and silicon-level systems. They also cover software, people, processes, and supply-chain security. This cross-layer view helps teams understand one attack path from entry point to business impact.

AI adoption adds another cross-layer dependency that can span several teams. Include identity, cloud, data, and AI workflows in the same risk conversation. Keep those workflows connected to the broader security program.

Measure the layers that matter to the selected service. Useful KPIs include social-engineering success and reporting rates. Track privileged paths, authorization bypasses, cross-zone paths, asset-to-asset paths, and untested dependencies.

What to do

Start with one service: map every dependency that supports a business-critical service, from people and facilities to applications and data.
Cross two layers: select one attack scenario that moves across at least two layers, such as identity to cloud or physical access to a workstation.

This produces a practical full-stack test and gives business leaders evidence they can use.

Connect Findings to Enterprise Risk Management

Offensive security creates value when each significant finding answers four questions. What could an attacker do? Which business service is affected? Which control failed? What should the organization address first?

The financial stakes make this translation important. IBM’s 2025 Cost of a Data Breach Report put the average global breach cost at $4.44 million and the mean time to identify and contain a breach at 241 days. Connect each finding to exposure, disruption, response performance, and the cost of reducing the risk.

NIST’s 2026 Cybersecurity Framework 2.0 quick-start guide links cybersecurity risk, enterprise risk, and workforce decisions. Give each priority finding a business owner, risk scenario, treatment decision, target date, and success measure.

Useful measures include priority attack paths validated and detection and containment performance. Track recurring control failures and the time between remediation and retesting. Map those measures to decisions about ownership, funding, staffing, architecture, and accepted risk.

What to do

Assign a decision owner: give each priority finding one accountable business owner and a technical lead.
Build a 90-day roadmap: put the highest-impact attack paths first, define retest dates, and report progress in the same forum used for enterprise risk decisions.

Enterprise Risk Decision Matrix

Security evidence	KPI to report	Enterprise decision
A priority attack path succeeds	Percentage of priority paths completed	Fund remediation or formally accept the risk
Detection is missing or delayed	Median time to detect	Prioritize monitoring, logging, or staffing
A control fails after remediation	Repeat-failure rate	Revisit the control design or implementation
Retesting is repeatedly delayed	Days overdue	Escalate ownership and delivery risk
A business service has several exposed layers	Number of exposed layers	Sequence a full-stack improvement plan

The real result is a better question: “Which risk decision should this evidence change?”

Make Offensive Security an Ongoing Capability

An ongoing capability links four activities: threat intelligence shapes the scenario, testing produces evidence, an owner handles remediation, and retesting confirms the result.

IOActive offers Red Team and Purple Team exercises, physical security and breach assessments, and social engineering. Its services also include full-stack assessments, penetration testing, code review, reverse engineering, secure development, advisory services, security training, and OCP SAFE assessments.

Select the service combination that matches the attack path. One engagement can expose the path, while follow-on testing and advisory support can help teams sustain the fix.

What to do

Schedule the retest first: define the evidence required to close the finding before the initial engagement begins.
Review the cycle quarterly: refresh threat scenarios, check overdue remediation, and select the next business-critical attack path.

Talk to IOActive About Offensive Security Best Practices

A mature offensive security program turns realistic attack testing into clear decisions. Test a business-critical attack path, measure how quickly defenses detect and contain it, fix the highest-risk gap, and retest.

If you need help connecting these activities across your technology stack, talk to IOActive. The team can help you apply these practices to a clear business risk.

Talk to IOActive about offensive security best practices

Sources

Google Threat Intelligence, “M-Trends 2025: Data, Insights, and Recommendations From the Frontlines,” https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
IOActive, “Red Team & Purple Team Services,” https://www.ioactive.com/service/red-team-and-purple-team-services/
Verizon, “2026 Data Breach Investigations Report,” https://www.verizon.com/business/resources/reports/dbir/
IOActive, “Full Stack Security Assessments,” https://www.ioactive.com/service/full-stack-security-assessments-2/
IBM, “2025 Cost of a Data Breach Report: Navigating the AI rush without sidelining security,” https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai
National Institute of Standards and Technology, “NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide,” https://csrc.nist.gov/pubs/sp/1308/final

INSIGHTS | May 28, 2024

5 Signs You’re Ready for a Red Team

By IOActive Red Team

We often talk about security as a continuum; a journey toward greater maturity and increased capability. Along that path, the practice of red team testing serves as an important milestone, not just for the benefits it offers, but also for what participating in red teaming says about the state of security — overall posture, culture, commitment to continuous improvement — in any organization.

Red team tests remain one of the most effective ways to probe defenses and identify vulnerabilities. And unlike traditional penetration tests, red team exercises simulate sophisticated cyber attacks that mimic real-world threats, providing a comprehensive assessment of security posture. That said, red teams are most effective in organizations that have reached a certain strata of infosec sophistication, a level necessary to realize the benefits of this more advanced approach.

Some of this is table stakes for any kind of advanced security methodology in any organization of any size or stripe. You need to check some basic boxes before you even get to the red team checklist.

Cybersecurity Maturity That’s Above Baseline

The organization’s security foundation must be solid. That means having clear and effective security policies and procedures in place that are not only understood, but also reliably adhered to by all stakeholders. If the organization’s policies are still in the early stages of development — or if the team is still struggling to enforce existing policy — it’s too early for the kinds of stark assessments that a more sophisticated effort like red team exercises provide.

You need a comprehensive understanding of the IT and security environments. Basic security controls and best practices must be in place along with a strong security operations team monitoring and trained to respond effectively to security incidents . There should be a history of conducting penetration tests and security assessments supported by taking corrective actions from their results. These measures will not only make existing security stronger, they ensure that the insights gained from goal-oriented, adversarial testing will be actionable, meaningful, and impactful.

With those basic qualifiers in hand, here’s five specific things to look for in your current environment that indicate your enterprise is primed and ready for the rigors of red team testing.

1. There’s a Strong Internal Security Culture

A red team engagement is not just a technical challenge; it encompasses the human factor of cyber risk. If your organization has already established a strong internal security culture, it signals that you’re ready for the next level of adversarial attack simulation. This culture should include ongoing security awareness programs, regular training sessions, and a proactive approach to security issues among all employees.

Organizations with a robust security culture are better equipped to handle the findings of a red team exercise, as their employees are more likely to follow established protocols, report suspicious activities, and participate effectively in the incident response process.

At this stage, it’s also critical to be certain the security team fully understands the role and the value of the red team. This is not an isolated assessment; it’s a strategic initiative to test and enhance the organization’s overall security posture. IT and security personnel should be educated on the purpose and benefits of red teaming, ensuring that the subsequent exercises are not perceived as critiques but rather as opportunities for growth.

2. You’ve Conducted Regular Penetration Tests

When charting a course toward greater infosec maturity, there are many stops along the route. Pentesting is one of those waypoints that should come well before the red team. Pentests are less complex, but still eminently useful activities that should be a regular occurrence in any organization that is considering stepping up to red teaming.

Organizations can utilize pentesting to focus on specific applications, internal networks, or a particularly critical system, however the testing does not assess the security team’s ability to respond to an incident quickly nor the effectiveness of the existing monitoring and detection controls. Red team exercises take security assessments to the next level by emulating real threat actors and using the same tactics, techniques, and procedures (TTPs) seen in today’s sophisticated attacks.

Incorporating regular pentests demonstrates a mature security posture and a proactive approach to managing risk. Pentests ensure that the lower-hanging security vulnerabilities have been addressed prior to the red team’s more strategic, stealthy attacks.

3. Top Management Supports the Red Team Plan

The adoption of red team testing needs buy-in from top to bottom. When the C-suite understands and supports the exercise, it encourages a culture of security awareness across all levels of the company. Such commitment from executives ensures that the resources required for red team testing — read: time and money — are allocated appropriately.

If the executive team is still bogged down chasing current, defensive shortcomings and has not yet realized the value of proactive testing, it may be too early for red teaming. It’s crucial to engage top management in order to define exercise scope and objectives that align with the strategic goals of the enterprise.

Ultimately, when the red team exercise kicks off, only a handful of employees, including 1-2 execs, are aware of when it will occur and what the goals are. The purpose of an unannounced test helps to ensure that security personnel will treat any related security alerts as a real event and respond appropriately.

4. There’s a Comprehensive Incident Response Plan in Place

An organization’s readiness to respond to security incidents is a litmus test of its resilience. Red team testing is not just about identifying vulnerabilities but also about evaluating and enhancing incident response capabilities. Each action and TTP used during the exercise will be documented and mapped to the Mitre ATT&CK Framework to help the organization understand its strengths and weaknesses when it comes to attack detection and prevention.

An organization with a comprehensive incident response plan — one that’s regularly updated and tested — is in a strong position to derive the full benefits of a red team exercise. Conversely, if incident response plans are either non-existent or incomplete, a better plan might be to concentrate resources on developing the IR protocols and saving the red teaming for a later date. After the training is complete and a well-established plan has been vetted through tabletop exercises, then it’s time to put the plan to the test and identify gaps through red teaming.

5. You Have Budget Allocated for Advanced Security Measures

Investing in information security is more critical than ever, and red team testing remains one of the best investments an organization can make; one that yields high returns in identifying and mitigating critical, business-damaging risks. If the organization has dedicated budget for security measures — and is willing to allocate a portion of that budget for advanced methods such as threat hunting and red team testing — that in itself demonstrates a serious commitment to safeguarding the company’s digital assets.

Of course, the budget for red team testing shouldn’t come at the expense of other foundational security measures. Red teaming, like most advanced infosec methodologies, is best viewed as a complement to existing security strategy and an important part of the enterprise’s ongoing risk management process. Through red team exercises, the enterprise can validate that their security controls are effective and capable of detecting or stopping an advanced attack through actionable results.

Making the Most of Red Teaming

So, you’ve met all the criteria and are ready to join the ranks of the red teaming participants. That’s no small commitment. Now that you’re on the path toward adding this methodology to the organization’s security arsenal, you can build in some reasonable expectations for success metrics in the program. Here’s some of the ways your developing red team approach should continue to pay dividends over the long haul:

Bolstered Security Posture: By simulating realistic attacks, red team testing helps refine defenses, making organizations resilient against not only attacks that mimic real-world threat actors , but also against future, unknown threats.
Spotlight on Critical Vulnerabilities: A red team will uncover weaknesses and risks that preconceived notions and traditional testing often miss by chaining multiple vulnerabilities together to accomplish its goals. This is the best way to ensure that all aspects of security are being assessed and fortified, including the people and physical locations, not just technology
Improved Incident Response: There’s absolutely no better way to hone IR skills than through real-world attack scenarios. Red team activities will challenge and educate security and incident response teams, significantly improving the organization’s preparedness for actual attacks by using real TTPs and testing the teams’ ability to detect and react efficiently.

Red Team Testing: Taking the Next Step

Conducting red team testing is a critical component of a comprehensive security strategy, but it’s important to approach it at the right time and with the correct level of preparation. Organizations need to evaluate themselves honestly to make sure they and their skilled defenders are ready to withstand the rigor — and the potential revelations — red team testing will almost certainly bring.

Remember, cybersecurity is a continuous process, and red team testing, when the time is right, can be a crucial part of your company’s ongoing improvement. Gear up, get ready, and get testing.

INSIGHTS | September 1, 2016

Five Attributes of an Effective Corporate Red Team

By Daniel Miessler & Ryan O'Horo

After talking recently with colleagues at IOActive as well as some heads of industry-leading red teams, we wanted to share a list of attributes that we believe are key to any effective Red Team.

[ NOTE: For debate about the relevant terminology, we suggest Daniel’s post titled The Difference Between Red, Blue, and Purple Teams. ]

To be clear, we think there can be significant variance in how Red Teams are built and managed, and we believe there are likely multiple routes to success. But we believe there are a few key attributes that all (or at least most) corporate Red Teams should have as part of their program. These are:

Organizational Independence
Defensive Coordination
Continuous Operation
Adversary Emulation
Efficacy Measurement

Let’s look at each of these.

Organizational Independence is the requirement that the Red Team be able to effectively act as a real-world attacker in terms of scope, tools, and techniques employed. Many organizations restrict their Red Teams to such a degree that they’re basically impotent, which in turn lulls the company into a false sense of security.

Defensive Coordination is the requirement that Red Teams regularly interact with their counterparts on the defensive side to ensure the organization is learning from their activities. If a Red Team is effective on its own, but doesn’t share its knowledge and successes with the defense in order make it stronger, then the Red Team has lost sight of its purpose.

Continuous Operation is the requirement that the organization remain under constant, rolling attack by the Red Team, which is the polar opposite of short, penetration-test style engagements. Red Teams should operate through campaigns that span weeks or months in duration, and both the defensive teams and the general user population should know that at any moment, of any day, they could be targeted by both a Red Team campaign of some sort, or by a real attacker.

Adversary Emulation is the requirement that Red Team campaigns should be regularly updated based on the actual tools, techniques, and processes employed by real-world attackers. If cyber-criminals are doing X this quarter, let’s emulate that. If we’re seeing some state actors doing Y this year, let’s emulate that. If you’re not simulating—to some significant degree—the techniques being used by actual attackers, the Red Team is providing questionable value.

Efficacy Measurement is the requirement that Red Teams know how effective they are at improving the security posture of the organization. If we can’t tell a clear story around how our defenses are improving, i.e., that it’s getting increasingly more difficult to compromise, move laterally, and achieve attacker goals, then you’re getting limited value from any work that’s being done.

Summary

Here’s a pointed capture of those points:

If your group is significantly restricted in its scope and capabilities by the organization, you probably don’t have an effective Red Team
If your group doesn’t regularly work hand-in-hand with the defensive side of the organization in order to improve the organization’s security posture, you probably don’t have an effective Red Team
If your internal or external service operates based on projects that happen once in a while rather than being staggered and continuous, you probably don’t have an effective Red Team
If you aren’t constantly updating your attack campaigns based on new intelligence on actual threat actors, you probably don’t have an effective Red Team
If you aren’t closely monitoring the effectiveness of the attack campaigns (and the responses to them by the defense) over time, you probably don’t have an effective Red Team

There are many other components of a solid Red Team that were not mentioned—top-end malware kits, elite security talent, deep understanding of the attacker mindset, etc.—but we think these five components are both most fundamental and most lacking.

As always, we would love to hear from other security types who might have a differing opinion. All of our positions are subject to change through exposure to compelling arguments and/or data.

RESEARCH | September 15, 2015

The iOS Get out of Jail Free Card

By Michael Allen

If you have ever been part of a Red Team engagement, you will be familiar with the “Get out of Jail Free Card”. In a nutshell, it’s a signed document giving you permission to perform the activity you were caught doing. In some instances, it’s the difference between walking away and spending the night in a jail cell. You may be saying, “Ok, but what does a Get out of Jail Free Card have to do with iOS applications?”

Well, iOS mobile application assessments usually occur on jailbroken devices, and application developers often implement measures that seek to thwart this activity. The tester often has to come up with clever ways of bypassing detection and breaking free from this restriction, a.k.a. “getting out of jail”. This blog post will walk you through the steps required to identify and bypass frequently recommended detection routines. It is intended for persons who are just getting started in reverse engineering mobile platforms. This is not for the advanced user.

Environment Setup

§ Jailbroken iPhone 4S (iOS 7.xx)

§ Xcode 6.4 (command-line tools)

§ IDA Pro or Hopper

§ Mac OS X

Intro to ARM Architecture

Before we get started, let’s cover some very basic groundwork. iOS applications are compiled to native code for the ARM architecture running on your mobile device. The ARM architecture defines sixteen 32-bit general-purpose registers, numbered from R0-R15. The first 12 are for general-purpose usage, and the last three have special meaning. R13 is denoted as the stack pointer (SP), R14 the link register (LR), and R15 the program counter (PC). The link register normally holds the return address during a function call. R0-R3 hold arguments passed to functions with R0 storing the return value. For the purposes of this post, the most important takeaway is that register R0 holds the return value from a function call. See the references section for additional details on the ARM architecture.

Detecting the Jailbreak

When a device is jailbroken, a number of artifacts are often left behind. Typical jailbreak detection routines usually involve checking for those artifacts before allowing access to the application. Some of the checks you will often see include checking for:

Known file paths
Use of non-default ports such as port 22(OpenSSH), which is often used to connect to and administer the device
Symbolic links to various directories (e.g. /Applications, etc.)
Integrity of the sandbox (i.e. a call to fork() should return a negative value in a properly functioning sandbox)

In addition to the above, developers will often seek to prevent us from debugging the process with the use of PT_ATTACH_DENY, which prevents the use of the ptrace() system call (a call used in the debugging of iOS applications). The point is, there are a multitude of ways developers try to thwart our efforts as pen testers. That discussion, however, is beyond the scope of this post. You are encouraged to check out the resources included in the references section. Of the resources listed, The Mobile Application Hackers Handbook does a great job covering the topic.

Simple PoC

We begin with bypassing routines that check for known file paths. This approach will lay the foundation for bypassing the other checks later on. To demonstrate this, I wrote a very simple PoC that checks for the existence of some these files. In the event one is found, the program prints out a message stating the device is jailbroken. In a real world scenario, the application may perform a number of actions that include, but are not limited to, preventing you from accessing the application entirely or restricting access to parts of the application.

Figure 1: Jailbreak detection PoC

If you have a jailbroken device and would like to test this for yourself, you can use clang – the Clang C, C++, and Objective-C compiler to compile it from your Mac OS host. Refer to the man page for details on the following command.

clang -framework Foundation -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ jailbreak.c -o jailbreak -miphoneos-version-min=5.0

Once compiled, simply copy the binary to your jailbroken device and execute it from the command line. On a side note, Objective-C is a strict superset of C, and in most instances you will see jailbreak detections implemented in C/C++. A sample run of the program reveals that the device is jailbroken:

Figure 2: PoC execution showing device is jailbroken

One of the first steps during an assessment is static analysis on the binary. Let’s begin by viewing the symbols with the following command nm jailbreak

Figure 3: Static analysis – extracting symbol information

Luckily for us, symbols have not been stripped, and based on the above, the _isJailBrokenmethod looks like the function responsible for determining the state of the device.

Figure 4: Examining the binary in IDA

The isJailBrokenmethod is called at 0000BE22, after which the value in R0 is compared to 0. Recall from earlier that the return value from a function call is stored in the R0 register. Let’s confirm this in gdb. We will set a break point at 0000BE28the BEQ (branch if eq) instruction and examine the contents of the R0 register.

Figure 5: Examining the contents of the R0 register

As expected the value at R0 is 1, and the program takes the branch that prints the message “Device is JAILBROKEN”. Our goal then is to take the other branch. Let’s examine the isJailBroken function.

Figure 6: isJailBroken function analysis

At 0000BEA0, the stat function is called, and at 0000BEA8, R0 is compared to 0. If the value is not zero, meaning the path hasn’t been found, the program processes the next file path in the jbFiles[] array shown in the PoC earlier on. However, if the path was found, we see R0 is set to 1 before the program returns and eventually exits.

Figure 7: Determining where R0 register is set

This above snippet corresponds to the following section in our PoC:

Figure 8: R0 gets set to 1 if artifact found

So if we update this, and instead of moving 1 in R0 we move a 0, we should be able to bypass the jailbreak detection check and thus get of jail. Let’s make this modification and run our binary again.

Figure 9: Updating R0 register to 0

Linking this to our PoC, it is the equivalent of doing:

Figure 10: Effect of setting R0 to 0

In other words, the isJailBroken function will always return 0. Let’s set another breakpoint after the comparison like we did before and examine the value in R0. If we are right, then according to the following snippet, we should branch to loc_BE3C and defeat the check.

Figure 11: PoC snippet

As expected the value is now 0, and when we continue program execution we get our desired result.

Figure 12: Bypassing the detection

But what if the binary has been stripped?

Earlier we said that we were lucky because the binary was not stripped, so we had the symbol information. Suppose however, that the developer decided to make our job a bit more difficult by stripping the binary (in our case we used strip <binaryname>). In this case, our approach would be a bit different. Let’s first look at the stripped binary using the nm tool:

Figure 13: Stripped binary

And then with gdb on the jailbroken mobile device:

Figure 14: Examining the stripped binary in gdb

It should be immediately clear that we now have a lot less information to work with. In the case of gdb, we now see “No symbol table is loaded”. Where has our isJailBrokensymbol gone? Let’s push ahead with our analysis by running strings on the binary.

Figure 15: Extracting strings from the binary

Ok, so we seem to be getting closer as we can see some familiar messages. Let’s head back to IDA once again:

Figure 16: Disassembled stripped binary

This certainly looks different from what we saw when the symbols were included. Nonetheless, let’s find the references to the strings we saw earlier. You can use the strings view in IDA and then use Ctrl+X to find all references to where they are used.

Figure 17: Locating references to the status message

Navigating to the highlighted location, we again see the familiar CMP R0, #0:

Figure 18: Locating CMP R0, #0

And if we go to the highlighted sub_BE54, we end up in our isJailBroken function. From that point on, it’s a repeat of what we already discussed.

Ok, but the functions are now inline

Another practice that is often recommended is to inline your functions. This causes the compiler to embed the full body of the function, as opposed to making a function call. With this in mind, our modified isJailBroken function declaration now looks like this:

Figure 19: Declaring functions inline

Before we continue, let’s remind ourselves of what the disassembled binary looked like prior to this change:

Figure 20: Binary before inline function

Now, let’s examine the modified binary:

Figure 21: Modified binary with function now inline

The _isJailBrokenmethod has now been inlined, and we no longer see the call(bl) instruction at 0000BE22 as before. Note that the original function body is still stored in the binary:

Figure 22: Function body still stored despite being inline

To prevent this, some very astute developers will go a step further and make the function static thereby removing the function body. The new function declaration will now be:

Figure 23: Static inline function

Again let’s look at this in IDA.

Figure 24: Disassembled inline binary

Instead of R0 being set from a function call as we saw previously, it is set from a value read from the stack using the LDRcommand at 0000BE9C. On closer examination we see the R0 register being set at 0000BE8Aand 0000BE98 and then stored on the stack:

Figure 25: Disassembled inline binary

At this point it’s the same process as before, we just need to move a 0 into R0at location 0000BE8A. And the rest is history.

Let’s block debugging then

We hinted at this earlier, when we said that the ptrace() system call is used when debugging an application. Let’s examine one implementation often used by developers:

Figure 26: ptrace function declaration

Figure 27: ptrace implementation

See the references section for additional details and source of the above code snippet. If we run our modified binary on the device and try to debug it as we have been doing with gdb, we are presented with the following:

Figure 28: Unable to use gdb

We were stopped in our tracks. Also, keep in mind that the function was inlined and the binary stripped of symbols. Examining it in IDA reveals the following:

Figure 29: Disassembled binary with call to ptrace_ptr

Pay special attention to the highlighted area. Recall from earlier, we said function arguments are in registers R0-R3. The ptrace_ptr call takes four arguments the first being PT_DENY_ATTACH with a value of 31. The /usr/include/sys/ptrace.h header file reveals the list of possible values:

Figure 30: Snippet ptrace documentation

So what happens if we pass a value that is outside of the expected values? The parameter is set at 0000BDF2 and later passed as the parameter to ptrace_ptrat 0000BDFC. We see a value of 1F, which translates, to 31 in decimal. Lets update this to 0x7F.

Figure 31: Updating PT_DENY_ATTACH to random value

We copy the modified binary back to our device and have our bypass.

Figure 32: Bypassing PT_DENY_ATTACH

Another oft recommended technique for determining if a debugger is attached is the use of the sysctl()function. Now it doesn’t explicitly prevent a debugger from being attached, but it does return enough information for you to determine whether you are debugging the application. The code is normally a variation of the following:

Figure 33: Using sysctl()

When we run this from gdb, we get:

Figure 34: Output from running with sysctl()

Let’s pop this in IDA. Again the binary has been stripped and the checkDebugger function inlined.

Figure 35: Call to sysctl()

At 0000BE36we see the sysctl() function call and at 0000BE3A we see the comparison of register R0 to -1. If the call was not successful, then at 0000BE40 the program copies 1 to R0 before returning. That logic corresponds to:

Figure 36: Code snippet showing call to sysctl()

The fun begins when sysctl() was successful. We see the following snippet:

Figure 37: A look at the ternary operator

This corresponds to the following code snippet:

Figure 38: Ternary operator in our source code

When the application is being debugged/traced, the kernel sets the P_TRACED flag for the process where P_TRACED is defined in /usr/include/sys/proc.h as:

Figure 39: P_TRACED definition in /usr/include/sys/proc.h

So at 0000BE4Awe see the bitwise AND against this value. In effect, the loc_BE46 block corresponds to the above ternary operator in the return statement. What we want then is for this call to return 0.

If we change the instruction at 0000BE46 to a MOVS R0, 0 instead:

Figure 40: Patching the binary

When we run the program again we get

Figure 41: Successful bypass

Now, you may be asking, how did we know to update that specific instruction? Well, as we said, the loc_BE46 block corresponds to the use of the ternary operator in our code. Now don’t allow the compiler’s representation of the operator to confuse you. The ternary operator says if the process is being traced return 1 otherwise return 0. At 0000BE46 R0 is set to 1, and R0is also set at 0000BE5C.[EW1] However, in the latter case, the register is set in a conditional block. That block gets hit when the check returns 0. In other words, the process is not being traced. Let’s look at this in gdb. We will set a breakpoint at 0000BE5E, the point at which R0gets stored on the stack at [sp,#0x20].

Figure 42: Inspecting the R0 register

As you can see, R0has a value of 1, and this was set at 0000BE46 as discussed earlier. This value is then written to the stack and later accessed at 0000BE60 to determine if the process is being traced. We see the comparison against 0 at 0000BE62, and if it’s true, we take the path that shows we bypassed the debug check.

Figure 43: Reversing the binary

So, if we set a breakpoint at 0000BE60 and look what value was read from the stack, we see the following:

Figure 44: Examining the value in R0 that will be checked to determine if process is being debugged

This value(0x00000001) is the 1 that was copied to R0 earlier on. Hence, updating this to 0 helps achieve our goal.

Bringing down the curtains

Before we go, let’s revisit our very first example:

Figure 45: Revisiting first example

Recall we modified the isJailBroken function by setting register R0 to 0. However, there is a much simpler way to achieve our objective, and some of you would have already picked it up. The instruction at 0000BE28 is BEQ (branch if eq), so all we really need to do is change this to an unconditional jump to loc_BE3C. After the modification we end up with:

Figure 46: Updated conditional jump to unconditional jump

And we are done, however, we had to take the long scenic route first.

Conclusion

As we demonstrated, each time the developer added a new measure, we were able to bypass it. This however does not mean that the measures were completely ineffective. It just means that developers should implement these and other measures to guard against this type of activity. There is no silver bullet.

From a pen tester’s stand point, it comes down to time and effort. No matter how complex the function, at some point it has to return a value, and it’s a matter of finding that value and changing it to suit our needs.

Detecting jailbreaks will continue to be an interesting topic. Remember, however, that an application running at a lower privilege can be tampered with by one that is at a higher privilege. A jailbroken device can run code in kernel-mode and can therefore supply false information to the application about the state of the device.

Happy hacking.

References:

http://www.amazon.com/The-Mobile-Application-Hackers-Handbook/dp/1118958500
http://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315
http://www.amazon.com/Hacking-Securing-iOS-Applications-Hijacking/dp/1449318746
https://www.owasp.org/index.php/IOS_Application_Security_Testing_Cheat_Sheet
https://www.theiphonewiki.com/wiki/Bugging_Debuggers
http://www.opensource.apple.com/source/xnu/xnu-792.13.8/bsd/sys/ptrace.h

INSIGHTS | October 3, 2013

Seeing red – recap of SecurityZone, DerbyCon, and red teaming goodness

By Ian Amit

I was fortunate enough to have a chance to participate in a couple of conferences that I consider close to my heart in the past couple of weeks. First – SecurityZone in beautiful Cali ,Colombia. This is the third year that SecurityZone has been running, and is slowly making its way into the latin american security scene.

This year I delivered the keynote on the first day, and albeit being a bit harsh on the whole “let’s buy stuff so we can think we are secure” approach, it was very well received. Apparently, stating the “obvious” – which is that a security function in an organization is tasked with risk management of said organization, rather than with dealing purely with the technical IT infrastructure for it.

Next up was DerbyCon. I can’t stress enough how much fun it is to run the Red Teaming Training class with my best friend Chris, and the kind of feedback (and learning) we have a chance to get. The biggest return for us every time we deliver the training is watching the trainees open up and really “get” what red team testing is all about, and the kind of value it brings to the organization being tested. This moment of enlightenment is sheer joy from me still.

Speaking of DerbyCon – OMG what a conference! It’s just amazing what a small crew of dedicated individuals can come up with in such a short period of time. If you’d ask me for how long this con has been running I’d say at least 8-9 years. And this one was just the third iteration. Everything from the volunteer crew, through the hotel staff (major kudos to the Hyatt for taking DerbyCon on, and “working” with us – going well above just accommodating a conference venue).

My talk at DerbyCon focused on the “receiving end” of a red-team, which articulates what an organization should do in order to thoroughly prepare for such an engagement, and maximize the impact from it and the returns in the form of improving the organizational efficiency and security posture. I had a lot of great feedback on it, and some excellent conversations with people who have been struggling to get to that “buy-in” point in their organizations. Really hoped that I managed to help a bit in figuring out how to more accurately convey the advantages and ROI of such an engagement to the different internal groups.

I’m really looking forward to getting more feedback on it, and more discussions on how to communicate the essence of red teaming to organizations – which is always a challenge in internal organization politics.

Following are the slides. Have fun!

http://www.slideshare.net/iamit/seeing-red-26632440

INSIGHTS | June 14, 2013

Red Team Testing: Debunking Myths and Setting Expectations

By Ian Amit

The term “cyber” seems to be overused in every corner of the information security industry. Now there is a new buzz phrase in computer security, “red team engagements.” Supposedly (to get “cyber” on you), you can have a red team test, and it will help move your organization in the correct “cyber direction.”

But what is red team testing really? And what is it not? In this post I’ll try to make some sense of this potent term.

The red team concept has been around for ages. It started as a military term for a team dedicated to simulating all of an enemy’s activities, including everything from methodology to doctrine, strategy, techniques, equipment, and behaviors. The red team was tasked with mastering how the adversary thinks and operates, and then executing the enemy’s strategies and tactics in the field. This allows your own forces to experience what it would be like to combat this enemy in real life − without the risk of getting injured or killed.

Fast forward 10-12 years and red teams are being used in civilian industry as well as in the military. In private industry, red teams simulate adversaries (not necessarily foreign armies) that could impact the organization. The adversary could be criminals vying to get your money, competitors trying to get their hands on your latest designs, or random attackers who want to exploit, destroy, or simply harm your organization. Their motivations can range from social activism, political strategy, financial gain, and so on.

When IOActive is asked to conduct a red team test, our main goal is to accurately and realistically simulate these types of adversaries. So the first, and probably most important, element of a red team test is to define the threat model:

· Who is your adversary?

· What are their motivations?

· Which adversaries are you most afraid of? (This is usually any party that wants to put you out of business.)

Defining the threat model is crucial to the success of a red team engagement, because it determines the value your organization will get from the project.

After we articulate the threat model, the fun part of the engagement begins.

Fun? Yes, because in the real world most tests, such as penetration tests do not really depict a persistent adversary. Instead, engagements such as pen tests simulates specific strategies that a persistent adversary will use as part of an overall attack.

The red team engagement, on the other hand, includes all possible elements that an adversary might use in such an attack (which is why it is often referred to as “no scope” or “full scope” testing).

In this context, everything including your employees, your infrastructure, the physical office locations, your supply chain − that’s every third party you use as part of your ongoing operations − and more. When developing attack scenarios for red team engagements, every element has to fit in perfectly.

Think of it as an “Ocean’s Eleven” type of attack that can include:

· Social engineering

· Electronic and digital attacks

· Bypassing physical controls

· Equipment tampering

· Getting into the supply chain to access your assets

· And more

This is full scope testing. Unlike in other types of engagement, all or almost all assets are “in scope”.

Note: Red team engagements do commonly use “reverse scoping” techniques to identify assets that are critical to operations and the types of tampering, access, or removal that are off limits for these assets. These sensitive assets are still in scope. But reverse scoping defines and restricts actions that may substantially disrupt operations.)

So far this sounds like a fun game. But hold on, it isn’t just about the attack. What I like the most is seeing how an organization’s ongoing security operations handle red team attacks.

In a red team test, very few people in the organization know about the test, and even fewer actually know when the test will happen. This means that from an operational security view, all red team activities are treated as if they involve a real adversary.

We gain a lot of insights from the actions and reactions of the organization’s security team to a red team attack. These are the types of insights that matter the most to us:

Observing how your monitoring capabilities function during the intelligence gathering phase. The results can be eye opening and provide tremendous value when assessing your security posture.
Measuring how your first (and second) responders in information security, HR, and physical security work together. Teamwork and coordination among teams is crucial and the assessment allows you to build processes that actually work.
Understanding what happens when an attacker gains access to your assets and starts to exfiltrate information or actually steals equipment. The red team experience can do wonders for your disaster recovery processes.

These are some of the rewards and benefits of a red team test. As you can see, they go well above and beyond what you would get from other types of focused tests.

I hope this explanation eliminates some of the confusion about red team testing that I have seen lately in Internet discussions. I am not saying that there is no value in pen tests, social engineering engagements, physical assessments, or anti-phishing campaign. However, to see how all of these different types of security considerations work in the real world, they also need to be considered as part of a larger (and relevant) context so that you can see how well your organization is prepared for any type of attack.

Last but not least, if you’d like to get hands-on training in how red team engagements are conducted, considering attending our two-day Red Team Training (https://www.blackhat.com/us-13/training/red-team-training.html) at BlackHat 2013 in Las Vegas.

Chris Nickerson and I will cover everything discussed in this post, with particular focus on the elements that go beyond penetration testing. Our topics will include lock picking, social engineering, physical assessments, and, most importantly, how to combine all of these elements into a realistic and successful simulation of an adversary. We also plan to give each of our students a very interesting goodie bag.

Hint: You’ll have fun walking through airport security with that bag :-).