DEV Community: Jason

What Is a Red Team Assessment?

Jason — Fri, 06 Jun 2025 06:48:51 +0000

TL;DR
A red team assessment is a real-world attack simulation that tests how well your people, processes, and systems can detect and respond to a threat. Unlike a penetration test, which looks for as many vulnerabilities as possible, red teaming is goal-driven. It mimics adversary behavior to evaluate whether your defenses actually work under pressure. This is about detection and response, not just patching CVEs.

What is a Red Team Assessment?

A red team assessment is a full-scope security exercise that simulates how a real attacker would target your organization. Unlike penetration testing, which focuses on finding and documenting vulnerabilities, red teaming is about stealth, persistence, and impact. The objective is to test not just your systems, but your security team’s ability to detect and respond to threats in real time.

At its core, red teaming is an adversary simulation which means your organization plays defense while a skilled external team plays offense. The red team will often begin with reconnaissance, gain initial access, escalate privileges, and move laterally through systems in an attempt to achieve a goal like exfiltrating data, compromising credentials, or reaching sensitive environments, all while trying to stay undetected.

This type of engagement answers a critical question: Can your organization detect and contain a real attack before damage is done?

Cybersecurity stats show that the US will be a lucrative target for more than 50 percent of cybercrime attacks by 2027 (Cybersecurity predictions reveal that the US going to be a soft target for more than half of cybercrime attacks in another five years, hence US-based companies should consider reinforcing their protection against cyber threats.)

How is a Red Team Assessment Different from a Penetration Test?

It’s common to confuse what a red team vs penetration test is, but they serve very different purposes. A penetration test (or pentest) focuses on identifying as many vulnerabilities as possible within a defined scope. The goal is to find flaws, confirm they’re exploitable, and provide remediation guidance. Pentesters often work with knowledge of the environment, operate in a cooperative manner, and may have access to credentials or internal systems to speed up discovery.

A red team assessment, in contrast, simulates a real-world attack without alerting the defenders. The red team plays the role of an adversary. They’re not trying to find every vulnerability. Their mission is to achieve a specific objective, such as accessing sensitive data, compromising a privileged account, or reaching a protected network segment. The focus is on testing detection and response, not just technical exposures.

Another key distinction is in how each test is conducted. Penetration tests are often scheduled and coordinated in advance. Red team operations are stealthy. They mimic actual threat actor behavior, including persistence and evasion. This is why red teaming is often called adversary simulation. It’s not about what’s broken, but what can be exploited quietly and effectively.

If you’re comparing a red team vs penetration test, it comes down to this:

Pentest: What’s vulnerable?
Red team: Can your team detect and contain a real attacker?

Both are valuable. They simply answer different security questions.

What Are the Goals of a Red Team Operation?

The main goal of a red team assessment is not to find every vulnerability. It is to simulate how a real attacker would approach your organization. This involves gaining access, avoiding detection, and using realistic tactics to test how well your people, processes, and technology respond to a live threat.

A red team operation is objective-based. Instead of following a checklist, the red team is given specific missions to accomplish, such as:

Accessing sensitive financial systems
Gaining domain administrator privileges
Exfiltrating customer or patient data
Reaching production environments without being noticed

These objectives mirror how real adversaries operate. They rely on planning, persistence, and creative thinking to achieve specific outcomes.

Another major goal is to test your organization’s detection and response capabilities. Can your security team identify abnormal behavior? Are logs being collected and monitored? If something suspicious is discovered, how quickly and effectively can the team contain it?

Red team assessments often reveal gaps across departments, not just in your technical defenses. Successful engagements might involve phishing employees, bypassing physical security controls, or escalating privileges from a basic user account into critical infrastructure, all while remaining undetected.

In summary, a red team assessment shows you how far a determined adversary could go if they targeted your organization. It provides a reality check and a roadmap for improving your overall defensive posture.

What Happens During a Red Team Assessment? (Phases)

A red team assessment follows a structured series of phases that mirror how real attackers operate. Each step is designed to test not just technical defenses, but also detection, response, and decision-making under pressure. While tactics vary based on the target and goals, most red team operations follow a framework similar to this:

1. Planning and Scoping

Every red team operation starts with clearly defined objectives. The planning phase includes identifying target systems, outlining rules of engagement, defining success criteria, and making sure all stakeholders understand the scope. This is also where safety controls and legal protections are put in place.

2. Reconnaissance

The red team gathers intelligence about your organization using both passive and active methods. This may include scanning public records, scraping employee data from LinkedIn, mapping external infrastructure, identifying third-party services, or reviewing DNS, WHOIS, and OSINT data sources.

3. Initial Access

Next, the team attempts to gain a foothold. This might happen through phishing, exploiting misconfigurations, abusing weak credentials, or bypassing exposed services. The goal is to enter the environment without alerting defenders.

4. Privilege Escalation and Lateral Movement

Once inside, the red team works to increase its access and move deeper into the environment. They might exploit local vulnerabilities, harvest credentials, crack password hashes, or pivot through systems to get closer to high-value targets.

5. Objective Execution

This is where the red team attempts to complete its primary goal. That could involve extracting data, accessing sensitive applications, simulating ransomware deployment, or compromising domain controllers. Everything is documented, but the objective is completed in a controlled, non-destructive manner.

6. Reporting and Debrief

After the operation, the red team delivers a detailed report that includes the attack path, all techniques used, detection points (if any), and actionable recommendations. This is often followed by a debrief with the blue team to review what happened, where gaps exist, and how to improve detection and response moving forward.

Who Needs a Red Team Assessment?

Red team assessments are not for every organization. They are best suited for businesses that already have basic security measures in place and want to test how well those defenses hold up under a real attack scenario.

Ideal candidates for red teaming include:

Mid-sized to large enterprises with mature IT and security operations
Organizations with an internal blue team or SOC* that want to validate their detection and response capabilities
Critical infrastructure sectors such as energy, healthcare, or finance, where impact from a breach could be catastrophic
Compliance-driven businesses that must go beyond checkboxes and demonstrate true resilience
SaaS or technology companies handling sensitive data across customer-facing apps and APIs

If your team is only beginning to address basic vulnerabilities, a penetration test or vulnerability scan is a better starting point. But if you want to know how your systems, staff, and procedures perform when faced with a stealthy, persistent adversary, a red team assessment will give you the answers you are looking for.

This type of assessment is particularly useful before a major audit, after a security architecture overhaul, or as part of a regular resilience testing program. It provides not only technical insights, but also clarity on whether your incident response playbooks are effective in practice.

How to Prepare for a Red Team Assessment

Red team assessments are only as effective as the preparation that goes into them. If your organization is not ready, the results may not reflect your actual defensive capability, or worse, the engagement may cause confusion or disruption. Taking time to prepare ensures that you get real value from the test.

1. Define Clear Objectives

What do you want to learn from this assessment? Are you testing your blue team’s response, identifying detection gaps, or evaluating response procedures? Clarity around goals will shape how the red team plans and executes the operation.

2. Set Rules of Engagement (ROE)

Work with the red team to define what is in and out of scope. This includes specifying which systems can be targeted, what types of attacks are allowed, who should be notified in case of escalation, and what the success criteria will be.

3. Confirm Monitoring and Logging

Make sure your defensive systems are in place and functioning. Your blue team should have access to logging, SIEM tools, endpoint detection, and network visibility. If detection is part of the objective, it is critical that telemetry is available to measure performance.

4. Align Internally Without Breaking Stealth

Only a limited number of stakeholders should know the test is happening. However, those individuals need to be aligned on the scope, timeline, safety controls, and how to respond if something unexpected occurs.

5. Review and Test Response Playbooks

Have your incident response procedures and escalation paths documented and accessible. This is your chance to see how those processes hold up under pressure. If the red team simulates exfiltration or domain takeover, how will your team respond?

6. Prepare for the Post-Engagement Phase

Plan to review the findings as a team. This is where most of the value comes from. A strong red team report will include attack paths, missed detection opportunities, and tactical recommendations. Be ready to use that feedback to close gaps and strengthen your overall posture.

The above list will help you prepare for red teaming. Preparing well helps ensure the red team engagement is focused, safe, and valuable. It also gives your internal teams the chance to learn, improve, and grow, which is the whole point of testing in the first place.

Real-World Example from a Red Team Engagement

In one red team assessment, we were hired by a regional power company to test both their digital and physical security. The goal was simple: simulate how an attacker could breach their facility and gain access to systems controlling power distribution.

We started by performing reconnaissance from public sources. Within a few hours, we identified vendor badge templates, LinkedIn profiles of contractors, and photos of employees entering the building. Using this information, we created a forged contractor badge and mimicked the uniform style worn by their HVAC vendor.

On the day of the test, we arrived on site, blended in with the morning shift, and tailgated a group of employees through the rear entrance of the building. Other red teamers found a low spot in a fence and made their way in the facility. Once inside, we plugged a drop box into an open Ethernet port in a rarely used conference room. The device was configured to call back over a cellular connection, giving us remote access to the internal network.

Within two hours, we had domain-level credentials, access to operational control systems, and visibility into the SCADA network. The company’s security team was unaware of the intrusion until we presented our findings a few days later.

This assessment proved how physical access combined with light social engineering could lead to complete compromise of critical infrastructure. It was a wake-up call for leadership, and it led to significant improvements in both badge policy and network segmentation.

Final Thoughts: Where Red Teaming Fits in a Security Program

Red team assessments are not where security begins. They are what you invest in once the basics are already in place. Organizations that benefit the most from red teaming are the ones that want to validate their detection, response, and recovery in real-world scenarios.

Think of red teaming as the ultimate stress test for your people, your technology, and your process. If your organization already runs regular vulnerability scans, conducts annual penetration testing, and has an incident response plan on paper, a red team assessment helps answer the next question: how well does it all work when an actual threat is simulated?

