Exploit Public-Facing Application

Exploiting a public-facing application means going straight at whatever a web server, API, or network-facing service will accept from the open internet, no phishing, no stolen credentials, no foothold needed first. If a piece of software listening on the internet has a known vulnerability, or a flaw nobody's found yet, this is the technique that abuses it directly.

This is often the very first technique in an intrusion chain specifically because it requires nothing else to already be true. An attacker doesn't need a user to click anything or a password to guess; they need a reachable service and a weakness in it, and the internet is a very large place to look for both.

Once a vulnerable, internet-facing application is found, whether through active scanning or an already-known CVE against a specific software version, an attacker sends crafted requests designed to trigger the flaw: an injection payload, a malformed input the application doesn't sanitize, a request that reaches a code path never meant to be reachable from outside.

Success looks different depending on the vulnerability, arbitrary command execution, a file written somewhere it shouldn't be, an authentication bypass, but the starting point is always the same: requests that don't look like normal traffic to that application, arriving from the outside.

Data source: The web server's access log, which shows the request reaching the vulnerable endpoint. Then the application's own query log, which is what proves the injected statement executed rather than merely arrived -- it carries the statement, its parameters and the number of rows returned, and an unparameterised statement returning a whole table is the finding. A network IDS may also raise a signature alert on the request; treat that as corroboration, since it depends on the tool used and will not fire for every injection.

{
  "url": {
    "path": "/upload.php",
    "query": "cmd=whoami"
  },
  "host": {
    "name": "WEB01"
  },
  "http": {
    "request": {
      "method": "GET"
    },
    "response": {
      "status_code": 200
    }
  },
  "source": {
    "ip": "203.0.113.44"
  }
}

Prebuilt Elastic rule: Web Server Potential Command Injection Request

Start with the access log, not the alert. Filter for request paths or query strings containing characters and sequences that don't belong in normal traffic to that application, shell metacharacters, path traversal sequences, unexpected encoded payloads, and look at which ones produced a response suggesting the request was actually processed rather than rejected outright.

Hunting manually: sort by response code and look for successes on unusual paths, then cross-reference the timing against any host-level activity on the web server around the same moment, since a successful exploit often produces effects beyond just the request itself.

Vulnerability scanners, whether run by your own security team or by opportunistic internet-wide scanning services, send exactly the kind of malformed, probing requests that make this technique hard to distinguish from routine background noise. Most public-facing applications receive scan traffic constantly.

The distinguishing signal is response and consequence: a scanner's requests are usually broad and shallow, testing many paths without following up, and typically get rejected with error responses. A request that succeeds, and especially one followed by new, unexplained activity on the host itself (a new process, a new file, an outbound connection), is a different story entirely from the ordinary background hum of internet scanning.

• MITRE ATT&CK T1190: Exploit Public-Facing Application
• Elastic Security: Web Server Potential Command Injection Request

1 scenario in this catalog covers T1190. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →