Internal Penetration Testing
Simulate an internal adversary to evaluate lateral movement and privilege escalation risk.
View service detailsExternal Penetration Testing · Central Illinois
Everything you own that faces the internet, attacked the way it will actually be attacked.
An external penetration test starts from the position a real attacker starts from: no credentials, no network access, and nothing but your domain name and IP ranges. We find what you have exposed, including the assets nobody told you about, and we prove what can be done with them.
What external penetration testing actually covers
External penetration testing evaluates every system reachable from the public internet — web servers, VPN concentrators, mail gateways, remote access portals, cloud storage, forgotten staging environments, and the third-party services (no active exploitation of third-party services) quietly holding your data. We work unauthenticated and from outside your network, in the same posture as an opportunistic attacker or a targeted one.
The part that matters is what happens after discovery. A vulnerability scanner produces a list of maybes. We take those maybes and try them. If a finding is exploitable, we exploit it in a controlled way and capture the evidence. If it is a false positive, it never reaches your report. The output is a set of confirmed attack paths, not a CVE inventory you have to triage yourself.
But we do not stop at what is already public. Known CVEs with published exploit code are the floor, not the ceiling. When testing reaches software with no public exploit — a niche appliance, a vendor portal, a bespoke application somebody exposed to the internet years ago — we read it, reverse it, and develop the exploit ourselves. That is the same work behind the fourteen CVE identifiers assigned to our founder's research, across targets ranging from consumer IoT hardware to campus administration platforms, and it is the difference between a report that lists your outdated software and one that demonstrates what an attacker does with it.
The tooling is ours too. Discovery runs through Injectra, an external pentest platform we built and operate, which enumerates internet-facing assets and tests them the way an attacker would rather than the way a scanner license permits. Injector, our AI hack bot, carries the breadth work — sweeping large ranges, correlating fingerprints against exploit availability, and surfacing candidates worth a human look. None of what it surfaces reaches your report until a person has reproduced it by hand.
Most organizations are surprised by the discovery phase more than the exploitation phase. The asset that ends up mattering is usually one that was stood up for a project three years ago, never decommissioned, and never patched — and it is not in the scope list you sent us, because you did not know it existed.
When you need this test
A customer or insurer is asking for a report
SOC 2, PCI DSS 4.0, HIPAA, and cyber liability renewals commonly require an annual external test against the internet-facing environment. Requirement 11.4 of PCI DSS is the usual specific citation.
You have never actually inventoried what is exposed
If nobody can produce a current list of your public IP ranges, domains, and subdomains, the answer is that your attack surface is larger than you think. Discovery alone tends to justify the engagement.
You just finished a migration
Cloud migrations, data center consolidations, and acquisitions all leave behind exposed remnants. Old firewall rules outlive the systems they were written for.
You inherited the environment
New CISOs, new IT directors, and post-acquisition integration teams need an unbiased baseline that was not produced by the people who built the environment.
Credential stuffing and password spraying are hitting you
If your logs show authentication attempts against Microsoft 365, your VPN, or your Citrix portal, you need to know which of those front doors would actually open.
What is in scope, and what is not
Included by default
- Public IP ranges, individual hosts, and network appliances
- Domains, subdomains, and the certificate transparency trail behind them
- VPN, RDP, Citrix, and other remote access gateways
- Mail infrastructure, including SPF, DKIM, DMARC, and relay behavior
- Internet-exposed cloud resources: storage buckets, management planes, misconfigured security groups
- Login portals and the credential attacks that target them
Excluded unless contracted
- Denial-of-service and volumetric load testing, unless explicitly contracted
- Physical intrusion and social engineering, which are separate engagements
- Internal network movement past the perimeter — that is an internal test
- Anything hosted by a third party without their written authorization
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 rules of engagement
Before testing beginsWe agree in writing on target ranges, testing windows, escalation contacts, and the specific actions that are prohibited. You get a source IP list so your SOC can distinguish us from a real intrusion — or deliberately not receive it, if the goal is to test detection.
- Confirm asset ownership and obtain third-party testing authorization where hosting is external
- Set the testing window, blackout periods, and emergency stop procedure
- Define the critical-finding threshold that triggers a same-day call rather than a report entry
Attack-surface discovery
Roughly 20% of testing timeWe enumerate the real perimeter rather than the documented one. Passive sources come first — certificate transparency logs, DNS history, public code repositories, breach corpora, and cloud provider ranges — followed by active resolution and service fingerprinting.
- Subdomain enumeration across passive datasets, brute force, and permutation generation
- Full TCP port sweep with targeted UDP coverage, then service and version fingerprinting
- Technology stack identification and virtual host discovery on shared infrastructure
- OSINT collection: exposed credentials, leaked API keys, employee email format, public repositories
Vulnerability analysis and threat modeling
Roughly 20% of testing timeAutomated scanning runs here, but only as an input. We correlate scanner output against version fingerprints, exploit availability, and your actual configuration, then rank targets by how likely they are to yield real access rather than by raw CVSS.
- Authenticated and unauthenticated scanning with manual verification of every candidate finding
- Review of TLS configuration, exposed management interfaces, and default credential exposure
- Identification of the shortest plausible path from unauthenticated internet to sensitive data
Manual exploitation
Roughly 40% of testing timeThis is the phase that separates a penetration test from a vulnerability assessment. We attempt actual compromise of the targets identified above, chaining low-severity issues where a chain produces meaningful impact, and we document each step with reproducible evidence.
- Exploitation of confirmed vulnerabilities in exposed services and applications
- Password spraying and credential-stuffing simulation against discovered login portals, throttled to avoid lockouts
- Testing of multi-factor implementation for bypasses, fallback weaknesses, and fatigue susceptibility
- Controlled post-exploitation to establish demonstrable impact, stopping short of any action that risks availability
Reporting and retest
5 business days after testing endsA human writes your report. Every finding includes the reproduction steps, the evidence, the business consequence in plain language, and remediation guidance specific to your stack rather than a link to a vendor advisory. Retesting of remediated findings is included.
- Draft report delivered with an executive summary written for a non-technical reader
- Technical walkthrough call with your engineering team
- Free retest of remediated findings within 90 days, with an updated attestation letter
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.
- OSSTMM
- The Open Source Security Testing Methodology Manual informs how we measure and express attack surface, particularly the distinction between exposure and actual accessibility.
- CVSS v4.0
- Every finding carries a CVSS v4.0 vector so the base score is reproducible, plus a separate business-impact rating, because a 9.8 on a decommissioned host is not your biggest problem.
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.
- Executive summary
- Two to three pages written for a board or an insurer. What we found, what it means for the business, and whether the perimeter held. No jargon, no scanner output.
- Attack-surface inventory
- The full list of internet-facing assets we discovered, including the ones missing from your scope document. Clients regularly tell us this is the most useful artifact in the package.
- Technical findings
- Each finding carries a CVSS v4.0 vector, affected assets, step-by-step reproduction, screenshots or request/response captures, and remediation guidance written for the team that owns the system.
- Attack narrative
- A chronological account of how we moved from zero knowledge to whatever access we achieved. This is the section that changes minds in a budget meeting.
- Attestation letter
- A signed, shareable summary letter suitable for customers, auditors, and insurers — no sensitive detail, just confirmation of scope, dates, and methodology.
- Retest report
- After you remediate, we verify the fixes and issue an updated document showing the closed findings.
Typical scope and duration
- Typical testing window
- 5–10 business days
- Report delivery
- 5 business days after testing ends
- Total elapsed time
- 2–4 weeks from kickoff
- Common scope size
- 1–256 live external hosts
- Access required
- None — we start unauthenticated
- 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 live, responsive hosts — not the size of your allocated IP ranges
- How many distinct web applications sit behind those hosts, since each one adds application-layer testing time
- Whether login portals are in scope for credential attacks, which requires careful throttling and coordination
- Whether you want the test run covertly against your SOC, which slows testing deliberately
- Retest scope and whether you need more than the included 90-day window
Frequently asked questions
How long does an external penetration test take?
Most external engagements run 5 to 10 business days of active testing, with the report delivered 5 business days after testing ends. From kickoff call to final report, plan on 2 to 4 weeks. Scopes under 20 live hosts can often be compressed; scopes spanning multiple acquired companies take longer, mostly in discovery.
What does an external penetration test cost?
Price is driven by the number of live hosts, the number of distinct web applications behind them, and whether credential attacks against login portals are in scope. We scope from a short discovery call and quote a fixed fee — no hourly billing and no surprise change orders. We will tell you on that call if a cheaper assessment would serve you better.
How is this different from a vulnerability scan?
A vulnerability scan produces a list of potential issues based on version numbers and signatures, and it is wrong a meaningful percentage of the time. A penetration test takes that list, verifies each item by hand, discards the false positives, and chains the real ones together to demonstrate actual impact. Scanning is an input to our process, not the product.
Will testing take our systems offline?
No. We exclude denial-of-service and volumetric testing by default, throttle credential attacks to avoid account lockouts, and stop short of any post-exploitation action that risks availability. You get an emergency stop contact before testing begins, and we agree on blackout windows in advance.
Do we need to tell our team the test is happening?
That is your call, and both options are useful. Announced testing maximizes coverage in a fixed window. Unannounced testing also measures whether your monitoring and response actually work. If you go unannounced, we still require one executive contact who knows, so a real incident is never mistaken for us.
Do you serve businesses outside Central Illinois?
Yes. We are based in the Peoria area and work regularly with organizations in Bloomington–Normal, Champaign–Urbana, Springfield, and Decatur, but external testing is performed remotely and we take engagements nationwide.
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.