Red team operations are most effective when done as part of a broader security program. They should complement your ongoing defensive efforts, not replace them. These assessments can be used to identify weaknesses in your SOC’s visibility, expose blind spots in your architecture, and improve the quality of your response procedures.

For organizations subject to regulatory frameworks or those operating in critical industries, red teaming is not just valuable, it is becoming expected. As threats become more targeted and persistent, your defenses need to be tested against realistic adversaries, not just automated scans.

If your team wants to go beyond checkboxes and see how it performs under real pressure, a red team assessment will give you answers that no dashboard can.

Want to See How Your Security Team Handles a Real Attack?

At Artifice Security, we conduct red team assessments that simulate stealthy adversaries across physical, digital, and hybrid environments.
We show you how an attacker could gain access, what would go undetected, and what it would take to stop them, before it happens in real life.

✅ Real adversary simulation
✅ Full kill chain, from recon to exfil
✅ Actionable reporting that cuts through the noise

👉 Schedule a consultation
👉 Or contact us here with questions

FAQ

What is the purpose of a red team assessment?
The purpose of a red team assessment is to simulate a realistic, stealthy cyberattack to evaluate how well your organization can detect, respond to, and contain a threat. It is less about finding every vulnerability and more about exposing blind spots in detection and response.

How long does a red team assessment usually take?
Most red team engagements take between two and four weeks, depending on the size of the organization, the scope, and the complexity of the environment. Some advanced operations may run longer to simulate persistent threats more accurately.

How is red teaming different from penetration testing?
Penetration testing focuses on identifying technical vulnerabilities in a defined scope. Red teaming focuses on simulating an adversary’s behavior, using stealth and creativity to achieve specific goals like data exfiltration or privilege escalation. It is about testing your ability to respond, not just your exposure.

How often should a company do red team assessments?
For mature organizations, once a year is a strong baseline. Some companies integrate red teaming into a larger purple team program, alternating red team assessments with blue team training and response tuning throughout the year.

About the Author

Jason Zaffuto is the founder and lead consultant at Artifice Security, where he specializes in manual penetration testing, red team operations, and adversary simulation. With more than 25+ years of experience in offensive security, military intelligence, and critical infrastructure assessments, Jason brings real-world insight to every engagement.

Before launching Artifice Security, he led red team projects at Rapid7, performed physical and network security testing for NASA and DHS, and conducted global operations as part of U.S. military intelligence teams. He holds certifications including OSWE, OSCP, OSCE, and CPSA.

Jason’s mission is simple: test systems like real attackers would, and give clients the clarity they need to improve.

📍 Learn more at ArtificeSecurity.com or schedule a consultation.

What Is Web Application Penetration Testing? Manual Pentesting Explained

Jason — Thu, 05 Jun 2025 08:08:42 +0000

TL;DR:

Web application penetration testing is a manual, real-world simulation of how attackers would try to break into your web app. It goes far beyond automated scans by uncovering logic flaws, chaining vulnerabilities, and testing how your defenses actually hold up. Done right, it protects sensitive data, prevents breaches, satisfies compliance requirements, and gives you peace of mind that scanners alone can’t provide.

What is Web Application Penetration Testing?

Web application penetration testing is the process of ethically hacking a web app to identify and fix security weaknesses before an attacker can exploit them. Unlike automated vulnerability scanners, which only scratch the surface, a proper web app pen test mimics real-world attack scenarios. It involves manual testing techniques designed to expose flaws in logic, authentication, access controls, session handling, and more which are the kinds of issues that automated tools often miss.

At Artifice Security, we specialize in manual penetration testing on web applications because we know what real attacks look like. Our job isn’t to generate a long report of false positives, it’s to help you understand how a skilled attacker would target your application, what they could do if they succeed, and how to stop them.

What’s the Difference Between a Vulnerability Scan and a Pentest?

A vulnerability scan is an automated process that checks your web application for known issues, usually by comparing it against a database of signatures. It’s fast, relatively inexpensive, and helpful as a first step in your security program. But a scan is not a web application penetration test.

Web application penetration testing goes far deeper. A proper pen test on a web application involves manual analysis and exploitation techniques used by real attackers. Instead of just listing unpatched software or missing headers, a web app pen testing engagement simulates how an attacker would exploit authentication flaws, bypass business logic, escalate privileges, and pivot through a sequence of vulnerabilities to access sensitive data.

Scanners cannot think. They do not follow conditional flows, misuse inputs creatively, or combine multiple smaller issues into a real-world breach. Human testers can. That is the core difference. A scanner might alert you to an outdated JavaScript library. A manual web application penetration test might show that an attacker could use that library to hijack sessions and steal user accounts.

If you are only running vulnerability scans, you are seeing the surface. Manual penetration testing on web applications reveals the depth that real attackers are counting on you to miss.

Why Is Web App Pen Testing Important?

Web applications are one of the most common entry points for attackers. They’re exposed to the internet, handle sensitive data, and often include complex functionality like authentication, file uploads, and integrations with other systems. If there’s a flaw, someone will eventually try to exploit it.

A proper pen test on a web application helps you find those flaws before an attacker does. Unlike surface-level scans, web app pen testing identifies issues that can lead to real-world breaches. These include things like broken access controls, logic flaws in business workflows, session hijacking, and authentication bypasses. Many of these issues are missed by automated scanners.

Web application penetration testing also helps you meet compliance requirements. Standards like PCI-DSS, HIPAA, SOC 2, and ISO 27001 either recommend or require regular pen testing for applications that handle sensitive data. For many companies, passing an audit is only part of the story. The real reason to invest in a pen test is to avoid the kind of incident that costs money, damages trust, and takes months to recover from.

If you care about protecting your users, your brand, or your bottom line, a real web pen testing process is not optional. It’s a necessity.

What Are the 5 Stages of a Web Application Pentest?

A professional web application penetration test follows a structured methodology. This ensures consistency, depth, and accurate risk assessment. While tools and techniques may vary, most pentesting engagements follow five key stages.

1. Reconnaissance

In this phase, we gather as much information as possible about the target application. This includes identifying domains, endpoints, technologies, exposed APIs, and potential user roles. Passive techniques like reviewing public code repositories or archived web content can also reveal valuable insights.

2. Enumeration

Once we understand the surface area, we begin probing for weaknesses. This involves mapping the entire application and testing inputs, parameters, access control logic, and session behavior. Automated tools might assist here, but the real value comes from manual exploration.

3. Exploitation

This is where the test moves from observation to action. We attempt to exploit the vulnerabilities we found, simulating what a real attacker would do. This could include SQL injection, cross-site scripting, file upload abuse, or access control bypass. Our goal is to prove the risk, not just list theoretical flaws.

4. Post-Exploitation

If exploitation is successful, we assess what could be done next. Could sensitive data be exfiltrated? Could an attacker maintain access? This phase helps prioritize which vulnerabilities truly matter to the business.

5. Reporting

Finally, we document everything in a detailed, actionable report. This includes each finding, its business impact, clear remediation steps, and supporting evidence. At Artifice Security, we also walk clients through the findings to ensure nothing gets lost in translation.

This process transforms a generic scan into a true pen test on a web application. It gives you more than a report, it gives you insight.

What Tools Are Used in Web App Pen Testing?

Tools are a big part of any web application penetration testing process, but they are only as effective as the person using them. Real pentesters don’t rely on tools to do the job, they use them to assist with discovery, exploitation, and verification.

At Artifice Security, we use a combination of open-source and commercial tools during our web app pen testing engagements. Some of the most common include:

Burp Suite Pro: This is our primary platform for intercepting and modifying HTTP requests, testing authentication flows, fuzzing parameters, and automating parts of the process. Burp Suite for web apps is one of the most trusted tools in the industry.
SQLMap: For testing SQL injection vulnerabilities, SQLMap is incredibly efficient. It automates the process of detecting and exploiting SQLi, but we still validate and tune the output manually.
Nmap: While often used in network testing, Nmap can help identify exposed services that are tied to web application infrastructure, such as admin panels or misconfigured development ports.
Custom scripts and payload generators: No tool covers everything. That’s why manual web application security testing often requires writing or modifying scripts to handle edge cases or exploit logic flaws specific to a client’s app.
Other tools: We also use tools like wfuzz, ffuf, JWT.io, Postman, and browser-based dev tools for specific testing needs.

Using these tools helps us identify vulnerabilities quickly and efficiently, but they never replace human logic. Automated scanners miss critical flaws because they can’t reason through workflows or spot context-specific weaknesses. The real value comes from how experienced pentesters apply these tools during a manual test.

What Vulnerabilities Are Usually Found?

Most web applications have security flaws, even the well-maintained ones. During a web application penetration test, we often find vulnerabilities that range from common misconfigurations to serious issues that could lead to full account takeover or data breaches.

Here are some of the most frequent findings we uncover during manual web app pen testing:

SQL Injection (SQLi): This allows attackers to manipulate backend database queries. If exploited, it can lead to data theft, data modification, or even complete database compromise.
Cross-Site Scripting (XSS): A vulnerability that lets attackers inject malicious scripts into web pages. These scripts often run in other users’ browsers and can be used to steal credentials or hijack sessions.
Broken Access Control: When users can access data or functions they shouldn’t. This might include viewing another user’s account, accessing admin features, or modifying restricted resources.
Insecure Direct Object References (IDOR): A common logic flaw where users can manipulate input (like IDs in URLs) to access data that belongs to someone else.
Security Misconfiguration: Default credentials, exposed debug endpoints, and outdated libraries fall into this category. These are often easy to find and easy to exploit.
Path Traversal: A vulnerability that allows attackers to access files outside the intended directory, potentially exposing source code, system configuration files, or logs.
Cross-Site Request Forgery (CSRF): A flaw that tricks users into performing actions they didn’t intend, often by embedding malicious links in emails or third-party sites.

