External Penetration Testing
Assess internet-facing assets to identify exploitable weaknesses before attackers do.
View service detailsInternal Penetration Testing · Central Illinois
Assume the perimeter already failed. Now find out how far that gets someone.
Phishing works. Laptops get stolen. Contractors get hired. An internal penetration test skips the argument about whether an attacker can get inside and answers the question that actually determines your risk: once they are in, how long until they own the domain?
What internal penetration testing actually covers
Internal penetration testing evaluates your network from the position of an attacker who already has a foothold — a compromised workstation, a phished user, a rogue device on the office wired network, or a contractor with legitimate but limited access. We start from that foothold and work toward the things that would hurt: domain administrator, the finance file share, the customer database, the backup infrastructure.
In practice most internal engagements become Active Directory engagements, because most organizations run Active Directory and its default configuration is optimized for administrability rather than for resisting attack. Kerberoasting, AS-REP roasting, unconstrained delegation, certificate services misconfigurations, and stale privileged group membership are not exotic — they are what we find, repeatedly, in environments that passed their vulnerability scan.
We also test the assumptions in your network design. Flat networks are still common. So are segmentation controls that exist in the firewall configuration but not in reality, VLANs that route to each other through a forgotten interface, and management networks reachable from the guest wireless. Segmentation testing is often the single most valuable result of the engagement.
When you need this test
You have a flat network and you know it
If a compromised receptionist workstation can reach the domain controller, the ERP server, and the backup appliance, you need documented evidence of that to fund the fix.
You are claiming segmentation for compliance
PCI DSS requires segmentation testing at least annually for the controls that keep systems out of scope. An assertion in a diagram is not evidence; a test is.
Ransomware is the board-level concern
Ransomware operators use exactly this playbook: initial access, credential harvesting, lateral movement, domain compromise, backup destruction, then encryption. Testing the middle steps is how you break the chain.
Active Directory has been running since before you got there
Domains that have survived several IT regimes accumulate service accounts with twelve-year-old passwords, nested groups nobody can explain, and admin rights granted for a project that ended in 2016.
You are deploying or tuning EDR
An internal test produces a concrete list of attacker techniques your tooling saw, missed, or saw and did not alert on — far more actionable than a vendor's detection coverage matrix.
What is in scope, and what is not
Included by default
- Active Directory: domain and forest trust configuration, delegation, ACL abuse, certificate services
- Credential access: hash capture, Kerberos ticket attacks, credential reuse across systems
- Lateral movement between workstations, servers, and management infrastructure
- Privilege escalation on Windows and Linux hosts
- Network segmentation validation between defined zones
- Internal services: file shares, databases, print, backup, hypervisor and virtualization management
Excluded unless contracted
- Destructive actions — we do not encrypt, delete, or modify production data
- Production outages: we halt before any action likely to disrupt a running service
- External perimeter breach, which is covered by an external test
- Phishing your staff to obtain the initial foothold, unless contracted as a separate exercise
Methodology, phase by phase
Every engagement follows the same documented arc. The percentages below describe how testing time is typically distributed — the balance shifts with what we find, but the phases do not change.
Scoping and foothold placement
Before testing beginsWe decide together how the assumed breach begins. The most common setup is a virtual machine we control on your internal network, or a standard-build laptop with a low-privileged domain user — deliberately the same access a new hire in a non-technical role would receive.
- Agree on starting position: unauthenticated network access, standard user, or a specific compromised role
- Define restricted systems and any data that must not be touched under any circumstance
- Establish escalation path for critical findings and a same-day notification threshold
Network reconnaissance
Roughly 15% of testing timeWe build a picture of the internal environment: live hosts, services, operating system versions, domain structure, and where the interesting data lives. Passive listening comes first, because broadcast traffic on a typical corporate network gives away a great deal before we send a single packet.
- Passive traffic analysis for LLMNR, NBT-NS, and mDNS broadcast poisoning opportunities
- Host and service discovery across in-scope ranges, tuned to avoid saturating the network
- Domain enumeration: users, groups, computers, trusts, group policy, and password policy
- Share enumeration and unauthenticated access review across discovered file servers
Credential access and Active Directory attack paths
Roughly 30% of testing timeWe collect credentials and map the graph of who can reach what. Attack path analysis matters more than any individual vulnerability here — the question is not whether one host is misconfigured but whether a chain of ordinary permissions adds up to domain compromise.
- Kerberoasting and AS-REP roasting against service and user accounts, with offline cracking
- NTLM relay and coercion testing where signing is not enforced
- Active Directory Certificate Services review for the known escalation templates
- Attack path graphing to identify the shortest route from our foothold to Domain Admins and Tier 0 assets
Lateral movement, escalation, and segmentation testing
Roughly 35% of testing timeWe move. Every hop is documented, and every technique is recorded against MITRE ATT&CK so your detection team can check their coverage line by line. In parallel, we test whether your network zones hold by attempting to cross each documented boundary.
- Lateral movement using recovered credentials, tickets, and hashes across workstations and servers
- Local privilege escalation on Windows and Linux via service misconfiguration, unquoted paths, sudo rules, and kernel exposure
- Segmentation validation: explicit reachability testing between every pair of defined network zones
- Access to designated crown-jewel systems, demonstrating impact without touching production data
Reporting, ATT&CK mapping, and retest
5 business days after testing endsYou receive the attack path narrative, the findings that enabled each step, and a technique-by-technique table your SOC can use to measure what they detected. Fixing the four permissions that break the chain is usually cheaper than fixing all sixty findings.
- Attack path diagram showing the full route from initial foothold to highest privilege obtained
- MITRE ATT&CK technique mapping with timestamps, so detection coverage can be verified against your SIEM
- Prioritized remediation plan that identifies the minimum set of changes that break the critical paths
- Free retest of remediated findings within 90 days
Standards this maps to
Auditors, insurers, and enterprise security reviewers all ask which methodology a test followed. These are the published frameworks our process is built on, and the report names them explicitly.
- PTES
- The Penetration Testing Execution Standard defines the engagement arc we follow: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting.
- NIST SP 800-115
- NIST's Technical Guide to Information Security Testing and Assessment. This is the document your auditor is most likely to name when they ask what your test was based on.
- MITRE ATT&CK
- Every technique we execute is mapped to its ATT&CK ID with a timestamp, which turns the report into a direct test of your detection coverage rather than just a list of misconfigurations.
- CIS Benchmarks
- Host and domain hardening findings reference the relevant CIS Benchmark control, so remediation maps to a configuration baseline your team may already be tracking.
What you receive
A human writes your report. Not a scanner export with a cover page, and not a template with your logo dropped into it.
- Attack path diagram
- A visual route from initial foothold to the highest privilege we obtained, with each hop labeled by the weakness that permitted it. This is the artifact executives actually look at.
- MITRE ATT&CK coverage table
- Every technique executed, with timestamps and source hosts, so your SOC can search their SIEM and determine exactly what was detected, what was logged but not alerted, and what was invisible.
- Segmentation test results
- A zone-by-zone matrix of attempted crossings and outcomes. Where segmentation held, you have evidence for your auditor. Where it did not, you have the specific rule to fix.
- Active Directory findings
- Delegation issues, certificate template misconfigurations, dangerous ACLs, stale privileged accounts, and password policy weaknesses, each with the specific object name and the remediation command or GPO change.
- Prioritized remediation plan
- Ordered by which fixes break the most attack paths, not by CVSS score. Typically a handful of changes eliminate the majority of the realistic routes to domain compromise.
- Attestation letter and retest report
- A shareable summary for auditors and insurers, plus verification of your fixes within the included 90-day retest window.
Typical scope and duration
- Typical testing window
- 5–10 business days
- Report delivery
- 5 business days after testing ends
- Total elapsed time
- 3–4 weeks from kickoff
- Common scope size
- 1 domain, 100–2,000 internal hosts
- Access required
- Network access plus a standard user account
- Retest window
- 90 days, included
What drives the price
We quote a fixed fee after a short scoping call. No hourly billing, no change orders mid-engagement. These are the variables that move the number:
- The number of Active Directory domains and forests, and whether trusts are in scope
- Internal host count and the number of distinct network zones requiring segmentation validation
- Whether testing is performed remotely via a deployed device or on site
- Whether you want covert testing measured against your SOC, which extends the testing window
- How many physical sites need coverage, since each one is a separate broadcast domain
Frequently asked questions
How long does an internal penetration test take?
Active testing usually runs 5 to 10 business days, with the report 5 business days later. Plan on 3 to 4 weeks total, including the kickoff call and shipping or provisioning the testing device. Multi-domain environments and organizations with many physical sites sit at the longer end.
Do you need to be on site?
Almost never. We ship a small hardened device that you plug into the network, or you stand up a virtual machine from an image we provide. Both give us the internal position we need. On-site testing is available where physical access or wireless coverage is part of the scope.
What access do you need to start?
The standard setup is network connectivity plus one standard, non-privileged domain user account — the same access a new hire in a non-technical role gets on day one. If you want a harder test, we can start with network access and no credentials at all.
Will you break anything or encrypt our data?
No. We never encrypt, delete, or modify production data, and we stop before any action likely to disrupt a running service. Where demonstrating impact would require a destructive step, we document that we had the access to take it and then do not take it.
Can this satisfy our PCI segmentation testing requirement?
Yes. PCI DSS requires segmentation testing at least annually for controls that keep systems out of cardholder data environment scope. We perform explicit zone-to-zone reachability testing and deliver a matrix documenting every attempted crossing and its result, which is what your QSA will ask to see.
What is the difference between this and a red team engagement?
An internal penetration test aims for coverage: find as many exploitable weaknesses and attack paths as possible in a fixed window. A red team engagement aims for a specific objective while staying undetected, and it tests your response capability more than your configuration. Most organizations should do internal testing well for a few years before a red team is worth the money.
Related engagements
Web Application Testing
Test modern web applications for logic flaws, auth issues, and exploitable vulnerabilities.
View service detailsAPI Security Testing
Analyze API endpoints for authorization flaws, data exposure, and abuse opportunities.
View service detailsNot sure this is the right test?
Tell us what you are trying to prove and to whom. A twenty-minute scoping call is usually enough to determine which engagement answers the question, and we will say so if the answer is a cheaper one.