Preparing for a CREST internal pen test.Without gaming it.

Agree the scope in writing

Most of the value of a test is decided before it starts. The rules of engagement should cover:

• which address ranges and systems are in scope, and which are out, such as fragile, safety-critical or third-party hosted systems;
• the testing window, and whether anything risky runs out of hours;
• where the tester starts: with a standard domain user account, which simulates a compromised laptop, or from a network port with no credentials at all. If you can afford both, do both;
• named contacts on each side, an escalation route and a way to pause the test immediately;
• how credentials and data the tester recovers will be stored, reported and destroyed.

Check that the provider is a CREST member company and that the people doing the work hold current CREST qualifications, such as CRT or CCT INF. The accreditation on the company is not the same as the skill of the tester in your building.

Fix what you already know

The aim is a useful report, not a clean one. If a weakness is already on your list, fix it beforehand or tell the tester about it, so they can go further. In Windows estates, these come up again and again:

• Name resolution poisoning. LLMNR and NetBIOS over TCP/IP left switched on, letting an attacker collect password hashes from the network. Disable both.
• SMB signing not required. Without it, captured authentication can be relayed to other machines. Require signing on servers and clients. Windows 11 24H2 and Windows Server 2025 tighten the defaults; older machines need policy.
• Relay paths to domain controllers. Turn on LDAP signing and channel binding, and Extended Protection for Authentication on internal web services such as certificate enrolment.
• Certificate templates anyone can abuse. A misconfigured Active Directory Certificate Services template can let an ordinary user request a certificate as anyone, including a domain admin. Audit templates with a tool such as Locksmith or Certify, and remove or restrict the risky ones.
• Service accounts with weak passwords. Any account with a service principal name can be attacked offline. Move to group managed service accounts, or use long random passwords with AES encryption.
• Shared local admin passwords. One password on every machine turns a single compromised laptop into all of them. Use Windows LAPS.
• Passwords in plain sight. Scripts, file shares and old Group Policy Preferences files in SYSVOL. Search for them before someone else does.
• Default credentials on devices. Printers, UPS cards, switches and server management controllers such as iLO or iDRAC.
• Privilege nobody meant to grant. Nested groups that quietly make ordinary accounts admins, stale accounts and unconstrained delegation.

Walk your own attack paths first

A month before the test, map how an ordinary account could become a domain admin. Free tools such as BloodHound Community Edition and PingCastle show those paths as a graph and a score. Work through the shortest paths first: removing one group membership can close dozens of routes.

Leave time for change control. The fixes that matter most, such as certificate templates and service account passwords, touch production and need testing. A week is rarely enough.

Decide what you want to learn about detection

If your security team or provider knows the test is coming and allow-lists the tester, you learn about prevention. If they don't, you also learn whether anyone noticed, and how quickly. Both are legitimate. Decide beforehand, and agree what should happen if your endpoint protection isolates the tester's machine.

Either way, someone must be able to stop the test within minutes if something breaks.

Protect production while it runs

• Confirm that backups have completed and can be restored before the window opens.
• Freeze non-essential changes, so any disruption is easy to trace.
• Keep fragile systems out of scope, or test them gently with their owners on hand.
• Have an engineer on call for the whole window, not just office hours.

Make the report worth paying for

Ask for attack narratives: the chain from the first foothold to the highest privilege reached, with evidence and steps to reproduce each link. A list of vulnerabilities ranked by CVSS score tells you what is wrong; a narrative tells you what matters. Then book a retest within 30 to 60 days, so the fixes are verified rather than assumed.