These are just a few examples, and what we find depends heavily on how your web application was built. Vulnerabilities vary by framework, developer habits, and how third-party libraries are implemented. That’s why penetration testing on web applications must be tailored and hands-on. Scanners may flag some of these issues, but they often miss the deeper problems hiding in your business logic.

Can You Just Use a Scanner Instead of a Pentester?

Scanners are useful. They can quickly identify low-hanging fruit like missing security headers, outdated components, or basic misconfigurations. But they can’t tell you whether an attacker can break your authentication system or access sensitive data through a flawed business logic path.

For example, a scanner might detect that your site uses HTTP instead of HTTPS. A real pentest on a web application might reveal that an attacker could chain that with a session fixation issue and compromise user accounts. That difference can mean everything.

A vulnerability scanner works like a checklist. It flags known patterns and signatures. That’s valuable, but it only tells part of the story. Web application penetration testing is different. A human tester looks at how your application behaves, how roles interact, and how seemingly minor flaws might be combined to create a major security risk.

Scanners also don’t handle custom authentication flows, single sign-on, multi-step transactions, or non-standard APIs very well. In modern apps, these are common and often where the real issues hide.

If you’re only relying on automated scans, you’re getting an incomplete picture. Manual web app pen testing gives you the full story and it’s the only way to truly understand your exposure.

How Much Does Web Application Penetration Testing Cost?

The cost of a web application penetration test depends on several factors. These include the size and complexity of your app, how many user roles and features need to be tested, whether you want authenticated testing, and how deeply you want the engagement to go. In general, a manual pen test for a web application can range from a few thousand dollars for a simple app to over ten thousand for a large enterprise-grade system.

It’s important to understand what you’re paying for. A proper penetration test on a web application involves more than just running a scanner and sending you a list of findings. It means a skilled human will spend hours (multiple days or sometimes weeks) manually probing your app, replicating attacker behavior, and verifying each issue’s impact. The result is a detailed report with real insight, not just a PDF full of automated scan output.

At Artifice Security, we scope every engagement individually to make sure clients only pay for what they actually need. Whether you’re looking for a targeted test on a new feature or a full web app penetration test from login to logout, we’ll help you understand what makes sense for your goals and your budget.

If you’re curious what a test would cost for your specific app, get in touch with us for a quick consultation. We’ll give you a real answer, not a sales pitch.

How Does Manual Testing Actually Work?

Manual web application penetration testing is exactly what it sounds like. It is a skilled human methodically testing your app by hand. This is what separates a true penetration test from a vulnerability scan.

When we test a web application manually, we start by mapping out its structure, identifying all the endpoints, forms, user roles, and key workflows. We look at how data moves through the app, how authentication and sessions are handled, and where logic flaws might exist. We test common attack vectors, but we also test for uncommon ones such as the edge cases that scanners miss because they require context, creativity, or chaining multiple steps together.

For example, we might notice that two separate features don’t seem risky on their own, but when combined, they allow for unauthorized access or data exposure. We test for things like broken access control, parameter manipulation, and privilege escalation by actually trying to exploit them. If something looks exploitable, we prove it.

Throughout the process, we document our steps, capture evidence, and assess real-world impact. Pen testing for web applications is as much about thinking like an attacker as it is about knowing the tools.

The outcome is more than just a vulnerability list. You get a full picture of how secure your app really is and what you need to fix to keep attackers out.

Do You Need Web App Testing for Compliance?

In many industries, web application penetration testing isn’t just recommended, it’s required. Regulatory standards like PCI-DSS, HIPAA, SOC 2, and ISO 27001 all include requirements or strong guidance around regular penetration testing for systems that handle sensitive data.

If your web application processes payments, stores health records, manages customer information, or interacts with regulated data in any way, there’s a good chance you’re expected to test its security on a recurring basis. Auditors want to see that you’ve taken steps to validate your defenses, not just assume they work.

But here’s what many companies miss: compliance isn’t the same as security. A checkbox scan won’t uncover the kinds of logic flaws or chained exploits that attackers look for. That’s why most frameworks explicitly or implicitly recommend manual penetration testing on web applications, not just automated tools.

At Artifice Security, we help clients meet their compliance requirements without losing sight of the bigger picture. A well-executed web app pen testing engagement supports audit readiness, risk reduction, and peace of mind all at once.

If you’re not sure whether your business needs a penetration test for compliance purposes, we can help you figure it out, and we’ll explain it in plain language.

Real-World Case Example

During a recent web application penetration test, we evaluated four internal applications for a mid-sized SaaS company. The engagement revealed multiple high-risk vulnerabilities that had been previously missed by automated tools.

One of the most critical issues was a SQL injection vulnerability that allowed data to be extracted from the backend database without authentication. Using SQLMap, we confirmed that the application was vulnerable by sending time-based payloads and retrieving table and user data from staging environments. We were able to pull invite codes, session identifiers, and sensitive user records from exposed tables, all without logging into the system.

We also found that the application allowed cleartext password transmission over HTTP. By capturing traffic with Wireshark, we demonstrated that login credentials and API keys were being transmitted without encryption, making them easy to intercept on a public or shared network.

Additional issues included weak password enforcement (allowing passwords like “1”), lack of account lockout, session hijacking through static tokens, and exposure of outdated JavaScript libraries with known vulnerabilities.

These flaws were not hypothetical. We showed how they could be chained together to gain access to user accounts, view restricted content, and perform actions as other users. The client took immediate steps to remediate the issues, and we later confirmed that the fixes were effective during a follow-up retest.

This is why manual web application penetration testing matters. A scanner might have flagged a few of these, but only a real test revealed how they could be used together to compromise the application.

How to Choose a Web Application Pentest Provider

Not all penetration testing companies are created equal. Some vendors rely almost entirely on automated scanners, rebranding the output as a “pentest” and sending clients a generic PDF full of surface-level findings. That’s not real security testing, and it’s not what your business needs.

When choosing a provider for web application penetration testing, look for a team that performs manual testing and explains how they simulate real-world attack scenarios. Ask about their methodology, whether they follow frameworks like OWASP or NIST, and whether they tailor their approach to your application’s architecture and business logic.

You should also ask what tools they use, how they validate findings, and whether they exploit vulnerabilities to show actual impact. A good pentest should show you not just what’s broken, but how it could be exploited and how to fix it.

Red flags to avoid:

Reports that only list CVSS scores without context
Firms that can’t explain their testing steps
No manual exploitation or custom payload development
Vague claims about “AI-driven testing” with no human involvement

In fact, we made a whole article about red flags you should avoid from less than ethical companies.

At Artifice Security, every pen test on a web application is manual, methodical, and tailored to your actual risk. We don’t rely on buzzwords or automated tools to do the job for us. We test the way attackers do, carefully, creatively, and thoroughly.

Get a Web App Penetration Test with Artifice Security

If you’re building or maintaining a web application, don’t leave your security up to guesswork or surface-level scans. Attackers don’t rely on automated tools alone, and neither should you.

At Artifice Security, we perform real, manual web application penetration testing that uncovers the flaws scanners miss. We simulate the same techniques used by attackers to help you find and fix issues before they become breaches.

Whether you need testing for compliance, internal risk management, or peace of mind, we’ll work with you to scope the right approach based on your app, your risk, and your goals.

Let’s make sure your application is secure.
Book a free consultation or contact us here to get started.

FAQ

What does a web application penetration test include?
A proper web application penetration test includes manual testing of authentication, session management, access control, input validation, business logic, and API endpoints. It goes beyond scanning by simulating real-world attacks and verifying each vulnerability’s actual impact.

How often should web apps be penetration tested?
Most organizations should test their web applications at least once a year or after any major code changes, feature releases, or infrastructure upgrades. Compliance requirements may also dictate testing frequency.

What’s the difference between manual and automated web app testing?
Automated tools scan for known issues but often miss logic flaws, chained vulnerabilities, and context-specific risks. Manual testing is performed by human experts who think like attackers and find what scanners can’t.

What’s the typical timeline for a web application penetration test?
A standard test usually takes 3 to 7 business days depending on the application’s size, complexity, and scope. Reporting and remediation support are typically delivered within a week after testing concludes.

About the Author

Jason Zaffuto is the founder and lead consultant at Artifice Security, where he specializes in manual web application penetration testing and red team operations. With over 25 years of experience in IT, security, and military intelligence, Jason has worked on everything from internal network assessments to physical Red Team engagements for global enterprises, government agencies, and critical infrastructure.

He holds a Master’s degree in Cybersecurity from Georgia Tech, a BS in Network Security, and certifications including OSWE, OSCP, OSCE, and CPSA. Before launching Artifice Security, Jason was a senior pentester at Rapid7 and a systems engineer for NASA and DHS. He brings deep technical expertise, tactical creativity, and real-world offensive experience to every assessment.

To connect or book a consultation, visit ArtificeSecurity.com/contact or schedule a session.

What Is Kerberoasting? How Attackers Crack Service Account Passwords

Jason — Thu, 05 Jun 2025 04:36:58 +0000

TL;DR:
Kerberoasting is a post-exploitation technique used to extract and crack service account passwords in Active Directory. It’s fast, silent, and often leads directly to Domain Admin, which is why it remains a favorite method for ransomware groups. This post breaks down how it works, why it matters, and how you can detect and prevent it in your environment.

What is Kerberoasting?

If you have never heard of Kerberoasting, you are not alone. Most executives and business leaders are unfamiliar with it until it shows up in a post-incident report.

Kerberoasting targets a part of your internal infrastructure that is easy to overlook. It goes after service accounts, which are special user accounts created for systems and software, not people. These accounts often run your databases, backup tools, or internal apps. Since they operate in the background, service accounts are rarely reviewed and often use weak or outdated passwords.

