Penetration testing of
external infrastructure
Everything your company exposes to the internet is probed daily by automated tools. We do the same, only more carefully and with a report at the end. We start from an inventory, because in practice the most common problem is not a missing patch but a system nobody remembered.
- Attack surface inventory, including forgotten systems
- Manual verification instead of a report glued together from a scanner
- A controlled attempt to move from the internet into the internal network
External infrastructure
- PTES
- OSSTMM
- NIST SP 800-115
- OWASP
What exactly we check
We tailor the scope to your environment, but these areas are always covered.
Attack surface inventory
Domains and subdomains, address ranges, cloud services, systems launched without the IT department knowing, and the risk of taking over abandoned subdomains pointing at resources that no longer exist.
Edge services
VPN gateways, remote access and RDP, mail servers, file transfer systems, administration panels exposed publicly. Today this is the most common way into an organisation.
Known vulnerabilities and patching
Software version identification and verification of vulnerabilities with public CVE numbers. Every hit is confirmed manually so that no false positives reach the report.
Configuration and email
TLS configuration and supported ciphers, security headers, DNS settings and zone transfer, SPF, DKIM and DMARC records and how easily your domain can be spoofed.
Leaks and public data
Employee credentials in public breaches, keys and passwords in code repositories, backups and configuration files reachable without authentication, data hidden in document metadata.
Controlled exploitation
A safe attempt to exploit the findings in order to show the real impact: access to a system, data retrieval or entry into the internal network. Always within the scope agreed in the contract.
What we find most often
Examples from our projects in this area. Client names and technical details stay in the reports.
- An unpatched VPN gateway vulnerable to a publicly known critical flaw
- An administration panel exposed to the internet with a default password
- A forgotten test environment holding a copy of the production database
- A subdomain takeover pointing at a deleted cloud resource
- A soft SPF record leaving the domain open to spoofing
- A configuration file with database credentials available without authentication
- Cloud access keys in a former contractor public repository
- RDP access without a second factor and without address restrictions
Selected tools
Tools take care of the repetitive work. The conclusions and attack chains are built by hand.
How the test runs and what you get
The testing process, the report format and the retest rules are the same across every scope.
See the full process and report contentsFrequently asked questions
Do I have to provide the address list?
You can give us the range directly, or ask us to establish the attack surface ourselves from the company name and domains. The second option better reflects how an attacker works and regularly turns up systems that were not on the list.
Will the tests disrupt our services?
We match the intensity to a production environment and we do not run denial of service attacks. Risky actions are announced before execution, and we stay reachable by phone throughout the engagement.
Should we allowlist your addresses on the firewall?
No, and we usually advise against it, because the test should reflect real conditions. We do provide the addresses we work from so you can tell our activity apart from a genuine attack when reviewing logs.
How often should this be repeated?
Once a year as a rule, and after every significant infrastructure change. The attack surface moves faster than applications: one new deployment or one server spun up briefly is enough.
Other testing scopes
We combine scopes into a single project whenever that works better for your environment.
Web applications and APIs
We detect vulnerabilities from the OWASP Top 10 (including SQL Injection, XSS, SSRF, BOLA). We audit customer portals, e-commerce systems, CRMs and complex environments based on microservices and APIs (REST, GraphQL).
View scopeMobile applications
Reverse engineering of iOS and Android applications (including Flutter and React Native). We verify secure on-device data storage, correct server communication and flaws in authorization logic.
View scopeInternal infrastructure
We simulate an attack, for example from the perspective of a malicious employee or a compromised workstation. We examine network segmentation (VLAN), Active Directory, file servers and password policies.
View scopeCloud environments
We verify the security of resources in AWS, Azure and Google Cloud Platform. We focus on IAM permission errors, storage bucket (S3) leaks and Serverless vulnerabilities.
View scopeWireless networks
We analyze the security of corporate Wi-Fi networks, guest network isolation, susceptibility to password interception, Evil Twin attacks and Rogue Access Points.
View scope