Buying a penetration test is easier when you know what the week actually involves. Here is the shape of a real engagement, from the paperwork to the retest.
Most people who ask what a penetration test looks like are not asking about hacking. They are asking what they are about to pay for, who will be on their network, what will land on their desk at the end, and whether anything is going to break. Those are the right questions, and the answers are more mundane than the word "pentest" suggests.
If you are still deciding whether you need one at all, start with what penetration testing is and how it differs from a scan. This piece assumes you have decided, and walks through the engagement itself.
The work starts on paper. NIST's Technical Guide to Information Security Testing and Assessment (SP 800-115) breaks a penetration test into four phases, and the first one is planning, not attacking. In practice that means a scoping conversation followed by a written document both sides sign.
CREST, the accreditation body for the testing industry, puts it plainly: the scope of a penetration test should be recorded in a formal document signed off by all relevant parties. That document should name the in-scope address ranges and applications, the testing window, the techniques that are off the table (denial of service usually is), how far the tester is allowed to go once they have access, who to call at 2 a.m. if something goes wrong, and how any sensitive data the tester touches will be handled and destroyed.
Two things are worth pushing on before you sign. Ask what happens if the tester finds something critical on day one, because you want that phoned in rather than saved for the report. And ask whether a retest is included or quoted separately, for reasons covered further down.
For an internal test, the engagement usually begins with a device on your network. It goes by a few names, "rogue device" or "network implant" among them, and physically it is unglamorous: a Raspberry Pi, an Intel NUC, or a small appliance the tester ships to your office. Some engagements run from a virtual machine or a laptop instead. Either way, the tester now has the same position on your network that an attacker would have after compromising one workstation.
The first move is not an attack. It is listening. Windows networks are chatty, and a tester watching broadcast traffic learns your naming conventions, your server roles, and which protocols you have left switched on.
A penetration test is not usually designed to be stealthy. Evading your detection stack is a different exercise, called a red team engagement. A standard pentest is trying to find every way in within an agreed window, which is why it will trip alarms, and why your security team should know it is happening.
Two legacy Windows protocols do most of the work here. When DNS fails to resolve a name, Windows falls back to LLMNR and NBT-NS, which put the question to the local subnet (LLMNR by multicast, NBT-NS by broadcast) and accept the first answer without authenticating it. A tester answers "that's me," and the machine that asked tries to authenticate.
What the tester captures at that moment is worth getting right, because it is widely described wrongly. It is not your password hash. It is a NetNTLM challenge-response, a one-time cryptographic proof computed from the password hash against a challenge the server supplied. It cannot be replayed as a pass-the-hash attack. It has exactly two uses: crack it offline to recover the plaintext password, or relay it live to another service that will accept it.
This is not a theoretical path. CISA and the U.S. Coast Guard published an analysis of 143 risk and vulnerability assessments they conducted across critical infrastructure sectors. Name-resolution poisoning with SMB relay succeeded in 13% of those assessments. Measured separately, under initial access, valid accounts were the single most common successful technique at 41%, and they were used for privilege escalation in 45% of instances. Stolen and reused credentials are the common thread through all three numbers.
Microsoft has narrowed this path recently, though less than the headlines suggest. SMB signing is now required by default on Windows 11 version 24H2 in the Pro, Enterprise and Education editions, which closes the most common SMB relay path against workstations. Windows Server 2025 requires only outbound signing by default, so member servers remain relay targets, and signing does nothing to stop a captured response being relayed to LDAP, HTTP or Active Directory Certificate Services. NTLMv1 has also been removed in those releases, although NTLMv1-derived cryptography lingers in some domain scenarios and blocking only becomes the default in late 2026.
What has not changed at all is that LLMNR and NBT-NS are still enabled by default. Microsoft's own Windows 11 security baseline still instructs administrators to turn multicast name resolution off, which tells you whose job it remains. If your fleet predates 24H2, both the capture and the relay are wide open.
Vulnerability scanning may or may not be part of your test. If you already run a scanning program, the tester may skip it and spend the time on things a scanner cannot do. If you do not, a scan early in the engagement finds the unpatched, directly exploitable systems quickly.
A foothold on one workstation is not the finding. What matters is how far it travels.
Once on a system, the tester looks for a way up: an unpatched local privilege escalation flaw, a service running with weak permissions, credentials sitting in a script or a text file, or a token they can impersonate. Metasploit's Meterpreter often shows up at this stage, though it is worth being precise about what it is. Meterpreter is a post-exploitation payload, the interactive agent that runs after an exploit has already succeeded. It includes a getsystem command that elevates from local administrator to SYSTEM, which is a narrower thing than "privilege escalation tool" implies.
With administrative rights on a machine, the next step is pulling credentials out of memory. MITRE catalogues this as OS Credential Dumping from LSASS memory (T1003.001), and it works because of how Windows caches credential material for logged-on users. If a domain administrator has ever logged into that machine, their credentials may be sitting there.
From there the process repeats. New credentials open new systems, which yield new credentials, until the tester reaches domain administrator or the sensitive data the scope named as the objective.
Microsoft's protections against this are real, and the conditions attached to them are where most organizations get caught out. Credential Guard is on by default on domain-joined Windows 11 22H2 and later and Windows Server 2025 systems that meet the hardware requirements, but it requires Enterprise or Education licensing. Most small and mid-sized fleets run Windows Pro, which does not qualify.
LSA protection is also enabled by default on Windows 11 22H2 and later, but only on clean installations that are domain or Entra joined and capable of hypervisor-protected code integrity. Machines upgraded from an earlier release do not get it. A fleet that upgraded rather than reimaged may be unprotected while the IT team assumes otherwise, and that is exactly the sort of gap an internal test surfaces.
Reporting is a named phase in the NIST methodology, and the report is the part you actually keep. A good penetration test report is readable by two different audiences: an executive summary that says what an attacker could do to the business, and a technical section that gives your engineers enough detail to reproduce and fix each finding.
Each finding should carry the affected systems, the steps taken, evidence, a severity rating with the reasoning behind it, and a specific remediation. "Harden Active Directory" is not a remediation. "Disable LLMNR and NBT-NS via Group Policy on these subnets" is.
Ask to see a redacted sample report before you sign anything. It is the clearest signal of what you are buying, and any firm that will not show you one is telling you something.
A report is a list of problems. The engagement is not finished until someone has confirmed they are gone.
This is not just good practice. PCI DSS requires internal and external penetration testing at least every twelve months and after significant changes, and it requires that testing be repeated to verify that findings have been corrected. Evidence of the testing and the remediation should be retained. CREST folds retesting into the scope document, agreed up front rather than negotiated later.
The pace matters as much as the fact. Cobalt's 2026 State of Pentesting report, drawn from more than 16,500 of its own engagements and a survey of 450 security professionals, puts the median time to resolve a high-risk finding at 39 days. The fastest organizations clear half their high-risk findings within 10 days. The slowest tenth take 249. A finding you have not fixed is a finding an attacker can still use.
If a proposal ends at report delivery, with the retest priced as a separate engagement or missing entirely, that is worth raising before you sign.
iFlock delivers penetration testing in-house, with senior engineers rather than account managers, and the scope, the report format and the retest are all agreed before anyone connects a device. You can see the full range on our penetration testing services page. If credential theft is what is keeping you up, our guide to email security services covers the other end of the same problem.
Not sure whether you need a full test yet? Start with a free security assessment. Talk to us at iflockconsulting.com/contact-us or call 1-833-4-HAXORS (1-833-442-9677).
Fly with confidence.
How long does a penetration test take?
It depends on scope, and any firm quoting a duration before scoping is guessing. The number of live hosts, the number of applications, whether external and internal testing are both in play, and whether social engineering is included all change the estimate. What you should expect is a written schedule with start and end dates agreed before testing begins, plus a defined window for report delivery.
Will a penetration test break something?
It can, which is why the rules of engagement exist. A professional test agrees in writing how far exploitation is allowed to go, excludes denial of service unless you specifically want it, names fragile or legacy systems that need special handling, and gives both sides an escalation contact. Testing outside production or during a defined window are both normal accommodations.
How often does PCI DSS require penetration testing?
PCI DSS requires internal and external penetration testing at least once every twelve months and after any significant infrastructure or application change. Findings must be corrected and the testing repeated to verify the corrections. The tester must be organizationally independent, but does not have to be a QSA or ASV.