There is one question that separates a penetration tester from someone who has simply installed Kali Linux.
It is not: “Which tools do you use?”
It is: “Why did you choose that tool, what are you trying to prove, and what will you do with the result?”
The offensive security ecosystem is now vast, capable and, in many cases, freely available. That accessibility is also the trap. Owning the tooling does not mean knowing how to operate it safely, interpret its output or turn isolated findings into a realistic attack path.
Blaze Information Security’s Annual Penetration Testing Review 2025 analysed 660 assessments across 145 organisations and identified 3,294 confirmed vulnerabilities spanning 206 different CWE categories. Crucially, the dataset came from manual penetration testing and red-team engagements rather than theoretical scanner results or unverified automated findings. (Blaze Information Security)
That distinction matters.
A scanner may report that a particular software version is vulnerable. A penetration tester must determine whether the weakness is genuinely exploitable in that environment, what access it provides, what compensating controls exist and whether it can be combined with other weaknesses to reach something the business actually cares about.
Broken authorisation, business-logic abuse and multi-stage attack paths often emerge only when a person understands how the system is supposed to behave and deliberately tests what happens when those assumptions are violated.
At Hard2bit, tools are used to expand coverage and accelerate repeatable work, but the final judgement remains with specialist security consultants. They validate findings, remove false positives, reproduce vulnerabilities safely, construct realistic attack paths and determine whether a technical weakness translates into meaningful business risk.
This is therefore not another list of the “best hacking tools”. It is a practical journey through the tooling used during a professional engagement: what each tool helps answer, where its limitations lie and what evidence defenders should expect it to leave behind.
For the wider context around objectives, scope and testing models, start with our guide to what penetration testing is and how it works.
How tools fit into a professional penetration test
Tools are not selected because they are fashionable. They are selected according to the stage of the assessment and the hypothesis being tested.
Methodologies such as PTES, the OWASP Web Security Testing Guide and NIST SP 800-115 provide useful structure. In practice, however, a pentest is rarely a rigid sequence of automated tasks.
The tester begins by mapping the exposed attack surface, identifies live systems and technologies, enumerates their behaviour, validates potential weaknesses manually and—where authorised—demonstrates exploitation, privilege escalation and lateral movement.
The engagement is complete only when the tester can explain, with reproducible evidence, which attack paths were possible, which assets were at risk and which controls should be improved first.
Running Nmap is not a methodology. Nmap provides observations. The value lies in knowing what question to ask next.
1. Reconnaissance and OSINT: rebuilding the external attack surface
Before sending direct traffic to a target, testers often reconstruct what an attacker can learn from public and third-party sources.
The aim is not merely to find an open port. It is to understand the organisation’s visible footprint: domains, subdomains, IP ranges, exposed services, cloud infrastructure, repositories, forgotten environments, suppliers and leaked credentials.
Much of this work can be performed passively, without touching the organisation’s systems. As a result, a significant part of reconnaissance may never appear in the target’s internal logs.
Amass, Subfinder and certificate transparency
OWASP Amass and ProjectDiscovery’s Subfinder collect subdomains from DNS data, search engines, historical records, APIs and certificate-transparency sources.
Certificate Transparency services such as crt.sh are particularly useful because public TLS certificates often reveal systems that are no longer linked from the corporate website. Development environments, old portals, migration systems and forgotten regional services can all surface in certificate history.
The output still requires human validation. A historical hostname may no longer resolve, may belong to a supplier or may fall outside the agreed scope. The tester must confirm ownership, current resolution and relevance before proceeding.
dnsx, httpx and naabu
ProjectDiscovery’s tooling is useful when reconnaissance produces thousands of potential assets.
dnsx resolves and validates DNS records. httpx determines which HTTP and HTTPS services are alive and extracts useful metadata. naabu performs efficient port discovery.
These tools are not conclusions in themselves. Their role is to reduce a large, uncertain dataset into a smaller group of assets suitable for deeper investigation.
Shodan, Censys and FOFA
Shodan, Censys and FOFA index internet-accessible services and allow testers to search by certificates, banners, products, ports, ASN, page titles and even favicon hashes.
They are valuable for locating management interfaces, cloud-hosted systems and infrastructure that does not appear in the official inventory.
Their information may be historical, however. A service appearing in a search index does not prove that it remains accessible today. The finding must be validated against the live environment and the agreed test scope.
TruffleHog and Gitleaks
TruffleHog and Gitleaks search repositories, commit history and other sources for potential secrets such as API keys, cloud credentials, private keys, connection strings and access tokens.
A pattern match does not prove that a credential remains active. Testing its validity may also create audit events or affect a live service. Any such validation must be explicitly authorised in the rules of engagement and performed with restraint.
Hard2bit Scanner: initial visibility into the exposed attack surface
Alongside third-party tooling, Hard2bit also uses proprietary technology to accelerate the early stages of reconnaissance and external exposure analysis.
Hard2bit Scanner performs a passive, non-intrusive assessment of a domain’s public security posture. It reviews areas such as TLS, DNS, HTTP security headers, exposed technologies, email security configuration, subdomains, certificates, cookies, security.txt, robots.txt and other signals visible from the internet.
It helps identify likely areas of interest, inconsistencies and exposed assets that should then be reviewed by an analyst.
It is a good example of how automation should be used: to expand coverage and reduce repetitive work so that specialists can focus on manual validation, attack chaining and real-world impact.
What this stage actually validates
Reconnaissance measures the gap between the organisation’s official inventory and its real external attack surface.
It is the same foundation used in attack surface management, although a pentest uses the information to guide adversarial testing within an agreed time window.
Because passive OSINT is difficult for the target to observe, the most effective defence is not to rely on detecting it. It is to reduce what can be discovered by removing abandoned services, cleaning up stale DNS, reviewing certificate issuance, protecting source repositories and rotating exposed secrets before an attacker finds them.
2. Scanning and enumeration: moving from “what exists?” to “how does it behave?”
Once the attack surface has been scoped, the tester begins interacting with assets to identify hosts, ports, protocols, software and configuration details.
Scanning and enumeration are related but different. Scanning provides breadth and identifies candidates. Enumeration goes deeper into a particular host or service.
This distinction is similar to the difference between vulnerability scanning and vulnerability management: one produces technical observations, while the other requires validation, context, prioritisation and follow-through.
Nmap
Nmap remains the reference tool for host discovery, TCP and UDP scanning, service identification, approximate version detection and NSE scripting.
Options such as -sV can help identify services, but banners should never be accepted uncritically. Services may suppress, alter or deliberately falsify version information.
The Nmap Scripting Engine enables precise enumeration and security checks, but indiscriminately launching broad script categories can create unnecessary traffic, trigger defensive controls or affect fragile services.
The skill is not in memorising switches. It is in interpreting the response and choosing the next safe and relevant test.
Masscan and Naabu
Masscan and Naabu are useful when the authorised scope contains large address ranges or significant numbers of assets.
They are commonly used as an initial filter. Interesting ports are then validated and examined in greater depth with Nmap or protocol-specific tools.
Scan rates must be adapted to the environment. An aggressive scan can saturate links, overwhelm legacy systems, trigger rate limits or distort the assessment by causing services to behave abnormally.
Nuclei
Nuclei runs template-based checks for known exposures, vulnerable products and common misconfigurations.
It is particularly useful for testing a large number of assets, checking for a specific CVE, locating exposed panels and repeating targeted controls during a retest.
Its findings depend on the quality, relevance and freshness of the templates being used. A match requires validation. A lack of matches does not demonstrate that the system is secure.
Nessus, Greenbone/OpenVAS and Qualys
Enterprise vulnerability scanners provide systematic coverage of missing patches, vulnerable versions, weak cryptography, obsolete software and configuration problems.
The distinction between authenticated and unauthenticated scanning is critical. An unauthenticated scan shows what an external or low-trust actor can observe. An authenticated scan can inspect installed software, patch levels and local configuration in much greater depth.
Neither should be treated as a final verdict.
Scanners can produce false positives, duplicated findings and severity ratings that ignore environmental context. They can also miss vulnerabilities for which no plugin exists, weaknesses hidden behind application logic and problems that only become exploitable when combined.
At Hard2bit, automated results are reviewed before they enter the final report. A finding is not accepted merely because a tool reported it. It must be confirmed, understood in context and, where safe and necessary, reproduced.
That is why effective vulnerability management requires technical validation, risk-based prioritisation and remediation tracking rather than a scanner export.
Wireshark and tshark: seeing what is really happening
Wireshark and its command-line counterpart, tshark, are cross-cutting tools rather than products tied to a single assessment phase.
They allow testers to inspect protocol exchanges, TLS negotiations, authentication flows, retransmissions, clear-text traffic, unexpected responses and differences between what an automated tool claims happened and what actually crossed the network.
Wireshark often does not discover the vulnerability by itself. Instead, it explains why a technique works, reveals what information is being transmitted or disproves an incorrect conclusion produced elsewhere.
What defenders should expect to see
Fast scanning normally leaves evidence in firewalls, IDS or IPS platforms, NetFlow, WAF logs and individual service logs.
That does not make reconnaissance easy to detect in every case. An attacker can slow the rate, distribute requests across infrastructure or imitate normal client behaviour.
The absence of an obvious scanning alert does not mean that nobody is mapping the environment.
3. Web applications and APIs: where context overtakes automation
Web applications and APIs are where the difference between tooling and judgement becomes particularly visible.
Automation is effective at recognising familiar patterns, but many high-impact weaknesses depend on context: broken horizontal or vertical authorisation, IDOR or BOLA, workflow abuse, race conditions, unsafe state transitions and insufficient tenant isolation.
The OWASP Top 10:2025 retains Broken Access Control as its leading category and introduces Software Supply Chain Failures as a distinct category, reflecting both the persistence of authorisation weaknesses and the growing importance of build and dependency risk. (OWASP)
Burp Suite Professional
Burp Suite remains the primary interception proxy in many professional web assessments.
Proxy captures and modifies traffic. Repeater allows a tester to replay requests with controlled changes. Intruder supports targeted fuzzing. Sequencer assesses token characteristics. Collaborator identifies out-of-band interactions associated with vulnerabilities such as blind SSRF and blind XXE.
The BApp ecosystem adds further capabilities. Autorize can help compare the behaviour of different user roles. JWT Editor assists with token analysis. Param Miner searches for hidden parameters, while Logger++ improves traffic logging and investigation.
These extensions highlight differences. They do not determine whether those differences constitute exploitable vulnerabilities. That decision still requires an analyst who understands the application.
Caido
Caido is a modern interception proxy aimed at manual security testing, with responsive project management, workflow automation and a growing plugin ecosystem.
It has become a credible alternative for penetration testers and bug-bounty researchers who value a lighter working environment.
Burp still offers a particularly mature ecosystem of extensions, training materials and integrated functionality. The sensible choice depends on the engagement and the tester’s workflow rather than on declaring one product universally superior.
OWASP ZAP
OWASP ZAP is an open-source proxy and dynamic application security testing platform.
It is useful for repeatable testing, CI/CD integration, authenticated scanning and controlled checks against pre-production environments.
Active scanning must nevertheless be configured carefully. Some checks create records, alter application state or generate significant load.
ffuf, Feroxbuster and sqlmap
ffuf and Feroxbuster discover directories, files, endpoints, parameters, virtual hosts and routes that are not linked from the visible application.
Their usefulness depends more on relevant wordlists, filtering and application knowledge than on launching a generic directory list.
sqlmap automates the identification and exploitation of SQL injection. It can efficiently validate whether a suspected injection is real, but some options can retrieve large quantities of data, change records, execute operating-system commands or place stress on the database.
In many professional engagements, a minimal and controlled proof is enough. The goal is to demonstrate impact, not extract everything the vulnerability could theoretically expose.
mitmproxy and API-specific tooling
mitmproxy is particularly useful when testers need to transform, automate or analyse HTTP traffic programmatically.
API testing also draws on OpenAPI specifications, clients such as Postman or Bruno, GraphQL tooling, JWT analysers, gRPC clients and scripts written specifically for the target.
The most important tool is often not software at all. It is the authorisation model built by the tester: which roles should be able to perform each action, against which objects and under which business conditions.
Where manual analysis creates the real value
This is one of the areas in which an experienced testing team contributes most.
Tools can identify unusual parameters, inconsistent responses and suspicious behaviour. Only a tester who understands the application’s roles, workflows and commercial logic can determine whether the issue is genuinely exploitable and how far the abuse can go.
At Hard2bit, automation provides broad coverage. Authorisation testing, business-logic analysis, attack chaining and workflow abuse are performed manually.
A meaningful web or API assessment must answer questions that a scanner cannot resolve:
Can one customer access another customer’s data? Can a read-only user alter an object? Can an approval stage be skipped? Can a discount or token be reused? Can a server-side price be manipulated? Can a legitimate function be abused to produce an unintended outcome?
This is why a web application security assessment or API security assessment must combine automation, manual testing and knowledge of the underlying business process.
A WAF can block known payloads. It cannot decide whether a legitimate operation should have been authorised for that specific user and object.
4. Exploitation: demonstrating impact without creating an incident
Exploitation during a professional pentest is not about causing damage.
It is about demonstrating, within the agreed rules, that a weakness is real, what level of access it provides, which assets become exposed and whether it can be combined with other weaknesses.
The governing principle should be minimum necessary proof: demonstrate enough to establish impact without creating avoidable operational risk.
SearchSploit and Exploit-DB
Exploit-DB and SearchSploit help testers find publicly available proof-of-concept code.
Public code should never be executed blindly against production. It must first be reviewed to determine what it changes, which dependencies it installs, whether it communicates externally, whether it contains harmful functionality and whether it may cause denial of service.
The existence of a public exploit does not mean it is safe, reliable or applicable to the exact target.
Metasploit Framework
Metasploit provides modules for exploitation, enumeration, payload generation, post-exploitation, pivoting and session management.
Its main value in a penetration test is reproducibility. It can validate certain impacts in a structured way and record precisely how a module was configured.
It does not remove the need for expertise. The operator must still verify the target version, understand the prerequisites and evaluate the likely consequences.
Command-and-control frameworks
Advanced engagements may use command-and-control platforms such as Cobalt Strike, Sliver, Mythic, Havoc or AdaptixC2.
These platforms manage agents, communications, tasking, pivoting and post-exploitation. The same products or open-source frameworks also appear in genuine intrusions, which means defenders may have detections for known payloads, infrastructure patterns and default configurations.
Not every penetration test requires a C2 platform. They are more relevant to adversary simulation and red-team exercises where the detection and response capability is itself part of the test.
What defenders should detect
This stage may generate evidence in EDR and XDR platforms, AMSI, Sysmon, PowerShell logging, DNS, proxies, firewalls, NDR and SIEM systems.
TLS fingerprints, beacon regularity, process behaviour, parent-child relationships and destination infrastructure can all contribute useful signals.
No single signal should be treated as conclusive. JA3 and JARM, for example, can provide context but may be shared by legitimate software, altered by an attacker or changed by modern TLS implementations.
A threat-hunting service looks for combinations of weak signals that have not already triggered a deterministic alert.
A red-team engagement goes beyond confirming that a vulnerability exists. It tests whether the organisation can observe, investigate and contain an attack path.
5. Active Directory and identity: the enterprise attack graph
Up to this point, many tests focus on individual services, applications or configurations. Active Directory changes the nature of the problem.
The greatest risk is rarely one isolated vulnerability. It is the accumulated interaction between identities, permissions, sessions, delegation and trust relationships.
In many organisations, the route to high privilege does not depend on an unpatched critical CVE. It depends on years of inherited access, misconfigured groups, service accounts, legacy protocols and poorly governed certificate services.
BloodHound Community Edition
BloodHound CE represents accounts, computers, groups, sessions and permissions as a graph.
SharpHound collects information from Active Directory, while AzureHound gathers relationships from Microsoft Entra ID.
BloodHound does not “hack the domain”. It reveals paths of control and converts thousands of difficult-to-interpret relationships into routes that testers and defenders can analyse.
The important question is not merely whether a risky relationship exists. It is whether a compromised user or device can reach that relationship from the tester’s current position and use it to progress towards a high-value asset.
NetExec
NetExec is the actively maintained successor to CrackMapExec.
It supports structured testing across protocols such as SMB, WinRM, LDAP, MSSQL, SSH and RDP. Testers use it to validate credentials, enumerate systems and perform authorised actions across multiple hosts.
Care is essential. A poorly planned credential test can lock accounts or resemble a real password-spraying attack.
Impacket
Impacket contains protocol implementations and a broad collection of scripts used in Windows and Active Directory assessments.
GetUserSPNs.py can request Kerberos service tickets associated with SPN-enabled accounts. GetNPUsers.py identifies users without Kerberos pre-authentication. secretsdump.py retrieves credential material where sufficient access is available. ntlmrelayx.py supports the controlled validation of NTLM relay exposure.
Other scripts such as psexec.py, wmiexec.py and smbexec.py provide different forms of remote execution.
These are powerful capabilities. They must remain within the approved scope and be operated with awareness of their impact.
Responder, Rubeus, Certipy and Kerbrute
Responder examines and, when authorised, responds to name-resolution protocols such as LLMNR, NBT-NS and mDNS. It can demonstrate the risk created by automatic NTLM authentication and relayable credentials.
Rubeus groups a range of Kerberos techniques. Certipy identifies and validates weaknesses in Active Directory Certificate Services. Kerbrute supports controlled Kerberos-based user and password testing.
The tool may identify a potentially dangerous condition, but exploitation still depends on reachability, permissions, enrolment rights and the attacker’s starting position.
PingCastle and Purple Knight
PingCastle and Purple Knight focus more heavily on posture assessment than exploitation.
They help identify legacy protocols, privileged-account problems, unsafe delegation, dangerous settings and general directory hygiene weaknesses.
They are valuable baselining tools, but they do not replace manual analysis of actual attack paths.
The chain matters more than the isolated finding
A tool may report that an account holds excessive permissions or that a certificate template appears unsafe.
The tester must establish whether the permission is reachable from the current foothold, what access is required, whether the route leads to a critical asset and which controls could interrupt it.
Hard2bit’s approach is to validate real attack paths rather than provide a list of theoretical directory findings.
The objective is to show how far an attacker could travel from a specific compromised account, workstation or initial entry point.
Detection in Active Directory
Offensive activity may leave evidence in LDAP queries, Kerberos ticket requests, NTLM authentication, service creation, remote administration, privileged-group changes and certificate requests.
Windows event 4769 using RC4 can be useful in some Kerberoasting detections, particularly where the service would normally use AES. It is not conclusive: legacy compatibility may still require RC4, and attackers can request AES tickets.
Detection should combine account behaviour, request volume, source device, SPN and historical baseline.
Instrumented decoy identities can create useful signals, but they do not automatically detect every BloodHound collection method.
For a deeper look at these attack paths, see our analysis of hybrid Active Directory attacks, Kerberoasting and AD CS.
MITRE ATT&CK provides a common language for mapping these offensive techniques to detection opportunities and defensive controls.
6. Passwords and offline cracking
Many identity attack paths produce hashes or other cryptographic material that can be tested offline.
In this scenario, there is no online account lockout and no repeated interaction with the production service. Resistance depends on the algorithm, computational cost, password length and—most importantly—predictability.
Hashcat and John the Ripper
Hashcat is the reference tool for GPU-accelerated password recovery.
Its value is not limited to testing millions of random combinations. Masks, mutation rules, hybrid attacks and targeted dictionaries model the way people actually construct passwords.
John the Ripper supports a wide range of formats and complements Hashcat particularly well when identifying hashes, converting files or processing protected documents and archives.
Dictionaries and organisational patterns
rockyou.txt is widely known, but a generic wordlist is often less effective than one built around the target organisation.
During an authorised assessment, candidate generation may incorporate company names, brands, products, locations, seasons, years and previously observed naming conventions.
The purpose is not necessarily to recover every password. It is to establish whether password practices expose high-impact accounts and whether written policies reflect reality.
What this stage validates
Offline testing measures real password strength, reuse, predictable organisational patterns and the exposure created by service accounts.
Effective controls include longer passwords, password managers, breached-password blocking, managed service accounts and the removal of weak storage or authentication protocols.
7. Wireless, mobile, cloud and Kubernetes
The methodology and tooling must change when the technology changes.
The techniques used against a web application cannot simply be copied onto a wireless network, a mobile application or a cloud platform. Specialist value also lies in choosing the right model for each surface rather than applying the same toolkit to every engagement.
Wireless security
Wireless assessments commonly use tools such as aircrack-ng, hcxdumptool, hcxtools, Wireshark and EAPHammer.
They support testing of WPA2 and WPA3, enterprise 802.1X deployments, EAP methods, client isolation, guest networks, segmentation and rogue access-point scenarios.
Capturing a PMKID does not mean the underlying password can be recovered. The actual impact depends on password strength and the wider wireless configuration.
These activities form part of a professional Wi-Fi security assessment.
Mobile applications
MobSF provides static and dynamic mobile analysis. Frida and Objection instrument applications at runtime. jadx, apktool and Ghidra support code inspection and reverse engineering.
Together, these tools help examine local storage, embedded secrets, certificate validation, communications, authentication, authorisation and anti-tampering controls.
Bypassing a local mobile control does not automatically produce business impact if the backend applies effective server-side enforcement.
A complete mobile application security assessment must therefore connect the mobile client, its APIs and the identity layer.
Cloud and identity
Cloud assessments may use Prowler, ScoutSuite, Steampipe, Pacu, CloudFox, ROADtools, AzureHound, Monkey365 and MicroBurst.
These tools help analyse configurations, identities, public resources, logging, roles and possible privilege-escalation paths.
A cloud posture report is not the same as a cloud penetration test. Reporting that a role contains an overly broad permission is different from proving how that permission can be combined with a managed identity, function or resource to create real impact.
Containers and Kubernetes
Container and Kubernetes environments introduce their own tooling, including Trivy, Kubescape, kube-bench, kube-hunter, Peirates and native clients such as kubectl.
They assist with vulnerable-image detection, benchmark checking, RBAC review, service-account analysis, secret exposure, admission controls and API Server configuration.
Manual interpretation remains essential.
An apparently broad permission may be low risk inside a genuinely isolated workload, or it may become critical if it allows the workload to read secrets, create privileged pods or assume the cloud identity of the underlying node.
As in Active Directory, Kubernetes risk is often found in a chain of permissions rather than in one isolated setting.
8. Local privilege escalation, pivoting and post-exploitation
Once access to a system has been obtained, the tester must determine what that position enables.
winPEAS, linPEAS and Seatbelt automate local enumeration and identify potential privilege-escalation candidates such as unsafe services, weak permissions, stored credentials, scheduled tasks, writable paths and vulnerable software.
They can produce a great deal of output. Many results are only possibilities. The tester must identify which ones are genuinely exploitable in the specific environment.
When systems beyond the initial network segment must be reached, authorised testers may use Ligolo-ng, Chisel or Proxychains.
Ligolo-ng supports tunnelling into internal networks. Chisel carries tunnels over HTTP or WebSocket. Proxychains routes compatible application traffic through a proxy.
Pivoting must be explicitly authorised. Incorrect routing can send traffic outside the defined scope or affect unrelated systems.
Post-exploitation should answer practical questions: can a compromised workstation reach critical servers? Is segmentation effective? Can credentials be reused? Can the attacker reach backup platforms, hypervisors or administrative networks?
The aim is not to remain hidden indefinitely. It is to establish impact with the minimum intervention needed.
9. Reporting tools: the deliverable is part of the test
The most valuable output of a pentest is not the attacker’s terminal. It is the evidence that allows the organisation to reduce risk.
Platforms such as PlexTrac, Ghostwriter, Dradis, Faraday, AttackForge and SysReptor help organise findings, evidence, affected assets, recommendations and review workflows.
The platform does not guarantee a useful report.
A well-written finding must explain what was observed, how it can be reproduced, which asset is affected, what prerequisites exist, what impact is possible, how the weakness should be fixed and how the correction can be validated.
A document full of screenshots and CVSS scores but lacking business context has limited operational value.
Hard2bit reviews each finding so that the final deliverable is not an export from a collection of tools. It is a clear explanation of what an attacker could achieve, what the resulting risk is and which remediation actions should come first.
Kali Linux, Parrot OS and Exegol are environments—not penetration tests
Kali Linux, Parrot OS and Exegol package tools and dependencies into convenient working environments.
They improve consistency, reduce setup time and make it easier for testers to reproduce their own workflows.
They do not replace methodology, protocol knowledge, programming ability, restraint, communication or commercial understanding.
Having hundreds of tools installed does not make someone a penetration tester any more than having access to an operating theatre makes someone a surgeon.
Automation and artificial intelligence: useful with supervision
Automation has a clear role in security testing. It expands coverage, repeats checks, detects changes, verifies known exposures and accelerates retesting.
It should not be trusted to decide, without human review, whether a finding is exploitable, what its impact is, whether two weaknesses can be chained or which issue the business should address first.
That is also Hard2bit’s approach: automate repeatable work so that specialist time is concentrated on the parts that genuinely validate the service.
Our consultants review relevant findings, remove false positives, reproduce exploitation where safe and investigate how one weakness may combine with another.
The result is not an automated tool export. It is a technical assessment interpreted by specialists and converted into clear risk and remediation decisions.
At Hard2bit, we apply the same principle through our own technology. Hard2bit Scanner automates part of the external reconnaissance and public security-posture review, but its results are used as a starting point rather than a final verdict.
The platform helps identify exposure, weak configurations and assets that deserve deeper investigation. Technical validation, controlled exploitation and risk interpretation remain the responsibility of the penetration-testing team.
The role of AI in penetration testing in 2026
AI assistants have also become part of the offensive-security workflow.
They can help summarise technical documentation, process large result sets, prepare supporting scripts, translate queries between languages, inspect code, generate test cases, classify evidence and suggest new investigative hypotheses.
They can also accelerate the initial understanding of unfamiliar protocols, SDKs and APIs.
Their output must be treated as a suggestion, not as evidence.
A model may invent parameters, refer to functions that do not exist, misunderstand a response, generate unsafe code or omit an important prerequisite. It also does not inherently understand the rules of engagement, the operational criticality of a service or the business consequences of an action.
In a professional penetration test, AI can contribute speed. Authorisation, execution, interpretation and validation remain the responsibility of the consultant.
To choose the right type of exercise, it is also important to understand the difference between penetration testing, red teaming and breach-and-attack simulation.
When penetration testing becomes a requirement
Tool selection is a technical decision, but the reason for commissioning a pentest may be contractual, regulatory or risk-driven.
In those cases, running tests is not enough. The organisation must also demonstrate scope, methodology, independence, evidence, remediation and retesting.
PCI DSS 4.0.1
PCI DSS provides a global baseline of technical and operational controls for organisations that store, process or transmit payment account data. PCI DSS v4.0.1 was published as a limited revision that clarified existing requirements without adding or removing requirements. (PCI Security Standards Council)
Requirement 11.4 includes penetration-testing obligations covering internal and external testing, significant changes and—where segmentation is used to reduce PCI scope—testing of those segmentation controls.
The exact applicability and frequency depend on the organisation’s role and cardholder-data environment. The testing methodology must cover the relevant attack surface and retain sufficient evidence to show how the conclusions were reached.
NIS2
NIS2 requires in-scope organisations to implement proportionate cybersecurity-risk-management measures and assess their effectiveness.
It does not impose an identical annual pentest on every organisation. In many environments, however, independent technical testing provides credible evidence that exposure, access controls, segmentation and defensive capability have been assessed in practice.
Further context is available in our guide to the practical NIS2 obligations affecting suppliers and SMEs and our NIS2 compliance service.
DORA and threat-led penetration testing
DORA establishes digital operational resilience requirements across the EU financial sector, including testing programmes and, for selected financial entities, threat-led penetration testing.
The regulatory technical standards adopted through Commission Delegated Regulation (EU) 2025/1190 specify the criteria used to identify the entities required to perform TLPT, together with requirements concerning scope, methodology, testers, remediation and supervisory cooperation. They also align the approach closely with TIBER-EU. (EUR-Lex)
TLPT is therefore not mandatory for every financial entity, and it is not simply a larger conventional pentest. It is an intelligence-led exercise covering critical or important functions and conducted within a formal governance framework.
The regulation does not prescribe Nmap, Burp Suite or BloodHound. It requires controlled execution, independence, meaningful evidence and remediation.
Hard2bit supports financial organisations through its DORA compliance and operational resilience service.
The point that matters
The offensive-security toolkit is broad, specialised and increasingly accessible.
That accessibility is valuable, but it can also create a false impression of competence. Knowing how to run a tool does not mean knowing when to use it, what risk it introduces, how to interpret its output, when to stop or how to translate a technical result into a business decision.
The value of an assessment is not measured by the number of tools executed or the number of pages in the report.
It lies in the judgement used to choose where to look, the ability to demonstrate realistic attack paths and the improvements the organisation makes afterwards.
Tools provide coverage. Artificial intelligence can provide speed. Experienced testers provide judgement, validation and meaningful impact.
The tool is the instrument. The penetration test is the judgement.
Need a penetration test that goes beyond automated scanning?
Hard2bit performs penetration testing across web applications, APIs, internal networks, infrastructure, Active Directory, cloud platforms, containers, Wi-Fi and mobile applications.
Our consultants combine automation with manual testing to validate findings, remove false positives, identify business-logic and authorisation flaws, build realistic attack paths and assess the impact on critical assets.
The result is not a scanner-generated vulnerability list. It is a specialist technical assessment supported by reproducible evidence and prioritised remediation guidance.
Request a penetration test tailored to your environment and objectives.
Last technical review: July 2026.