Exploit Public-Facing Application (MITRE ATT&CK T1190) is initial access through a weakness in something that faces the internet. The weakness can be a software bug, a temporary glitch or a misconfiguration. MITRE lists the platforms as Containers, ESXi, IaaS, Linux, Network Devices, Windows and macOS.
Most people think of web servers first, and those are common. But MITRE's scope is wider: databases such as SQL servers, standard services such as SMB or SSH, network device management protocols such as SNMP and Smart Install, and any other system with an internet-accessible open socket.
How attackers use it
The technique is simple to state. An attacker finds an exposed service, sends input that triggers a flaw, and gets a foothold. What changes is what they reach afterward, and MITRE calls out a few cases.
Cloud and containers. If the app runs on cloud infrastructure or in a container, exploiting it can lead to compromise of the instance or container. From there an attacker may reach cloud or container APIs, for example through the cloud instance metadata API, try to escape to the host, or take advantage of weak identity and access management policies.
ESXi. MITRE notes that on ESXi infrastructure, adversaries may exploit exposed OpenSLP services, or exposed VMware vCenter servers.
Edge devices. Adversaries may also go after edge network infrastructure and appliances, especially devices that do not support strong host-based defenses. That matters for detection: if you cannot run an agent on the device, your visibility comes from logs and network telemetry around it.
For websites and databases, MITRE points readers to the OWASP Top 10 and the CWE Top 25 as the lists of the most common web vulnerabilities.
Depending on the flaw, this can also involve exploitation for stealth or for client execution, which are separate ATT&CK techniques.
How to detect it
MITRE's detection strategy correlates a chain of events instead of waiting for one perfect signature. The chain, adapted per platform:
- Abnormal requests to a public endpoint, such as unusual methods or paths.
- Errors. A spike in 4xx or 5xx responses, or WAF blocks.
- A process that should not do this. The server process (w3wp.exe on IIS, or apache2, nginx, php-fpm, node or python on Linux) starting a shell, a living-off-the-land binary, curl, wget or socat, or writing a webshell.
- A callback. An outbound connection from the host or container to a new destination.
For containers, MITRE adds ingress and app logs, a shell or exec inside the container, and egress to the internet or to the metadata service address 169.254.169.254. For cloud hosted endpoints, the sources are load balancer logs showing exploit-like input or error spikes, then a workload that spawns a shell or reaches the metadata API. For ESXi and vCenter, the signal is a crash or restart of hostd or vpxd after inbound requests to a management service, followed by unexpected process behavior.
The practical lesson is to log the web tier and the process tier together. A 500 error in an access log is boring. A 500 error followed by the web server user launching a shell is not.
How to reduce the risk
MITRE's mitigations, in plain steps:
- Isolate the application. Limit what other processes and system features an exploited app can reach.
- Use a web application firewall to keep exploit traffic from reaching the application.
- Restrict outbound traffic from public-facing servers. This may not stop the first exploit, but it limits the attacker's ability to verify and control the server afterward.
- Check that every exposed service is meant to be exposed. Restrict anything that should only be reachable internally.
- Segment. Put external-facing servers in a DMZ or on separate hosting infrastructure.
- Use least privilege for service accounts. The exploited process gets only the permissions it needs.
- Patch external applications regularly through patch management.
- Scan externally facing systems for vulnerabilities and have a procedure to patch quickly when critical issues appear through scanning or public disclosure.
Check your own environment
A starting checklist:
- Do you have a current list of every internet-facing service, including old test systems and appliances?
- For each, who owns patching, and what is the target time for critical fixes?
- Can your public servers make arbitrary outbound connections?
- Do web server logs, WAF logs and process creation logs land in the same place?
- Do service accounts on public servers have more rights than the app needs?
On a Linux host, this read-only command lists listening TCP sockets and the process behind each one (run as root to see all processes):
ss -tlnp
Compare the result with what you expect to be exposed. Anything unexpected deserves a name and an owner.
Try it yourself
Knowing a flaw exists is not the same as knowing it can be reached and used in your setup. This demo walks through checking exploitability.
Click through it at your own pace, or open it full screen.
Quick check
Which outbound control does MITRE recommend for public-facing servers, and why?
Restrict outbound traffic from them. It may not prevent the initial exploitation, but it limits the attacker's ability to verify and control the compromised server, which reduces the overall impact.
What chain of events does the detection strategy look for on a Linux web server?
Suspicious requests in access logs, a spike of 5xx errors or WAF blocks, the web server or interpreter process spawning a shell, curl, wget or socat or writing a webshell, and then an outbound callback.
Why is a containerized app a different risk from a plain host?
Exploiting it can give access to the underlying instance or container, and from there to cloud or container APIs such as the instance metadata API, or to the host through an escape.