Here is where the problem starts. Once an attacker has access to your internal network, even using a basic domain user account with no special privileges, they can request encrypted password data for those service accounts. The system gives it to them by design. The attacker saves this data, takes it offline, and begins cracking the passwords using freely available tools. If any of those passwords are weak, they can unlock access to critical systems or even gain Domain Admin control.

This process is called Kerberoasting, and it has become one of the most common ways attackers escalate privileges once they are inside. It does not require malware, exploit kits, or advanced tools. It takes advantage of how Active Directory works and how many organizations fail to enforce strong passwords and proper account hygiene.

This technique is used in both real ransomware attacks and in manual penetration tests, because it reflects what would happen in an actual breach.

How Does a Kerberoasting Attack Work?

Kerberoasting works because of how authentication is designed in Active Directory. The attacker does not need elevated access or special tools to start. They only need a valid domain user account, which can be obtained through phishing, a stolen VPN login, or other low-effort intrusion methods.

Once inside, the attacker moves through four simple steps:

1. Log in as a basic domain user.
They do not need admin access. Any regular account in the domain will work. These can often be found or guessed using public data, credential stuffing, or social engineering.

2. Identify service accounts and request tickets.
Using a tool like Rubeus or GetUserSPNs.py, the attacker queries Active Directory for service accounts tied to SPNs (Service Principal Names) and immediately requests their encrypted Kerberos service tickets, known as TGS tickets. These tickets are encrypted using the password hash of the service account.

3. Export those tickets and crack them offline.
Using tools like Hashcat or John the Ripper, the attacker attempts to brute force the password used to encrypt the ticket. If the password is weak or uses an outdated algorithm like RC4, this step can take only hours.

4. Use the cracked credentials to move deeper.
Once the attacker has a service account password, they check its permissions. If it has admin rights on any systems, which is often the case, they can log in, extract more credentials, or access sensitive data.

Imagine someone walks into your office building using a valid employee badge. They go to the front desk and request a copy of every service key used by internal departments. The receptionist hands them over without question, because the request follows normal protocol. Instead of trying the keys on doors right away, the person takes them to a private workshop, studies them, and makes duplicates. Once they figure out which key opens the most important doors, like the server room, they come back quietly and let themselves in.

That is how Kerberoasting works. The attacker uses a normal domain account to request encrypted service tickets. They take those tickets offline, crack the passwords, and use any successful result to access systems with elevated privileges, all without triggering alerts.

This entire process can be automated and done quietly. Most environments will not detect it unless specific logging and alerting are in place. That is what makes it so dangerous, especially in ransomware campaigns.

Why Is Kerberoasting Dangerous for Your Organization?

Kerberoasting is dangerous because it turns one small gap in your internal defenses into a direct path toward full domain compromise. It does not require malware. It does not rely on software vulnerabilities. And it often works even in environments that appear to follow standard security practices. This makes it a favored method for ransomware operators and other threat actors who want to quietly escalate their access without being detected.

Once an attacker cracks a service account password, they can begin moving laterally through the network. This means using that one account to access other systems, looking for more credentials, more access, and more control. Even if the cracked account is not a Domain Admin, it may still have local admin rights on key servers, access to backup data, or permissions that open new doors inside the network.

To put it in context, most ransomware incidents begin with something simple like a weak password or a stolen VPN login. But that initial access is just the beginning. What happens after the attacker gets in is what really causes damage. Kerberoasting is one of the fastest and quietest ways to turn that foothold into complete control of your domain.

This technique fits neatly into the second phase of an attack, where the goal is to escalate access and prepare for the final blow. Once the attacker gains Domain Admin, they can disable antivirus tools, access sensitive data, install persistence mechanisms, and launch a ransomware payload across hundreds of systems in minutes.

The risk is not just the loss of one account. The danger comes from what that account connects to and how quickly that access can grow. Kerberoasting gives attackers a way to chain together weak passwords, misconfigured permissions, and poor visibility into a full-blown breach.

For decision-makers, this is not just a technical flaw. It is a business risk that can lead to data loss, ransom payments, regulatory penalties, and long-term reputation damage. Ignoring it means giving attackers an easy and invisible path to your most sensitive systems.

💡 Real-World Threat. Real Fixes.
Most Kerberoasting attacks don’t need exploits, they just need a single weak service account. A proper internal pentest shows you exactly how far someone could get in your environment before a real attacker does.

What Tools Are Used in Kerberoasting Attacks?

Kerberoasting does not require advanced malware or custom code. In fact, attackers often use freely available tools to perform every step of the attack. If they gain access to a Windows system inside your network, they may run a tool called Rubeus, which allows them to interact with the Kerberos protocol and request service tickets. With just a few commands, Rubeus can list accounts tied to services, request the tickets, and export them for offline cracking.

Rubeus is popular with threat actors because it runs directly on a Windows host and blends in with normal system activity. It uses PowerShell or can be compiled as an executable. Either way, it is fast, quiet, and effective.

On the penetration testing side, we often use a tool called GetUserSPNs.py from the Impacket framework. This tool performs the same actions from a Linux system like Kali. It queries the domain controller for any account associated with a Service Principal Name, requests the encrypted ticket, and saves it to a file for analysis. The process reflects exactly what a real attacker would do, but in a controlled and safe environment.

There is also a module in Metasploit called auxiliary/gather/get_user_spns that can perform this step as well. While Metasploit is best known for exploitation, its modules are often used to demonstrate proof of concept during internal security assessments.

What these tools have in common is that they take advantage of normal, allowed behavior in a Windows domain. There is no exploit involved. The domain controller issues tickets because it is designed to. That is why tools like Rubeus and GetUserSPNs.py are so effective as they rely on built-in features and only need the kind of access most attackers can get early in an intrusion.

For security leaders, this means the tools themselves are not the real issue. The real issue is weak passwords, outdated encryption, and lack of visibility. The tools just reveal what is already possible in your environment.

How Can You Detect and Prevent Kerberoasting?

Kerberoasting is quiet by design. It uses legitimate features of Active Directory, so many environments do not detect it unless they are watching for very specific behaviors. That is part of what makes it so dangerous. It is not a virus, not a zero-day, and not something your firewall is going to block. It slips through unnoticed unless you know how to look for it.

Detection starts with logging. You need to collect and monitor Kerberos service ticket requests, especially when they involve accounts with Service Principal Names (SPNs). Windows Event ID 4769 can provide some visibility, but by default, most systems do not flag this as suspicious. What helps is correlating these requests with patterns, such as a low-privileged account making requests for multiple high-privilege service accounts in a short time span.

Security tools like Microsoft Defender for Identity or SIEM platforms like Splunk or Sentinel can help detect these anomalies, but only if the right logs are being ingested and alerts are properly configured. Without that, the entire attack can unfold with no one noticing.

Prevention focuses on reducing the attack surface. One of the most effective ways to block Kerberoasting is to use strong, complex passwords for all service accounts, especially those tied to SPNs. Passwords should be long (e.g. 24 characters), randomly generated, and changed regularly. If a password is too strong to crack in a reasonable amount of time, the attack becomes ineffective.

Another key step is using AES-only encryption for service accounts instead of older, weaker algorithms like RC4. Attackers often succeed because the tickets they capture are encrypted with outdated ciphers that can be cracked quickly. Enforcing AES means the encryption is much harder to break, even if an attacker manages to capture the ticket.

You can also reduce exposure by replacing traditional service accounts with Group Managed Service Accounts (gMSAs). These are managed by the domain controller and use complex passwords that rotate automatically. They cannot be used to log in interactively and are not vulnerable to Kerberoasting in the same way.

Finally, review and limit where your service accounts have admin rights. Many environments assign local admin access to service accounts on dozens of systems without realizing the risk. Just because a service needs to run on a server does not mean it needs elevated privileges everywhere.

To stop Kerberoasting, you need to harden accounts, enforce modern encryption, reduce privilege sprawl, and monitor for unusual Kerberos activity. It is not one fix. It is a combination of controls that work together to shut down this attack path.

How Penetration Testing Identifies Kerberoasting Risks

Kerberoasting is not something you can fully understand by looking at a checklist. It depends on real-world context, what accounts exist, how they are configured, where they have access, and how well they are protected. That is exactly why a manual penetration test is so valuable.

During an internal penetration test, we simulate the exact steps an attacker would take after gaining a foothold. If we are simulating a user-level compromise, one of the first things we do is look for service accounts tied to SPNs. Using tools like GetUserSPNs.py, we request service tickets from the domain controller and analyze the encryption type. If the tickets use weak ciphers or belong to accounts with short, guessable passwords, we attempt to crack them offline using tools like Hashcat.

The difference between this and a vulnerability scan is depth. A scanner might tell you that RC4 is still allowed or that a password policy is weak, but it will not tell you if a service account password can actually be cracked and used to access other systems. A manual pentest shows you what is possible right now, not what might be risky in theory.

We also test what happens next. If we successfully crack a service account password, we try to log in to systems where that account has access. If we can move laterally, escalate privileges, or reach sensitive data, we document every step. You see not just that a problem exists, but what someone could actually do with it.

In your case, we already covered this in our previous post, Can a Penetration Test Prevent Ransomware?, where a Kerberoasting attack led directly to Domain Admin access. That was not hypothetical, it reflected exactly what could happen in many real environments.

A proper penetration test does not stop at detection. It walks the same path an attacker would and gives you a clear report of what they would have found, how far they could have gone, and how to fix it.

Final Thoughts: Why This Attack Still Works in 2025

Still Common. Still Effective. Still Preventable.
Kerberoasting continues to succeed not because it’s new, but because internal environments are rarely tested the way attackers move.
At Artifice Security, we perform manual internal penetration tests that simulate real-world attacks like Kerberoasting. We identify weak service accounts, unsafe configurations, and paths to privilege escalation and we can help you shut them down before an attacker finds them.
If you want a real test of your internal security, schedule a free consult or contact us here.

