External penetration testing

Attackers do not care which assets you have on a spreadsheet. They enumerate everything that answers. The assets most likely to be breached are often the ones nobody is watching: a marketing microsite from three campaigns ago, a staging server cloned from production, a subdomain still pointing at a cloud bucket someone deleted. None of these get patched because nobody remembers they exist.

This is why an external test begins with discovery rather than with a list you supply. Your list sets the authorized scope; discovery shows what is missing from it. Anything found outside the agreed scope is reported to you for a decision before it is touched. Ongoing discovery of this kind is also sold as external attack surface management, which watches continuously but generally does not attempt exploitation.

If you have never inventoried your exposure, a scan or attack surface tool is a sensible first step and costs less. A penetration test adds value when you need to know which exposures are actually exploitable and in what order to fix them.

Scope is usually defined by root domains and IP ranges you own or control, plus any cloud-hosted endpoints. Hosted services owned by third parties (a SaaS help desk on your subdomain, a payment page run by a processor) are generally excluded unless that provider's terms permit testing. Credential attacks against login portals are capped to avoid locking out real staff, and denial-of-service is off the table. The signed rules of engagement record all of this.

An open port is not a finding; a reachable admin panel that accepts a default password is. During Brexa's Prove stage an operator demonstrates impact safely, for example by showing authenticated access or a readable file, without moving further than the rules allow. Fixes are often simple once known: remove the DNS record, shut the service, restrict it to a VPN, rotate the leaked key, or patch the appliance. Verify confirms each one from the outside again, the same way an attacker would check.