How T1190 exploitation gets adversaries into your network
T1190 Exploit public-facing application is how an adversary uses a weakness in an internet-reachable service to gain a first foothold in your environment. In MITRE ATT&CK, it sits under the Initial Access tactic (TA0001), whose stated purpose is that the adversary is trying to get into your network. The technique is described in the Enterprise ATT&CK 20.0 knowledge base, so detection mappings for your program should name that version explicitly. Your public web applications, APIs, remote access gateways, and the hosts behind them must be reachable from the internet to do their job, which is why they are a persistent entry point rather than an occasional one.
The reach of this technique is wider than web servers. The same pattern applies to container platforms and their management interfaces, hypervisor management endpoints such as ESXi, cloud-hosted virtual machines and IaaS control planes, and Linux services exposed for business or partner use. Each of these platforms adds its own inventory question: which services are published, which versions run on them, and which of those are owned by a team that patches them on a schedule. Many intrusions that begin here are discovered only after the fact because the exposed component was not in the asset register or was managed by a different team from the one reviewing logs.
For a CISO or platform lead, the practical starting point is an inventory of internet-facing entry points, with an owner, a patch cadence and a log source for each. Confirm with your platform and cloud teams whether every exposed workload forwards network and process telemetry to your monitoring stack, and whether the upstream vendor publishes advisories for each version you run. Where you cannot answer these questions for a given platform, treat that gap as the first finding to close, because detection for T1190 depends on knowing what should be reachable in the first place.
Which telemetry reveals exploitation of public-facing applications
This table maps each ATT&CK data component relevant to T1190 to the exploitation signal it shows and the open-source collector that gathers it, targeting Enterprise ATT&CK v18 and later detection strategies. Read it as a coverage checklist: no single source reliably reveals exploitation, so pair network sensors at the application edge with host and application logs.
| Data component | Signal for T1190 | Open-source collector or tool |
|---|---|---|
| Network Connection Creation (DC0082) | New inbound sessions to exposed services from unexpected sources, or unusual connection bursts to a web or API port | Zeek connection logs, Suricata flow records, Security Onion dashboards |
| Network Traffic Content (DC0085) | Request payloads, headers and responses that match known exploit patterns or abnormal application protocol use at the edge | Suricata rules with payload inspection, Zeek protocol analyzers, Security Onion alerts |
| Process Creation (DC0032) | A web or application service spawning a shell, interpreter or download utility, which suggests code execution in the application context | Wazuh agent process monitoring, Sysmon for Linux or Windows where deployed, Velociraptor hunts |
| Application Log Content (DC0038) | Malformed requests, repeated errors, unusual parameters, authentication anomalies and stack traces in web server or framework logs | Wazuh log collection and decoders, Filebeat or Fluent Bit shipping to the SIEM stack in use |
| Network Traffic Flow (DC0078) | Outbound sessions from an application server to unfamiliar hosts after an inbound request, indicating a follow-on channel | Zeek conn.log, Suricata flow metadata, Security Onion session views |
| Platform scope | Containers, ESXi, IaaS and Linux hosts all expose the same application sensors, but host agent coverage differs by platform | Confirm agent support for each platform in the environment before relying on Process Creation coverage |
| Version alignment | Detection strategy and data component IDs changed in ATT&CK v18, released October 28, 2025, so mappings should name the version targeted | Record the ATT&CK version in each rule's metadata and re-check mappings after each release |
Detection ideas for T1190 across web apps, containers and hypervisors
T1190 usually shows up as a change in how a public-facing service behaves: it runs something it never ran, accepts content it should reject, talks to hosts it never contacts, or starts throwing errors from one source. Each idea below pairs a signal with the telemetry that reveals it, the thresholds to tune, and the benign activity that will trigger it.
Unexpected child processes from services
A web server, application runtime or container entrypoint should rarely spawn a shell, package manager or download utility. Alert on Process Creation events where the parent is a service process and the child is an interactive shell or network tool, and tie the event to the container or host identity. Tune by allowlisting known health-check and deployment hooks. Expect false positives from configuration management runs, cron-driven maintenance and scheduled database dumps, so confirm the change window before escalating.
Anomalous inbound request content
IDS and WAF signatures can flag payloads that carry command syntax, template expressions or serialized objects in request parameters and headers. Feed Suricata or Zeek HTTP logs and Network Traffic Content into Security Onion or Wazuh, then group matches by URI and source. Start with high-severity rulesets and raise the threshold for repeated hits from one address. Vulnerability scanners, penetration tests and load testing tools generate the same content, so keep an approved source list and a scan calendar.
New outbound connections from servers
Public-facing servers that normally only answer inbound requests should not open new connections to the internet or to unfamiliar internal hosts after an exploit. Baseline destination addresses and ports per workload using Network Connection Creation data, then alert on first-seen destinations from web tiers. Set a learning period before alerting, and review hosts that call package mirrors, certificate authorities and monitoring endpoints. Patch rollouts, DNS refreshes and cloud metadata calls are common benign sources.
Application error spikes from one source
Exploit attempts often produce bursts of 4xx and 5xx responses, parser exceptions and stack traces from a single address or user agent. Use Application Log Content to count errors per source over a short window, and alert when one source exceeds a baseline you set from normal traffic. Tune the window and the ratio against each application's error profile. Load balancer health checks, misconfigured clients after a release and bot crawlers can produce the same pattern, so exclude known health-check sources first.
How to validate that T1190 detections fire
This sequence proves, in a private cyber range or isolated lab, that each T1190 detection receives the telemetry it depends on, fires on a benign test, and is recorded against a named ATT&CK version so the results can be repeated and audited. It turns a rule that looks correct on paper into evidence that the detection works in your environment.
Agree scope and rules with the asset owner
Before any test traffic is generated, the security lead and the owner of the public-facing application agree in writing which hosts, containers, ESXi hosts, IaaS instances and Linux services are in scope, which test payloads are allowed (benign, non-destructive markers only), which time windows apply and who can stop the test. The owner also confirms that the target is a lab copy or a cyber range replica, not production. The output is a signed scope note that names the ATT&CK version targeted, for example Enterprise ATT&CK 20.0, so every later result can be traced to a specific technique definition. Ask the vendor or your own platform team to confirm which data components and detection strategies that version references for T1190.
Build the isolated lab or cyber range target
Stand up a replica of the public-facing stack in an isolated network segment, using the same reverse proxy, web application, container runtime, hypervisor and Linux service versions as production where possible. The segment has no route to production data or the internet, and egress is limited to the monitoring path. Label every asset with its role so logs can be matched to test activity later. The output is a lab inventory and a network diagram showing where Network Connection Creation, Network Traffic Content and Process Creation sensors sit, which confirms that the sensors can see the traffic the detections need.
Confirm that telemetry reaches the monitoring stack
Before testing detections, check that each required data source arrives in the SIEM or data lake with the expected fields. Typical open-source paths include Wazuh agents for host process and log data, Zeek or Suricata sensors on the lab network for connection and content metadata, and Velociraptor or Sysmon-equivalent process logging on Linux hosts. For each data component, a team member generates a harmless request or process event and searches for it. Record the source, the ingestion time and any missing fields. Telemetry is confirmed only when the event appears with the fields the rule reads, such as source address, destination port, user agent, parent process and command-line field names. Gaps are logged as blockers, not silently skipped.
Run benign exploit-pattern tests against the target
A tester, working under the agreed scope, sends benign test requests that mimic the shape of exploitation attempts against the lab application, such as malformed inputs, unexpected parameters and known harmless test strings used by web scanners and detection teams. The tests do not carry working exploit code, do not change system state and are run from a single documented source host. Each test is logged with a unique marker and a start and end time. The output is a test log that a second person can reconcile against the sensor logs, so the detection outcome can be compared with what was actually sent.
Check that each detection rule fires
For each T1190 detection (for example, rules for anomalous inbound requests to the web tier, suspicious child processes spawned by a web service, or unexpected outbound connections from a container), the analyst confirms that the rule produced an alert for the matching test marker. Use the rule identifiers from your Sigma or SIEM repository and record the rule version, the alert ID and the alert timestamp. A rule passes when it fires on the intended test, and a second rule-negative test (benign traffic that should not match) stays silent. Any rule that does not fire is marked as failed and is not counted as covered until the cause is found, whether it is a missing field, a wrong index, a time zone mismatch or a logic error.
Record timestamps, hit rates and tuning changes
Build a results table with one row per test and per rule. Columns capture the test marker, the time the request was sent, the time the sensor saw it, the time the alert was created, whether the alert fired, false positive counts from benign traffic, and any tuning change with its reason and author. Hit rate is the share of intended tests that produced an alert, and it is reported next to the number of tests run so readers can judge its weight. Store the table, the rule versions and the raw logs as evidence. The output is a validation report that names the ATT&CK version used, the data components relied on and the open items.
Re-run after tuning and version changes
When a rule is tuned or the detection content is updated, repeat the affected tests on the same lab target and compare the new results with the baseline. Re-run the full set after a change to the ATT&CK version used for mapping, because releases can rename, deprecate or revoke techniques and change detection guidance. Confirm the detection still maps to the current technique and sub-technique IDs in the ATT&CK STIX bundle for the targeted version. The output is a dated revalidation record that a compliance or audit reviewer can read without needing the original analyst, and it feeds the next scheduled review of the response runbook.
How detections for public-facing exploitation fit together
The core idea is that no single sensor proves T1190 Exploit public-facing application on its own, so the detection is built from three layers that describe the same request from different angles. Network sensors such as Zeek or Suricata see the inbound request and its content, which maps to the Network Traffic Content (DC0085) data component. Host and container telemetry (Process Creation, DC0032, and Network Connection Creation, DC0082) shows what the exposed service process does next, such as spawning a shell, opening an outbound connection or writing a new file. Application logs (Application Log Content, DC0038) record the request path, status codes and errors as the application itself understood them. Each layer is incomplete alone: the network sensor may be blind to encrypted payloads, the host may not see the request at all, and the application log may omit the malicious parameter entirely.
Correlation is what makes the detection usable on exposed workloads, which generate constant scanning noise. A useful pattern is to alert only when an inbound request matching a suspicious content signature is followed, within a short and documented window, by an unexpected child process or outbound connection from the same workload, with an application error or unusual status code in between. Illustrative example: a web scanner probing a login endpoint produces many inbound alerts and no process activity, so it stays a low-priority event, while one request that is followed by a shell spawned under the web server account raises a high-priority incident. Your team should confirm that the Wazuh, Security Onion or SIEM pipeline it uses can join these sources on host identity and time, and that clock synchronization across containers and ESXi hosts is reliable enough for the window to mean anything.
Because ATT&CK content is published as STIX 2.1 in the mitre-attack/attack-stix-data repository, with one bundle per domain and version, detection mappings should name the exact bundle they target, such as the Enterprise ATT&CK 20.0 bundle. This matters because releases can rename, deprecate or revoke techniques and data components, so a rule written against an older version may silently lose its mapping. Record the ATT&CK version in each detection's metadata, review the mapping whenever a new release is adopted, and keep a change log so auditors can trace which coverage claim applied on which date.
Controls that reduce T1190 exposure: Update Software and Network Segmentation
T1190 Exploit public-facing application succeeds when a reachable service runs a flaw the adversary can trigger. The two focus controls, Update Software and Network Segmentation, shrink that window and limit what an attacker can reach after a foothold. The supporting controls reduce what a successful exploit can do.
Update Software (M1051)
This mitigation covers patching and upgrading the internet-facing components your teams operate, including web servers, reverse proxies, application frameworks, container base images and appliance firmware. Exploits against public services often target flaws that already have vendor fixes, so the gap between a patch release and deployment is the exposure window. Confirm that you can inventory every public endpoint and its exact version, that critical fixes have a defined deployment path, and that you can roll back. Ask your vendors which advisories they publish for each component.
Network Segmentation (M1030)
Segmentation restricts which systems a public-facing service can open connections to and which systems can reach it. If an exploit lands on a web tier, the attacker should not be able to freely reach databases, identity services or management interfaces. Confirm that the public tier sits in its own network zone, that east-west and outbound rules are explicit and deny by default, and that administrative paths do not traverse the public zone. Validate these rules in the cyber range, because documented rules often differ from what is deployed.
Restrict Web-Based Content (M1021)
This supporting mitigation limits the web content and resources that a service will accept or load, for example through request filtering, content policies and restrictions on dangerous file types and methods. It can block common exploit patterns before they reach application code. Confirm which rules run at the edge, which run in the application, and who tunes them. Treat filters as a layer, not a substitute for patching, and test that legitimate traffic still passes.
Application Isolation and Sandboxing (M1048)
Isolation limits what a compromised application process can access on the host or within its container. Run public services with least privilege, separate filesystem and credential scope, and restricted system calls where the platform supports them. Confirm that service accounts cannot read secrets belonging to other workloads and that containers do not run privileged by default. Verify these settings against the actual deployed workloads, not only the templates.
Exploit Protection (M1050)
Exploit protection refers to platform defenses that make memory corruption and similar flaws harder to turn into code execution, such as memory protections and runtime hardening. These controls buy time but do not remove the underlying vulnerability. Confirm which protections your operating systems and runtimes enable by default, which are disabled for compatibility, and how exceptions are approved and reviewed.
What to do when a T1190 detection fires
When a T1190 detection fires, the first decision is whether the alert reflects a real exploitation attempt against the affected service or a false positive, and that check should be done with the application owner on the line. Confirm the request path, the vulnerable component and the version actually running, then compare the alert against the service's recent deployments and change records. Treat a confirmed match as a possible compromise of the workload until the logs show otherwise. Do not wait for a full forensic picture before containing the service, because an exploited web tier can pivot quickly into the internal network.
Containment should be the smallest action that stops the attack path. Where the platform allows it, restrict the workload's network path first: tighten the ingress rule, pull the instance or pod from the load balancer, or block the specific request pattern at the web application firewall, and keep the service in a state the application owner can still investigate. Before any restart or redeploy, preserve evidence: copy web server and reverse proxy access and error logs, export container runtime state and the image digest, and capture memory from a virtual machine where your tooling supports it. Then check for new processes spawned by the service account, unexpected outbound connections, and new files written in web-accessible or temporary paths. Record what you checked, when, and by whom.
The rebuild or patch decision should follow the evidence. If there is no sign of post-exploitation activity and the vulnerable version can be fixed quickly, patch the component through your normal change process and verify the fix with a repeat test. If there is any sign of code execution, webshells or credential access, rebuild the workload from a known-good image and rotate the secrets the service could read, because patching a compromised host does not remove an implant. Coordinate scope with application owners before you declare recovery: confirm every instance, replica and environment that runs the same component, check whether a shared library or base image is affected, and agree on the evidence that closes the incident. Recovery is declared only when that scope is confirmed in writing.
Rehearsing T1190 detection and response in a private cyber range
The web tier is usually the first environment a team rehearses because the exposed surface is easiest to describe. The range should mirror the production path: an internet-facing reverse proxy or load balancer, the application server, and a backend database, all on isolated segments with the same logging forwarded to a Wazuh or Security Onion collector. Facilitators can plan injects that send malformed requests with unusual parameters to a deliberately vulnerable test build, then have a simulated attacker pivot from the application process to the host. Good detection means the network sensor and the web access log raise an alert within the agreed window, the alert names the correct application and host, and the context includes the source address, the requested path, and the response code. Good response means the on-call engineer isolates the affected instance from its database credentials, preserves the logs, and notifies the application owner and the incident lead using the agreed channel. Ask your team which web server and proxy logs are retained in your environment and for how long before scheduling the exercise.
A container platform range needs a cluster that matches your production topology, including the ingress controller, a sample workload exposed through it, and the node-level agent that reports process and network events. Facilitators can plan an inject where a request to the exposed service results in an unexpected process starting inside the workload container, and a second inject where the same workload opens an outbound connection to a host it has no reason to reach. Good detection means the process creation event is tied to the correct pod, namespace and image, and the network event carries the workload identity rather than only a node address, so the responder does not have to reconstruct the mapping under pressure. Good response means the team scales the deployment to zero or applies a network policy that drops the workload's egress, preserves the container image digest and logs, and checks whether other replicas share the same exposure. Confirm with your platform team which runtime event sources and admission controls are available in your chosen distribution before you write the inject script.
An ESXi range tests whether the team can detect exploitation of a management or workload-facing service on a hypervisor, a case where the blast radius is large and the telemetry is thinner. The range should include a lab host with a management interface reachable only from a segregated administration network, a syslog destination, and a network sensor placed on the management segment so that traffic to the host is visible. Facilitators can plan injects that generate unusual connection attempts to the management interface from a workstation that is not on the approved administration list, followed by a configuration change recorded in the host logs. Good detection means the network sensor flags the connection to the management address, the alert identifies the host by name and management address, and the context shows the source, the time, and whether the source was on an approved list. Good response means the team restricts management access at the segmentation layer, confirms the host state against its last known configuration, and communicates with virtualization administrators before any restart. Ask your vendor and your virtualization team which hypervisor logs they can forward and whether the host can be taken out of service for the exercise.
An IaaS range rehearses an exposed virtual machine in a cloud account or private cloud project, where detection depends on flow logs, host telemetry, and the security group or firewall rules that define what is reachable. The range should use a dedicated test account or project, a Linux workload behind a load balancer, and both cloud flow telemetry and host-level process logging sent to the same collector. Facilitators can plan an inject where a public-facing port receives a burst of requests that do not match the application's expected traffic, followed by an inject where the workload starts a process it does not normally run. Good detection means the alert ties the network event to the correct instance, subnet and security group, and the process event shows the parent process and user, so the responder can judge severity quickly. Good response means the team tightens the security group to block the source, snapshots the instance for forensics before replacing it, rotates any credentials the workload could read, and records the change in the ticket. Confirm which flow log fields your cloud provider exposes and whether snapshots and rule changes are logged in your account before you define pass criteria.
Questions SOC leads ask about detecting T1190
How do I separate vulnerability scanners from real exploitation attempts?
Start by inventorying known scanner sources, such as your own vulnerability management platform and any external assessment vendors, and tag their traffic with a documented allowlist that expires when the scan window closes. Scanners generate high volumes of requests with predictable user agents, paths and timing, while real exploitation usually targets one application version with a short sequence of requests followed by unusual responses or new outbound connections. Correlate web access logs with process creation on the application host, because a request that spawns a shell or writes a new file is far more meaningful than one that only returns an error code. Expect allowlists to need review every time scanning schedules or tooling change, and confirm that the allowlist itself is logged and approved.
Should network or host telemetry come first for T1190 detection?
Collect both, but start with the telemetry that sees the application boundary and the host that runs it. Network connection creation and network traffic content from sensors such as Zeek or Suricata show inbound requests and anomalous outbound sessions, which helps when the host is ephemeral or unmanaged. Process creation on the application server shows what the exploited service did after the request, and that is often the clearest signal of success. A practical order is to alert on host process anomalies first because they carry lower noise, then use network content to explain how the request arrived. Confirm that your sensors cover the east-west and ingress paths where the application actually sits.
How do I handle encrypted traffic when inspecting public-facing applications?
Terminate TLS at a point you control, such as a reverse proxy or load balancer, and log the decrypted request metadata there, because payload inspection is impossible once traffic reaches the application encrypted. Where TLS termination is not possible, rely on connection metadata, certificate anomalies, request timing and the host-side telemetry described above. Be deliberate about where decrypted content is stored, since request bodies may contain credentials or personal data and your retention rules apply. Confirm with your security and privacy teams which fields may be logged, and test the decryption path in a cyber range before production traffic depends on it.
How do I tune detections for containers that restart often?
Key your detections on stable identifiers such as the service name, image reference and deployment label instead of container IDs, which change on every restart. Treat a short-lived container that starts a shell or opens an unexpected outbound connection as a finding in its own right, because attackers do not need the container to persist. Forward container runtime and orchestrator logs to a central store so events survive the container's lifetime, and set alert thresholds on the workload group rather than individual instances. Restarts caused by normal rollouts will create noise, so correlate alerts with your deployment pipeline events before paging anyone. Validate the tuning by replaying a rollout in your cyber range.
How often should detection rules be re-mapped to new ATT&CK versions?
Re-map on every ATT&CK release you adopt, and record the version each rule targets in its metadata. MITRE publishes ATT&CK releases on a regular schedule, and recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, and ATT&CK v18 moved detections into detection strategies and analytics, so a rule mapped to an old technique page may silently lose its reference. Review the ATT&CK updates page when each release lands, diff the STIX bundle for your domain, and update your coverage matrix before the next assessment.
What should I confirm before relying on a T1190 detection rule?
Confirm four things before a rule pages anyone: the telemetry it depends on actually arrives, the rule fires against a known test event, the false positive rate is acceptable for your traffic, and the response playbook names an owner. Check that web logs, host process events and sensor output are present and time-synchronized, because a silent data source looks like a clean environment. Replay a benign scanner run and a controlled exploitation test in a private cyber range, and record what the rule caught and missed. Document the ATT&CK version the rule targets and the mitigations you rely on, including Update Software and Network Segmentation. Ask your detection engineering team or implementation partner to show the validation evidence, not just the rule file.
Can my own team run this detection work without an outside partner?
Many teams can run it in-house if they already operate a log pipeline, a SIEM or Wazuh deployment, and a sensor stack, and they have engineers who can write and test detection logic. The recurring work is ongoing: maintaining allowlists, tuning for restarts, re-mapping rules at each ATT&CK release and rerunning validation after application changes. Costs are driven by staff time, the size of the internet-facing estate, the number of applications and how often they change. An outside partner can handle scoping, cyber range rehearsals and validation as a fixed-scope engagement, with ongoing support available as a retainer. Ask any provider for a written scope listing the applications, telemetry sources and deliverables before comparing quotes.
How DeployOpen builds T1190 detections and range scenarios
DeployOpen starts every T1190 engagement by agreeing a written scope that names the public-facing applications, APIs, load balancers and reverse proxies in play, the environments they run in (cloud accounts, data center segments or air-gapped networks inside the client's own estate), and the ATT&CK version the detection mappings will target. Because ATT&CK releases can rename, deprecate or revoke techniques, the scope should state the version explicitly. The first working session usually inventories internet-facing entry points, the logs each one produces, and which of those logs already reach the SIEM, so that detection gaps are visible before any exercise is designed. Fixed scope means the deliverables, the systems covered and the acceptance checks are agreed in writing up front, and anything outside them is handled as a separate change.
Purple team exercises for this technique are planned around the telemetry the client actually has. Typical decisions include which web server access logs, WAF events, application error logs and container or host process records are forwarded, how long they are retained, and whether the team can correlate a request in the proxy with the process that handled it. DeployOpen's range scenarios are built in a private cyber range inside the client's infrastructure, mirroring the production versions of the application, reverse proxy and runtime. Scenarios are described as defined events the blue team must detect and triage, and each one is written against the named data components, such as Network Traffic Content for request payloads and Process Creation for unexpected child processes on the application host. Clients should confirm with DeployOpen which scenarios touch production-like systems, who approves each run and where the results are stored.