📧 contact@artificesecurity.com
📞 720-515-1337
🔗 artificesecurity.com

About the Author

Written by Jason Zaffuto, Founder of Artifice Security
Jason is a veteran penetration tester with over 25 years of experience in IT, electronics, and offensive security. He served in the U.S. Army as a Military Intelligence Systems Maintainer and later worked in red team operations for both the military and private sector. He holds several degrees in electronics and Cybersecurity and has led engagements for Fortune 500s, critical infrastructure, and government agencies. Today, he leads Artifice Security, helping clients identify and fix the exact weaknesses ransomware attackers exploit.

FAQ

What is Kerberoasting in cybersecurity?
Kerberoasting is a technique where attackers request encrypted service tickets from Active Directory using a normal user account. These tickets can be taken offline and cracked to reveal the passwords of service accounts. If those accounts have elevated privileges, attackers can use them to access sensitive systems.

Can Kerberoasting be detected?
Yes, but it requires specific monitoring. You need to log and analyze Kerberos ticket requests, especially Event ID 4769. Unusual patterns, like a regular user account requesting multiple service tickets in a short time, may signal Kerberoasting activity. Most environments do not alert on this by default.

How do pentesters simulate Kerberoasting?
Penetration testers use tools like GetUserSPNs.py from the Impacket framework or the Metasploit module get_user_spns to request service tickets. They then try to crack those tickets offline using tools like Hashcat. If successful, they use the cracked credentials to test lateral movement and privilege escalation, just like a real attacker would.

What are the best defenses against Kerberoasting?
The most effective defenses include enforcing strong passwords for all service accounts, switching to AES-only encryption, using Group Managed Service Accounts (gMSAs), and reducing unnecessary privileges. Monitoring for unusual Kerberos activity is also essential for early detection.

Can a Penetration Test Prevent Ransomware? What Most Companies Miss

Jason — Thu, 05 Jun 2025 02:36:48 +0000

TL;DR:
Yes, a penetration test can help prevent ransomware. Not by blocking it directly, but by identifying the same weaknesses attackers use to gain access. These can be things like weak service account passwords, lack of MFA, poor internal segmentation, and exposed attack paths like Kerberoasting. In this post, I’ll break down how a real ransomware attack unfolded and show how a manual penetration test would have stopped it before it spread.

Ransomware attacks keep making headlines, but most don’t rely on advanced exploits or nation-state-level tools. They often start with simple issues like a weak password, an unprotected VPN, or an overlooked service account. This post answers a critical question many companies are asking: can a penetration test prevent ransomware before it happens? The answer is yes, if it’s done right.

How Do Ransomware Attacks Usually Start?

Most ransomware attacks don’t begin with some elite-level hack. They start with something simple: a weak password, a misconfigured VPN, or credentials stolen from a past breach. In this real-world case, the attacker gained access through a VPN gateway that didn’t require multi-factor authentication. It was a backup system at a disaster recovery site, overlooked during configuration. That single gap gave them an initial foothold.

Once inside, the attackers spent the next week moving laterally across multiple Windows systems using PsExec, a legitimate remote admin tool already in use by the company. There were no advanced exploits here. They simply used what was already available in the environment.

After about ten days, they pivoted to a Windows server and quietly loaded a tool called Rubeus through PowerShell. With it, they launched an attack called Kerberoasting, which let them request encrypted service account credentials from Active Directory. One of the cracked accounts, “admin1,” turned out to be a Domain Admin.

From there, things escalated quickly. The attackers dumped the NTDS.dit file, which holds every password in the domain, and exfiltrated over 100GB of data using WinSCP. Finally, they deployed ransomware across the network using PsExec and WMIC, copying the payload to hundreds of systems from a VirtualBox VM they spun up just for the job.

This entire compromise could have been prevented if the right security controls had been tested ahead of time. That is exactly where a real penetration test becomes critical.

Most ransomware breaches do not use advanced exploits. They rely on overlooked basics.

What Is Kerberoasting and Why Should You Care?

Kerberoasting is a technique attackers use to extract encrypted passwords for service accounts in Active Directory. What makes it especially dangerous is that it requires no elevated privileges. As long as an attacker has any valid domain user account, even one with no special access, they can run this attack and try to crack the passwords offline.

A service account is a user account used by automated tasks or services like SQL Server, backup software, or internal apps. These accounts are often overlooked in routine password audits and may have broad access across the environment. Because they are tied to SPNs (Service Principal Names), they can be identified and targeted using built-in domain queries.

Here’s how Kerberoasting works:

The attacker logs in using a basic domain user account.
They scan the domain for accounts with SPNs. In most environments, these are service accounts.
Active Directory returns encrypted service tickets (TGS tickets) for those accounts by default.
The attacker saves those tickets and attempts to crack them offline using tools like Hashcat or John the Ripper.
If the service account password is weak or uses outdated encryption like RC4, cracking it can be fast and reliable.

In this case, the attackers succeeded because the password for the service account they targeted was weaker than it should have been. Once they cracked it, they gained Domain Admin access and took full control of the environment.

During a penetration test, this is one of the exact techniques we use to simulate real-world attacks. While ransomware operators often use tools like Rubeus inside a Windows environment, we typically use GetUserSPNs.py from the Impacket toolkit on Kali Linux to do the same thing. Both approaches allow us to find service accounts vulnerable to Kerberoasting and provide clear guidance to fix the issue before an attacker can exploit it.

This is a practical attack method used by both real threat actors and ethical hackers. It is one of many reasons why a penetration test can prevent ransomware by exposing overlooked internal weaknesses that attackers often rely on.

What Happens If a Service Account Gets Compromised?

When attackers crack a service account password, the real danger begins. Even if that account is not a Domain Admin, it might still have local administrator rights on multiple systems. That means the attacker can start moving laterally across the network, hopping from one machine to another, looking for more credentials, access, and opportunity.

Lateral movement is the process of using one compromised system to access another. You can think of it like someone finding a key to one office in a building, and then discovering that key opens ten more. Each time they open a new door, they gain more visibility and more tools to work with.

This is often all it takes to get Domain Admin access. Once the attacker lands on a system where a Domain Admin account has logged in recently, they can use tools like Mimikatz or LSASS dumpers to extract credentials directly from memory. From there, full control of the environment is usually only a step or two away.

In the case we’re describing, one cracked service account led directly to a Domain Admin. But even if it hadn’t, the attacker could have still pivoted through the network, escalating slowly until they reached the same goal.

A good penetration test will simulate this exact process. After identifying vulnerable service accounts, we check whether they can be used to access other systems and gain additional privileges. If we can move laterally using a cracked service account, we flag it immediately and provide guidance to fix it. This is another clear way a penetration test can prevent ransomware, by identifying the internal escalation paths that most companies never realize exist.

Can a Penetration Test Help Prevent Ransomware?

Yes. A well-executed penetration test can absolutely help prevent ransomware. It does this by simulating the same steps an attacker would take after gaining initial access. Instead of waiting for someone with malicious intent to find the gaps, a manual penetration test exposes those weaknesses first, with clear steps on how to fix them.

In the attack we’ve been walking through, the threat actors got in using a basic VPN login, escalated privileges using Kerberoasting, and then moved laterally across the environment until they had full control. These steps are not unique to ransomware gangs. They are common tactics used in everyday penetration tests.

Here’s how a good internal pentest works in a similar scenario:

We start with no access, user-level access, or simulate it.
We attempt to identify service accounts using tools like GetUserSPNs.py.
We try to extract and crack Kerberos tickets offline.
If successful, we test whether that account gives us admin access to other systems.
We follow the same logic an attacker would: try to harvest credentials, pivot, and escalate.

The difference is that we stop there. Instead of launching ransomware or stealing data, we deliver a report that tells you exactly what happened, how far we got, and how to stop it from ever happening in the real world.

This kind of test goes far beyond what a vulnerability scanner would catch. A scanner might tell you that SMB signing is disabled, or that a patch is missing. But a manual pentest tells you what an attacker could actually do with that information.

If your goal is to prevent ransomware from locking down your environment, then simulating the attacker’s path is the only reliable way to see where your defenses fall short. That’s why a penetration test can prevent ransomware, not by guessing, but by proving what needs to be fixed before someone malicious finds it.

What’s the Difference Between a Vulnerability Scan and a Penetration Test?

A vulnerability scan checks your systems for known issues like missing patches, outdated software, or open ports. It compares your environment against a list of known vulnerabilities and reports what it finds. That’s useful, but it only tells you what is exposed — not what can actually be exploited.

A penetration test takes it further. Instead of listing vulnerabilities, it simulates what a real attacker would do with them. It shows how someone could chain small issues together, escalate privileges, move across the network, and reach critical assets. That is a big difference.

For example, a scanner might tell you that SMB signing is not enforced. A penetration test will show you that an attacker can use that gap to run NTLM relay attacks or impersonate users. A scanner might note that a service account password is old. A tester will show you that it can be cracked and used to access dozens of systems.

Another key difference is how each approach deals with context. Vulnerability scanners see every issue in isolation. Pentesters see the relationships between them. They find paths an attacker would actually follow, not just items on a checklist.

This is why there is no such thing as an “automated penetration test.” Tools like Nessus or OpenVAS are scanners. They are helpful for hygiene but not for security validation. If a company tells you they provide automated pentesting, what they’re really offering is a scan with a marketing wrapper.

If you want more insight into the difference, check out our guide: Penetration Testing Firms: 10 Red Flags Every Business Should Know. It breaks down what real testing looks like, and how to avoid paying for a report that doesn’t actually help.

A scanner might give you a list. A manual penetration test gives you proof, context, and clear guidance to reduce risk. That is exactly what you need if you want to prevent ransomware and stop attackers before they get inside.

How Would You Know If Your Network Was at Risk?

Most companies think they’re doing fine until something breaks. But in many environments, attackers are able to move freely not because the network is wide open, but because the right tests were never done to expose what’s quietly misconfigured or forgotten.

If you haven’t tested your internal network with a manual penetration test, the truth is that you likely don’t know how exposed you are. Most environments don’t generate alerts when Kerberoasting happens. Many still allow VPN access without enforcing multi-factor authentication. And far too many service accounts have not had their passwords changed in years.

Here are a few examples of the kinds of findings that might show up in a strong internal pentest report. The image below is a sample excerpt from a real-world report format showing a variety of risks.

These are not rare. We see them constantly, even in organizations with decent external security posture. And attackers know that once they are inside, these gaps often go unnoticed.

A real internal pentest checks for exactly these risks. We look at account hygiene, privilege assignments, network structure, and monitoring. More importantly, we don’t just check for these issues, we attempt to use them the same way an attacker would. If we can compromise a service account or move laterally to a domain controller, you’ll know about it in the report.

Knowing your risk means not guessing. It means validating your controls from the inside, just like ransomware groups do. That is what a proper penetration test provides.

What Would a Good Pentest Report Actually Show You?

A good penetration test report does more than list problems. It tells a story. It shows how a real attacker could move through your environment, where they would start, what they would find, and how far they could go.

This kind of report is built on real attack paths, not guesses or theoretical issues. If we find a service account that can be Kerberoasted and cracked, we document it. If that cracked account gives us local admin rights on multiple machines, we show how that access can be used to pivot deeper into the network.

Here are a few examples of the kinds of findings that might show up in a strong internal pentest report:

A weak service account password that allowed offline cracking in under 12 hours
A VPN portal without multi-factor authentication that accepted simple credentials
A lack of alerting on lateral movement, such as PsExec or remote desktop activity across high-value systems

But the value is not just in identifying problems. The report should tell you exactly what to do next. That includes:

Which accounts to rotate or decommission
How to enforce stronger encryption and password policies
Where to improve segmentation or privilege boundaries
What types of monitoring and logging to enable or tighten

Findings are prioritized by risk and ease of exploitation. You’ll know what needs to be fixed right away versus what can be scheduled for future hardening.

This is how you translate security testing into meaningful outcomes. You’re not just checking a box. You’re giving your team a focused list of actions that directly reduce the risk of a ransomware event. A good pentest report does not just diagnose the issues, it gives you a plan to protect the business.

Can a Pentest Really Stop a Breach from Happening?

A penetration test cannot guarantee you will never be breached. But it can stop most attacks before they start, especially the ones that rely on common missteps like weak passwords, poor segmentation, or unmonitored lateral movement.

Most ransomware cases do not involve advanced exploits. They succeed because nobody was looking internally. A good pentest fixes that. It simulates the attacker’s perspective inside your environment and shows you what would happen if someone got in.

When we run a manual internal pentest, we simulate the exact steps a ransomware operator would take. We look for vulnerable service accounts, test privilege escalation paths, attempt Kerberoasting, and try to move laterally. Each step tests whether real-world attack paths like Kerberoasting or lateral movement are possible in your network right now.

If we can find it, so can they. The difference is that we give you a chance to fix it first.

That is the point of a good penetration test. It is not just about finding flaws. It is about showing how to prevent those flaws from becoming the reason your business ends up in the news.

Don’t Wait for a Breach to Learn Where You're Exposed

If attackers can get Domain Admin starting from a low-privilege account and a service ticket, the real question is: have you tested whether they could do it in your environment?

At Artifice Security, we simulate real ransomware attack paths from Kerberoasting and lateral movement to privilege escalation and exfiltration. We test safely, manually, and give you clear steps to fix what matters before it’s exploited.

If you're relying on scans, you're not testing the same way attackers operate.

Let’s find the gaps before someone else does.

📧 contact@artificesecurity.com
📞 720-515-1337
🔗 artificesecurity.com

About the Author

FAQ

Can a penetration test prevent ransomware?
Yes. A penetration test can help prevent ransomware by identifying and simulating the same internal weaknesses that attackers rely on. That includes weak service account passwords, poor network segmentation, and missing multi-factor authentication. A good pentest reveals these issues before someone else uses them against you.

What is Kerberoasting in Active Directory?
Kerberoasting is a technique where an attacker with a valid domain user account requests encrypted service tickets from Active Directory. These tickets can be cracked offline to recover service account passwords. If those accounts have high privileges, the attacker can escalate access quickly.

Are vulnerability scans the same as penetration tests?
No. Vulnerability scans identify known issues using automated tools. A penetration test uses human logic to chain misconfigurations together and simulate how an attacker would exploit them. If your provider only delivers a scan report or claims to offer “automated penetration testing,” you’re likely not getting a real pentest.

How do attackers move laterally in a network?
Lateral movement happens when an attacker uses one compromised account or system to access others. They often rely on local admin rights, cached credentials, or misconfigured permissions to hop from machine to machine, getting closer to high-value targets like domain controllers.

What does a good pentest report include?
A strong report shows you exactly how far the tester got, what weaknesses were used, and what to fix first. It includes cracked credentials, privilege escalation paths, lateral movement risks, and prioritized remediation guidance.

Penetration Testing Firms: 10 Red Flags Every Business Should Know

Jason — Fri, 30 May 2025 20:32:54 +0000

Why You Shouldn’t Trust Penetration Testing Firms Without Asking These Questions

When you pick a penetration testing firm, the biggest red flags are the ones that signal you are paying for theater instead of real validation. Be wary of any firm that won’t describe its testing methodology in plain language, refuses to define exactly what “penetration testing” includes, or can’t explain how it separates manual exploitation from automated scanning. Watch for vague scopes (“we’ll test everything”), pricing that looks too good to be true without a clear breakdown of time and effort, and proposals that focus on deliverables like “a big report” rather than outcomes like verified impact, reproducible evidence, and practical fixes. Credibility matters too: if a firm leans heavily on flashy claims instead of verifiable references, won’t name the actual testers assigned to your engagement, won’t commit to rules of engagement and safe-testing boundaries, or won’t offer a retest to confirm fixes, you should assume they won’t stand behind their work. Finally, treat any resistance to basic transparency as a deal-breaker: a legitimate firm will document scope, constraints, data-handling, and reporting expectations up front so there are no surprises for you or your auditors.

Why You Shouldn’t Trust Penetration Testing Firms Without Asking These Questions

The penetration testing market has a quality problem. Some penetration testing firms run disciplined, expert-led engagements that use clear methodology, defined scope, and manual validation to prove real impact. Others sell a “pentest” that looks legitimate on paper but relies heavily on automated scanning, vague claims, and marketing language that does not match what gets delivered. If you can’t tell the difference up front, you can end up with a report that satisfies a checkbox while missing the attack paths that actually matter.

This guide is built for buyers who want to vet penetration testing companies the same way they vet any other high-risk vendor. It focuses on practical due diligence, the questions that credible pen testing firms answer without hesitation, and the warning signs that often show up when a cybersecurity testing firm is more focused on appearance than outcomes. Nothing here requires you to assume bad intent. The point is to help you verify capability, ensure the scope matches your risk, and confirm the firm will stand behind the work with transparent reporting and retesting.

By the end, you’ll know how to spot common red flags, what to ask before you sign a statement of work with a penetration testing provider, and how to avoid pentest vendors that overpromise, underdeliver, or blur the line between scanning and true manual testing. If you’re evaluating penetration testing firms right now, or reconsidering a past engagement, the goal is simple: make sure you’re buying real security testing, not a deliverable that only looks credible.

What you’ll take away:

Why “best penetration testing company” marketing should trigger verification, not trust
How to spot questionable credentials, unclear staffing, and unverifiable claims
What to ask before you sign a pentesting services agreement

Red Flag #1: When Penetration Testing Firms Misrepresent Cybersecurity Certifications

A common way some penetration testing firms try to look more qualified than they are is by listing impressive certifications and displaying certification logos without giving you a clean way to verify who actually holds them. Certifications can matter because they signal baseline training and hands-on skill, but the only thing that truly counts is whether the specific people testing your environment have the experience and credentials the vendor implies. If a penetration testing company makes broad claims like “our team is fully certified” while avoiding names, credential IDs, or verifiable proof, treat that as a serious warning sign.

The fix is simple: verify. Before you sign with any penetration testing provider, ask for the names of the testers assigned to your engagement and request evidence for any certifications the vendor uses as a selling point. Legitimate pen testing firms will not act offended by basic due diligence. They will provide credential details you can confirm directly with the issuing body, and they will explain how those credentials map to the scope you are buying, whether that’s web application testing, internal network testing, cloud configuration review, or a blended assessment. If a cybersecurity testing firm stalls, changes its story, or pushes you to “trust the brand,” you should assume the marketing does not match delivery.

How to protect yourself:

Ask for the full names of the specific testers assigned to your engagement, not just roles or initials.

Request proof of certifications the vendor highlights, including a credential ID or verification link where available.

Verify directly with the issuing body, using official validation tools or support channels.

Be skeptical of generic claims like “fully certified team” with no names or documentation.

Ask for the full names of the specific testers assigned to your engagement, not just roles or initials.
Request proof of certifications the vendor highlights, including a credential ID or verification link where available.
Verify directly with the issuing body, using official validation tools or support channels.
Be skeptical of generic claims like “fully certified team” with no names or documentation.
Prefer penetration testing companies that provide a short tester bio, relevant project experience, and a clear mapping from tester capability to your scope.

Security companies don’t just drop logos on a page and hope you won’t notice. They give you names, resumes, and credentials that you can actually verify. If a vendor stalls or dodges when you ask, walk away.

Verification Links:

Offensive Security, certificate verification support and requests https://help.offsec.com/hc/en-us/requests/new
(ISC)², “Member Verification” page (official way to verify an (ISC)² member) https://www.isc2.org/MemberVerification
GIAC, certification verification (GIAC Certified Professionals directory) https://www.giac.org/certified-professionals/
CompTIA, certification verification (CertMetrics login and verification workflows) https://www.certmetrics.com/comptia/
CREST, find a member company (for verifying CREST member organizations) https://www.crest-approved.org/members/

Red Flag #2: When Pentesting Companies Hint at Government Ties Without Proof

Some penetration testing firms try to boost credibility by implying they have government relationships or “agency-level” affiliations. You’ll see this when a vendor uses federal logos, name-drops government teams, or leans on vague language like “trusted by government” without giving you anything you can independently confirm. That kind of marketing is meant to shortcut your due diligence. In reality, legitimate federal work leaves a paper trail: the company can point to contract vehicles, award records, or other verifiable artifacts. If a penetration testing company won’t provide that level of clarity, treat the claim as unproven and evaluate them on what you can actually verify, such as tester qualifications, methodology, deliverables, and references you can contact.

How to protect yourself:

Ask for specifics: contract name, agency, time period, and whether the work was prime or subcontract.
Verify claims using official government award databases rather than screenshots or logos.
Be cautious with vague references to incident response teams or programs. Names get used loosely in marketing, and “CERT” can refer to an organization, not a certification.
Prefer penetration testing providers who prove credibility through transparent scope, named testers, and reproducible technical evidence, not implied prestige.

Reference and Verification Links:

USAspending.gov, official open data source for federal spending and awards https://www.usaspending.gov/
USAspending.gov, award search (find contracts and recipients) https://www.usaspending.gov/search
System for Award Management (SAM.gov), official U.S. government site for entity registration and contractor records https://sam.gov/
SAM.gov, entity registration and Unique Entity ID (UEI) getting started https://sam.gov/entity-registration
CISA alert, “US-CERT and ICS-CERT Transition to CISA” (explains status and consolidation of those brands) https://www.cisa.gov/news-events/alerts/2023/02/24/us-cert-and-ics-cert-transition-cisa
CISA, Industrial Control Systems topic page (how CISA frames ICS cybersecurity work and resources) https://www.cisa.gov/topics/industrial-control-systems

Red Flag #3: When Penetration Testing Firms Crown Themselves “#1”

Be skeptical any time penetration testing firms claim they are “#1” based on a ranking they published themselves or on a list that has unclear ownership, unclear criteria, or paid placement. Self-published “Top 10 penetration testing companies” posts can look like independent research, but they are often just marketing content designed to shape perception and capture search traffic. That does not automatically mean the vendor is incompetent, but it does mean you should treat the claim as unverified until you can validate it through objective evidence.

Instead of trusting rankings, evaluate penetration testing companies using signals you can check. Do they publish a clear methodology and rules of engagement? Will they name the testers assigned to your engagement and provide verifiable credentials? Can they provide references you can contact, and sample report sections that demonstrate real exploitation evidence rather than generic scanner output? Do they define scope and limitations precisely, and do they offer retesting to confirm fixes? The strongest penetration testing providers win work because they produce repeatable outcomes and clear documentation, not because they self-award trophies in blog posts.

What to check before trusting any “best penetration testing company” claim:

Does the vendor rely on measurable proof of capability (methodology, staff, references, sample deliverables) rather than slogans?
Who published the ranking, and is the publisher independent from the vendors listed?
Are the evaluation criteria public, objective, and consistently applied?
Is there evidence of real recognition, such as peer-reviewed awards, independent analyst reports, or reputable industry programs?

Reference Links:

FTC, Endorsement Guides (rules and expectations around endorsements, testimonials, and disclosures) https://www.ftc.gov/business-guidance/advertising-marketing/endorsements-influencers-reviews
FTC, Guides Concerning the Use of Endorsements and Testimonials in Advertising (16 CFR Part 255) https://www.ecfr.gov/current/title-16/chapter-I/subchapter-B/part-255
FTC, “Native Advertising: A Guide for Businesses” (disclosures when ads resemble editorial content) https://www.ftc.gov/business-guidance/resources/native-advertising-guide-businesses

Red Flag #4: When Penetration Testing Firms Misrepresent Team Size and Staffing

Some penetration testing firms market themselves as having a large bench of “full-time senior experts” when the reality is much smaller or heavily contractor-based. A lean team is not a problem. Many excellent penetration testing companies stay small on purpose because it keeps quality high and accountability clear. The red flag is when a vendor’s headcount claims do not match who will actually perform the work, how they staff engagements, and what capacity they can realistically deliver within your timeline.

This matters because staffing impacts outcomes. If a penetration testing provider oversells its team size, you may end up with testers you were not told about, last-minute subcontractors with unknown quality, or schedule pressure that pushes the engagement toward automated scanning instead of manual validation. The safest approach is to treat staffing as part of scope. You are not just buying a report. You are buying named expertise, time-on-target, and the ability to support remediation and retesting.

Here’s how to check:

Ask who will perform the testing and who will write the report, including names and roles.
Ask whether testers are employees or subcontractors, and whether any work will be outsourced.
Request short bios or resumes for assigned testers and confirm relevant experience for your environment (cloud, web apps, internal network, AD, OT, etc.).
Put staffing expectations in the statement of work (named testers or at least minimum qualifications, substitution rules, and notice requirements).

Reference Links:

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (planning, staffing, and conducting security testing) https://csrc.nist.gov/pubs/sp/800/115/final
OWASP Web Security Testing Guide (WSTG), methodology benchmark for web application testing https://owasp.org/www-project-web-security-testing-guide/
CREST, professional standards and guidance for penetration testing (credentialing and quality signals) https://www.crest-approved.org/

Red Flag #5: When Security Testing Companies Aren’t Transparent About Who Will Do the Work

Some penetration testing firms present themselves as strictly “in-house” while staffing engagements with subcontractors or external testers that the client never approved or even knew were involved. Using contractors is not inherently bad. Many reputable penetration testing companies use them for niche expertise or to meet scheduling demands. The red flag is a lack of transparency. If a pentesting company markets “no outsourcing” or implies only employees will access your systems, but then assigns work to third parties without clear disclosure and controls, you should treat that as a serious governance and risk issue.

This matters because staffing directly affects confidentiality, access control, and accountability. You are granting a security testing provider privileged visibility into your environment, sometimes including internal credentials, sensitive data, or production-like systems. You need to know who will access what, where they are located, and what contractual and technical safeguards apply. High-quality penetration testing firms handle this cleanly: they disclose whether testers are employees or subcontractors, restrict access to least privilege, document data-handling rules, and put the staffing and location constraints in writing.

How to protect yourself:

Ask for the names and roles of the people who will access your systems and produce the report.
Require disclosure of subcontractors and require written client approval before any third party participates.
Confirm where testing will be performed (country/region) and whether any data will leave your environment.
Ensure the statement of work covers confidentiality, access controls, and data handling, including retention and secure deletion.
If your requirements include “U.S.-only personnel” or “no offshore access,” put it explicitly in the contract.

Reference Links:

NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information (useful for contractor access expectations, access control, and system security requirements) https://csrc.nist.gov/pubs/sp/800/171/r2/final
NIST SP 800-53 Rev. 5, Security and Privacy Controls (baseline controls relevant to third-party access, access control, and confidentiality) https://csrc.nist.gov/pubs/sp/800/53/r5/final
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (planning and controls around security testing activities) https://csrc.nist.gov/pubs/sp/800/115/final

Red Flag #6: When Pentest Companies Fake Reviews

Testimonials can help you shortlist penetration testing firms, but they are also easy to manipulate. The red flag is not “a vendor has reviews.” It’s when the reviews are vague, unattributed, or impossible to verify, especially when the vendor uses them as a primary credibility signal. In security testing, trust matters because you may be granting deep access to internal systems and sensitive data. If a penetration testing company relies on anonymous praise, generic quotes, or claims that do not connect to real, verifiable work, you should treat that as a cue to dig deeper before you engage.

A credible penetration testing provider should be able to back up marketing claims with something concrete: a reference you can contact (under NDA if needed), a case study that explains scope and outcomes without hype, and a report style that demonstrates real testing rather than copy-paste language. You do not need public logos or flashy quotes to make a good hiring decision. You need evidence that the firm does the work they claim, documents it properly, and stands behind it.

How to spot questionable testimonials:

No full names, companies, or roles, and no way to verify the source.
“Case studies” that read like ads instead of describing scope, constraints, and measurable outcomes.
Quotes praising capabilities the vendor does not clearly offer elsewhere.
Repeated generic phrasing with no attribution (“highly recommended,” “best in the business,” “excellent work”).
Stock photos or generic headshots that appear unrelated to real clients.
References the vendor refuses to enable even privately, such as a customer call under NDA.

Reference Links:

FTC, Endorsement Guides overview (endorsements, influencers, and reviews) (https://www.ftc.gov/business-guidance/advertising-marketing/endorsements-influencers-reviews)
FTC, Guides Concerning the Use of Endorsements and Testimonials in Advertising (16 CFR Part 255) https://www.ecfr.gov/current/title-16/chapter-I/subchapter-B/part-255
FTC, “Native Advertising: A Guide for Businesses” (when promotional content resembles independent editorial) https://www.ftc.gov/business-guidance/resources/native-advertising-guide-businesses

Red Flag #7: When Cyber Companies Fake Their Infrastructure

Some cybersecurity vendors describe operational capabilities like a Security Operations Center (SOC), Network Operations Center (NOC), managed detection and response (MDR), or “data center” services in ways that imply a level of infrastructure and staffing they may not actually operate themselves. Sometimes those capabilities are real and in-house. Other times they are partner-delivered, limited in scope, or described with marketing language that blurs what you are truly buying. The red flag is not that a vendor relies on partners or runs lean operations. The red flag is when the vendor cannot clearly explain what exists, who runs it, what coverage looks like, and what evidence you will receive as a customer.

If you are evaluating penetration testing firms, keep one thing straight: a strong penetration test does not require the vendor to run a SOC or a NOC. What matters is tester capability, a clear methodology, disciplined rules of engagement, safe execution, and reporting that proves real impact. When a vendor uses operational buzzwords to signal “enterprise readiness,” treat it like any other claim. Ask for definitions, boundaries, and proof, and put the parts you care about into the contract so they are deliverables rather than slogans.

How to protect yourself:

Ask for a plain-language definition of what they mean by “SOC,” “NOC,” “MDR,” and “data center” in their offering.
If they claim 24/7 operations, ask how coverage works (shifts, escalation, staffing levels) and what reports, metrics, or SLAs you receive.
Ask whether the capability is operated in-house or delivered through a partner, and require disclosure of any third parties involved.
Verify the business address and request a high-level staffing summary for relevant roles (for example, SOC analysts, incident responders, NOC engineers).
Put operational claims into the statement of work if they are part of your buying decision.

Reference Links:

NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations https://csrc.nist.gov/publications/detail/sp/800-137/final
NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide (incident response operations that SOC teams commonly support) https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
CISA, National Cyber Incident Response Plan (coordination and operational response context) https://www.cisa.gov/national-cyber-incident-response-plan-ncirp

Red Flag #8: When Penetration Testing Firms Blur Scanning and Real Pentests

Vulnerability scanning plays a real role in a security program. It helps teams find known issues at scale and supports patch and configuration management. PTaaS can also be legitimate when it means human-led penetration testing delivered through a platform that improves scheduling, collaboration, evidence sharing, and retesting. The red flag is when penetration testing firms blur those terms and sell automated scanning as if it were a real penetration test. Scans and pentests can complement each other, but they are not interchangeable.

A penetration test requires human judgment: validating findings, proving exploitability, demonstrating impact, and following realistic attack paths that scanners cannot reason about, like authentication abuse, authorization flaws, business logic issues, chaining, and lateral movement. When a vendor markets “automated penetration testing” or uses PTaaS language while avoiding any description of manual testing, assume you are looking at a scanning service unless they can prove otherwise. The goal is not to argue about labels. The goal is to ensure you know what you are buying and whether it matches your risk and compliance needs.

How to tell when you are being sold a scan rather than a pentest:

The report has no proof of exploitation: screenshots, request and response evidence, payloads, or clear reproduction steps.
Findings are mostly generic CVE summaries and CVSS scores with little environment-specific context.
There is no attack narrative: no chaining, no privilege escalation pathing, no lateral movement discussion where applicable.
Web findings lack business logic testing, authorization testing, and application-specific abuse cases.
The report reads like raw scanner output with branding rather than a tester-written assessment.

What to ask before you sign:

Will you retest high and critical fixes, and what does retesting include?
How much time is allocated for manual testing versus scanning?
What methodology do you follow, and what does “manual validation” mean in your process?
What evidence will be included in the report to prove impact?
Reference Links:
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment https://csrc.nist.gov/pubs/sp/800/115/final
OWASP Web Security Testing Guide (WSTG), methodology benchmark for web application security testing https://owasp.org/www-project-web-security-testing-guide/
PCI Security Standards Council, Penetration Testing Guidance (Information Supplement) https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf

Red Flag #9: When a Penetration Testing Firm Uses Legal Threats Instead of Transparency

Disputes happen in every industry. A professional penetration testing firm can have a disagreement with a former employee, a competitor, or a customer without it meaning anything about the quality of their work. The red flag is when a vendor responds to reasonable questions about scope, methodology, staffing, or deliverables with intimidation tactics, legal threats, or blanket demands for silence instead of straightforward answers. If a company’s first instinct is “lawyer up” rather than “show the evidence,” you should treat that as a governance risk, because it often correlates with poor transparency, weak documentation, and a culture that punishes scrutiny.

This matters to you as the buyer because penetration testing firms may gain access to internal networks, credentials, vulnerability data, and sensitive reports. You want a vendor that behaves predictably under pressure, documents decisions, and resolves issues professionally. If the sales process includes aggressive NDAs before scoping, hostile reactions to basic due diligence, or refusal to provide verifiable proof of claims, it is a sign you should slow down and verify everything through neutral sources, then put your requirements in writing.

How to protect yourself:

Put key expectations in the statement of work: named roles, subcontractor disclosure, data handling, retention, and a clean retest process.
Treat “trust us” responses as a signal to ask for documentation: methodology, sample sanitized report sections, staffing disclosure, and retest process.
If you hear claims about government work, certifications, awards, or major clients, verify them through primary sources rather than marketing.
Check public records for litigation and filings that may affect vendor stability or ownership, especially if the engagement requires long-term access or ongoing retesting.

Reference Links:

PACER, official federal court case search portal (“Find a Case”) https://pacer.uscourts.gov/find-case
PACER Case Locator (nationwide index across federal district, bankruptcy, and appellate courts) https://pcl.uscourts.gov/
U.S. Courts, “Find a Case (PACER)” explainer (what PACER is and what it covers) https://www.uscourts.gov/court-records/find-a-case-pacer
Colorado Judicial Branch, Docket Search (example of an official state judiciary docket search tool) https://www.coloradojudicial.gov/dockets
Colorado Secretary of State, UCC Home (official UCC filing and search entry point) https://www.sos.state.co.us/ucc/
Delaware Division of Corporations, UCC Search information (Delaware’s official guidance) https://corp.delaware.gov/uccsearch/

Red Flag #10: Using NDAs to Limit Normal Buyer Feedback and Accountability

Non-disclosure agreements can be appropriate in security work. You may share network diagrams, credentials, vulnerability details, or incident information, and both sides need clear confidentiality rules. The red flag is when a security testing company uses an NDA (or contract language bundled with it) to go beyond protecting sensitive information and instead restrict normal, truthful feedback, dispute discussions, or professional review. Overbroad non-disparagement clauses, vague “reputation harm” language, or restrictions that chill even private escalation can make it harder for you to hold a vendor accountable if the engagement does not match what was promised.

A healthy contract protects both sides and still leaves room for routine realities: you may need to share findings with auditors, regulators, counsel, insurers, or internal stakeholders; you may need to escalate a quality issue; and you may need to communicate factual concerns to get the work corrected. Strong penetration testing firms do not fear those guardrails. They define confidentiality clearly, specify what data they will collect and retain, outline dispute and remediation processes, and provide a retest path that resolves issues without intimidation.

How to protect yourself:

If something feels off, have counsel review it before you sign, especially if the vendor also asks for early payment or broad limitations on liability.
Read confidentiality and “public statements” clauses carefully, including any non-disparagement language embedded in the SOW, MSA, or NDA.
Ensure the agreement allows you to share necessary information with auditors, counsel, insurers, and regulators, and internally on a need-to-know basis.
Require clear remediation and retesting terms: what happens if the deliverable is late, incomplete, or materially inconsistent with scope.
Push back on vague “reputation harm” triggers or blanket restrictions that prevent factual communication.

Reference Links:

Cornell Law School Legal Information Institute, “Nondisclosure agreement” overview https://www.law.cornell.edu/cfr/text/48/227.7103-7
Cornell Law School Legal Information Institute, “Non-disparagement clause” overview https://www.law.cornell.edu/wex/nondisparagement_clause
FTC, Endorsement Guides (context for truthful reviews and disclosure expectations when endorsements are used in marketing) https://www.ftc.gov/business-guidance/advertising-marketing/endorsements-influencers-reviews

Final Thoughts: Choosing a Pentesting Company You Can Actually Trust

Hiring penetration testing firms is not a normal vendor decision. You are giving an outside team deep visibility into your environment, and sometimes direct access to systems that support revenue, operations, and customer trust. That means your selection process should prioritize competence and transparency over marketing. The goal is simple: choose penetration testing companies that can prove what they do, explain how they do it, and document results in a way you can use for remediation, governance, and audits.

If you are evaluating penetration testing providers, use a verification-first approach. Confirm credentials through the issuing body, validate who will actually perform the work, and insist on a clear methodology that distinguishes manual testing from automated scanning. Ask for a sample sanitized report section so you can see the level of evidence and context you will receive. Put key expectations in writing, including subcontractor disclosure, data handling, retesting, and timelines. Most importantly, pay attention to how the vendor responds to basic due diligence. Trustworthy pen testing firms welcome scrutiny because it matches how they work.

A practical due diligence checklist:

Verify any highlighted certifications using the issuing organization’s official verification tools.
Validate staffing and accountability, including who will test, who will write the report, and whether subcontractors will be involved.
Review the scope and methodology in plain language, including how findings are validated and what evidence the report will include.
Confirm data handling terms: what access is required, what data is retained, how it is protected, and when it is deleted.
Ask about retesting and remediation support so you are not left with a report you cannot operationalize.

The best penetration testing firms do not rely on inflated claims or buzzwords. They set expectations clearly, execute safely, and produce evidence-driven reporting that helps you reduce risk. If you want a second set of eyes on a proposal or scope from a penetration testing vendor, reach out. We can help you sanity-check the engagement so you know you are buying real testing and not a deliverable that only looks convincing.

Book a consultation to review your pentest scope, vendor proposal, or security testing plan.

Click here to book a consultation!

This article is educational and reflects general industry practices and publicly available information. It does not identify or accuse any specific company or individual. Examples are illustrative and are included to help buyers evaluate penetration testing firms using independent verification and documented due diligence.

Originally published at Artifice Security.