Overview

Exploit Public-Facing Application (T1190) describes adversaries gaining initial access by attacking a vulnerability — a software bug, misconfiguration, or unpatched CVE — in any internet-exposed service. Targets range from web applications and databases to SSH servers, VPN appliances, ESXi hosts, and containerized workloads. A successful exploit gives the attacker a foothold inside the perimeter without needing credentials.

This technique is one of the most common initial access vectors observed in real-world incidents, including ransomware campaigns, nation-state intrusions, and supply chain attacks. Because exploitation happens against a legitimate service, it often blends into normal traffic until a post-exploitation action triggers an alert — making early detection absolutely critical for limiting dwell time.

Attacker Perspective

Attackers systematically probe internet-facing services for known and zero-day vulnerabilities, then weaponize findings to land an initial shell or extract data before any defender responds.

• Web application SQL injection: Automated tools like sqlmap --dbs --batch -u https://target.com/login?id=1 enumerate databases, dump credentials, and in some configurations achieve OS command execution via xp_cmdshell or INTO OUTFILE.
• Remote code execution via unpatched CVEs: Public exploits for vulnerabilities like Log4Shell (CVE-2021-44228), ProxyShell (CVE-2021-34473), or Citrix Bleed (CVE-2023-4966) are packaged into exploit frameworks like Metasploit or standalone PoC scripts and run within minutes of target identification.
• VPN and edge appliance exploitation: Tools like nuclei -t cves/ -u https://vpn.target.com scan for known weaknesses in Fortinet, Pulse Secure, and Ivanti devices, often yielding pre-auth credential theft or arbitrary file read leading to session hijacking.
• Container and cloud metadata abuse: After exploiting a containerized app, attackers issue curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ to harvest instance role credentials, pivoting directly into cloud APIs without ever touching endpoint defenses.

This technique is attractive because it requires no insider access or phishing — a single vulnerable service exposed to the internet is all an attacker needs to begin a full intrusion chain.

Detection Strategy

Required Telemetry

• Web server access logs (all platforms): Must include full URI with query string, HTTP method, response code, response size, User-Agent, source IP, and server-side processing time. For Apache/Nginx, ensure combined or json log format is configured and logs are shipped to your SIEM. For IIS, enable W3C logging with cs-uri-query, sc-status, sc-bytes, and time-taken fields.
• Application error logs (Linux/Windows): JVM applications must have LOG_LEVEL=ERROR or above enabled and logs forwarded. Look for FileNotFoundException, stack traces containing user-controlled input, and exception messages referencing path traversal strings.
• Database query logs (Linux/Windows/cloud): For MySQL, enable the general query log (SET GLOBAL general_log = 'ON';) or slow query log. For MSSQL, enable SQL Server Audit or Extended Events. For PostgreSQL, set log_statement = 'all' in postgresql.conf. Logs must include the full query text, source IP, and executing database user.
• Linux SSH daemon logs: Ensure sshd logs to syslog/journald and that logs are forwarded to the SIEM. On rsyslog: confirm /etc/rsyslog.d/ includes SSH facility. On systemd: use journalctl -u sshd output shipped via a log agent such as Filebeat or Fluentd.
• Linux process execution (auditd or eBPF): Deploy auditd with rules targeting execve syscalls: -a always,exit -F arch=b64 -S execve -k exec_log. Alternatively, use osquery, Falco, or an EDR agent to capture process name, PID, PPID, command line, and spawning user. This is essential for detecting shells spawned by web server or database processes.
• Windows process creation (Event ID 4688 or Sysmon Event ID 1): Enable process creation auditing via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. For full command-line capture, also enable: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Sysmon Event ID 1 provides richer data including hashes and parent command line — deploy Sysmon with the SwiftOnSecurity or Olaf Hartong config baseline.
• Network flow and proxy logs: Enable NetFlow/IPFIX on edge devices or use VPC flow logs (AWS/Azure/GCP). Capture source IP, destination IP, port, bytes transferred, and connection duration. Web proxy logs should record full URLs including query strings.
• Cloud metadata and API logs: For AWS, enable CloudTrail with data events for S3 and EC2 metadata API calls. For Azure, enable Azure Monitor and Diagnostic Logs. For GCP, enable Cloud Audit Logs. These are critical for detecting post-exploitation metadata service abuse.
• Container runtime logs (Kubernetes/Docker): Use Falco or an equivalent runtime security tool to capture syscall-level events within containers. Ship Kubernetes audit logs (enable via --audit-log-path in the API server configuration) to catch unexpected exec calls into running containers (kubectl exec).
• ESXi/vCenter logs: Forward ESXi host syslog to the SIEM (esxcli system syslog config set --loghost=udp://siem:514). Capture vCenter Server events via the vSphere API or native syslog forwarding. Focus on OpenSLP service errors and authentication events.

Key Indicators

• Web server spawning interactive shells: In process logs, check parent_process_name = httpd, nginx, w3wp.exe, tomcat, or java and process_name = cmd.exe, powershell.exe, bash, sh, or python. This is the single highest-fidelity indicator of web application RCE.
• Database process spawning OS commands: Check parent_process_name = sqlservr.exe, mysqld, or postgres and child process_name = cmd.exe or xp_cmdshell-related activity in SQL logs. In MSSQL audit logs, look for statement containing xp_cmdshell or EXEC master..xp_cmdshell.
• SQL injection patterns in HTTP request logs: In web access logs, check cs-uri-query or the URI field for patterns: UNION+SELECT, OR+1=1, '; DROP TABLE, SLEEP(, WAITFOR DELAY, BENCHMARK(. These are classic SQLi payloads delivered via GET/POST parameters.
• Path traversal in URIs: In web access logs, check the URI field for ../, %2e%2e%2f, %252e%252e%252f (double-encoded), or ....//. A response code of 200 on a path traversal request is critical — a 404 or 400 may indicate probing rather than success.
• Bulk HTTP errors from a single source IP: In web server logs, high volumes of status_code = 400, 403, 404, or 500 from a single src_ip within a short time window strongly suggest automated scanning or exploit fuzzing.
• SSH exploit error messages: In sshd logs, look for messages containing unexpected internal error, fatal: buffer_get_string: bad string, Local: crc32 compensation attack, or Corrupted MAC on input. These are emitted by the OpenSSH daemon when malformed exploit payloads are processed.
• JVM path traversal exceptions: In JVM application error logs, check for events where both FileNotFoundException and a string matching /../../.. appear in the same log entry — this strongly suggests a local file read exploit attempt against the application.
• Outbound connections from web/database processes: In network flow logs, check for connections where initiating_process = a web or database process and dest_port = 4444, 1337, 8080, or other non-standard ports, particularly to external IPs. Web servers should rarely initiate outbound connections.
• Cloud metadata API access from unexpected processes: In process logs on cloud instances, flag any process other than known cloud agents making HTTP requests to 169.254.169.254 or fd00:ec2::254 (AWS), 169.254.169.254 (Azure/GCP). In VPC flow logs, look for flows to these destinations from application servers.
• Unusual User-Agent strings: In web access logs, check cs(User-Agent) for known scanner signatures: sqlmap, nuclei, Nikto, zgrab, python-requests combined with exploit-like URIs, or empty/null User-Agent on non-API endpoints.

Detection Logic

Rule 1 — Web/DB Server Spawning Shell Process (High Precision, Low Volume):
IF parent_process_name IN ["httpd","nginx","w3wp.exe","tomcat","java","php-fpm","sqlservr.exe","mysqld","postgres"] AND process_name IN ["cmd.exe","powershell.exe","bash","sh","dash","python","python3","perl","ruby","nc","ncat"] AND NOT (process_name = "bash" AND parent_process_name = "httpd" AND command_line CONTAINS "graceful") THEN alert HIGH

This catches the post-exploitation shell spawn that follows a successful RCE exploit. Alert volume should be very low in a well-baselocked environment — any hit warrants immediate investigation. The exclusion prevents false positives from Apache graceful restart scripts.

Rule 2 — SQL Injection Patterns in HTTP Logs (Broad, Medium Volume):
IF log_source = "web_access" AND (uri_query MATCHES "(?i)(UNION.{0,10}SELECT|OR.{0,5}1=1|'; DROP|SLEEP\(|WAITFOR DELAY|BENCHMARK\(|xp_cmdshell|INTO OUTFILE|LOAD_FILE)" OR uri_query MATCHES "(%27|%22|%3B|%2D%2D)") AND NOT src_ip IN [known_scanner_ips, vulnerability_management_hosts] THEN alert MEDIUM

Catches automated SQL injection tooling and manual exploit attempts. Expect moderate volume — tune heavily using the exclusion list for your vulnerability scanning tools and pentest IP ranges. Escalate any MEDIUM alert where the HTTP response code was 200 and response bytes were significantly larger than the baseline for that endpoint.

Rule 3 — High Error Rate Spike from Single Source (Broad, Behavioral):
IF log_source = "web_access" AND COUNT(events) WHERE src_ip = X AND status_code IN [400,403,404,500] > 100 WITHIN 60 seconds AND NOT src_ip IN [known_scanner_ips, load_balancer_ips, cdn_ranges] THEN alert MEDIUM

Detects automated exploit scanning and fuzzing before a successful hit. High volume alert — critical for early warning but requires good exclusion lists. Pair with threat intelligence enrichment on the source IP to prioritize.

Rule 4 — JVM Application Local File Read Exception (High Precision):
IF log_source = "application" AND product = "jvm" AND log_level IN ["ERROR","FATAL"] AND message CONTAINS "FileNotFoundException" AND message MATCHES "(/\.\./|%2e%2e%2f|\.\.%2f)" THEN alert HIGH

Directly implements the community Sigma rule for path traversal against JVM applications. Low expected volume — a FileNotFoundException containing traversal sequences almost always indicates a real exploit attempt or at minimum a critical application bug requiring immediate review.

Tuning Guidance

• Vulnerability scanners and authorized pentests: Tools like Tenable, Qualys, Rapid7, or Burp Suite proxy will trigger virtually every web-based detection rule. Maintain a documented list of scanner IP ranges and pentest windows. Add exclusion: src_ip IN [vuln_scanner_ips] and suppress alerts during scheduled scan windows using a time-based filter. Critically, never suppress the shell-spawn rule — scanners should not be executing code on your servers.
• Load balancers and health checks: Internal load balancers and CDN health probes generate repetitive HTTP traffic that can trip the high-error-rate rule. Exclude: src_ip IN [load_balancer_ranges, cdn_ip_ranges] and uri_path IN ["/health", "/ping", "/status"].
• Legitimate application error logging: Some applications generate FileNotFoundException or SQL errors during normal operation due to missing optional config files or empty database returns. Baseline your application’s normal error rate and add exclusions: message CONTAINS "config_optional.xml" or known benign query patterns. Escalate only when error content matches traversal sequences or injection patterns.
• Development and staging environments: Developers frequently run sqlmap, Nikto, or custom scripts against non-production environments. Segment your SIEM data by environment tag and consider separate, less sensitive alert thresholds for dev/staging. Never reduce sensitivity on production internet-facing assets.
• Web application frameworks with verbose errors: Frameworks like Django (DEBUG=True), Laravel, or older Spring Boot configurations expose stack traces and internal paths in HTTP 500 responses. These can generate high volumes of JVM/application error detections. Confirm the application is properly configured for production (debug mode off) and exclude known internal error message patterns once confirmed benign.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. Pull the exact log entry from your SIEM — check the raw web access log, database query log, or process event to confirm the suspicious field values match what the rule fired on. Do not proceed based on the alert summary alone; verify the original uri_query, command_line, or message field contains the actual indicator.
2. Identify the affected host, service, and source IP. Confirm the hostname or IP of the targeted server, the specific application or service that was hit, and the attacking source IP. Immediately run the source IP through threat intelligence (VirusTotal, Shodan, AbuseIPDB) and check whether it belongs to a known scanner, APT infrastructure, or Tor exit node — this directly informs severity.
3. Determine whether the exploit was successful by checking the HTTP response or database output. In web access logs, check status_code — a 200 response to a SQLi or path traversal request is a red flag; a 403 or 404 may indicate a failed attempt. For database alerts, check whether the query in the database query log returned rows or triggered an error. For shell-spawn alerts, success is self-evident — move immediately to step 4.
4. Pull the full process tree and timeline for any spawned processes. Using your EDR, Sysmon Event ID 1 logs, or auditd logs, retrieve the full parent-child process chain from the web or database process forward. Capture command_line, user, pid, ppid, working directory, and file hashes for every process in the chain. Look specifically for reconnaissance commands like whoami, id, ifconfig, net user, or download cradles like curl, wget, or PowerShell IEX.
5. Check for network connections and files written to disk by the exploited process. In network flow logs, filter on the affected host and look for any outbound connections initiated after the exploit timestamp — particularly to external IPs on uncommon ports. On the host, use your EDR or auditd file write events to identify any new files dropped by the web/database process user, especially in /tmp, /var/www, C:\Windows\Temp, or web root directories. Hash any files found and check against VirusTotal.
6. Search for lateral movement originating from the compromised host. In network flow logs and authentication logs, look for any new connections from the compromised server to internal hosts — particularly over SMB (port 445), WinRM (port 5985), SSH (port 22), or RDP (port 3389). In Windows Security Event Log, check for Event ID 4648 (explicit credential logon) or 4624 Type 3 logons sourced from the compromised server. In Linux, check /var/log/auth.log or auditd for SSH sessions initiated from the host.
7. Make the escalation decision based on evidence of code execution or data access. Treat the incident as confirmed and escalate to P1 if you observe: a shell spawned by a web/database process, files written to disk by the service account, outbound connections to external IPs post-exploit, or any lateral movement. Downgrade to a lower-severity monitoring case only if the exploit attempt definitively failed (confirmed non-200 response, no matching process events, no file or network activity) — but always document the source IP and CVE for threat intelligence tracking.

Response Playbook

Containment

• Isolate the affected host at the network level immediately upon confirming code execution, but keep the system powered on to preserve volatile forensic evidence (active connections, in-memory artifacts, process list). Use your EDR’s network isolation feature, apply a firewall host policy, or move the VM to an isolated VLAN. Do not shut down the system — this destroys memory forensics.
• Block the attacking source IP at the perimeter firewall and WAF. Add the attacker IP (and any associated /24 if attribution to known malicious infrastructure is confirmed) to your blocklist. If a WAF is in front of the application, add a deny rule for the source IP and any identified malicious User-Agent strings. Update DNS sinkholes if C2 domains have been identified.
• Disable or suspend the service account used by the exploited application if there is any evidence it was used post-exploitation for lateral movement. In Active Directory, use Disable-ADAccount -Identity [account]. In Linux, use usermod -L [username]. For cloud workloads, detach the IAM role from the affected instance immediately via the cloud console or CLI.
• Revoke active sessions and tokens. For web applications, invalidate all active session tokens in the application database or cache (Redis/Memcached). For cloud environments, run aws iam delete-access-key or equivalent to revoke any instance role credentials that may have been harvested. For Kubernetes, rotate ServiceAccount tokens.
• Temporarily take the affected application offline or into maintenance mode if isolation is not immediately possible and active exploitation is ongoing. This is a business decision — coordinate with application owners, but err on the side of stopping the bleeding over maintaining availability when active exfiltration or lateral movement is observed.

Eradication

• Identify and remove all files dropped by the attacker. Review all files created or modified by the web/database service account after the exploit timestamp using EDR file activity logs or auditd. Pay particular attention to web shells (look for .php, .jsp, .aspx files in the web root with recent modification times), binaries in /tmp or C:\Windows\Temp, and cron jobs or scheduled tasks added post-compromise.
• Remove all identified persistence mechanisms. Check for new cron jobs (crontab -l -u www-data, /etc/cron.d/), systemd unit files (/etc/systemd/system/), Windows scheduled tasks (Event ID 4698 in Security log or schtasks /query), Windows services (Event ID 7045 in System log), and registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). Remove any additions made by the attacker.
• Reset all credentials that could have been accessed or used by the attacker. Reset the service account password for the exploited application. If database credentials are stored in the application configuration, rotate them and update the config. If cloud metadata credentials were potentially accessed, rotate all IAM keys and secrets associated with that instance role. Assume any credential accessible to the compromised process is compromised.
• Patch or mitigate the exploited vulnerability before bringing the service back online. Apply the vendor security patch, implement a virtual patch via WAF rule, or disable the vulnerable feature. Do not reconnect the service to the internet on the same codebase that was exploited — this is the most common cause of reinfection.
• Scan all lateral movement targets for indicators of compromise. For every internal host the compromised server connected to during the incident window, run an IOC sweep using your EDR for the hashes, process names, and file paths identified during investigation. Check those hosts for the same persistence mechanisms reviewed above.

Recovery

• Rebuild or restore the affected host from a known-good baseline before reconnecting it to the network. If confidence in the completeness of eradication is less than absolute — re-image the system from a trusted golden image or restore from a pre-compromise snapshot. Reconnect only after the patch or mitigation for the exploited vulnerability has been validated as applied.
• Re-enable the service account and application only after confirming no persistence remains. Conduct a final sweep of cron jobs, scheduled tasks, startup scripts, and installed packages before re-enabling accounts. Have a second analyst verify the sweep independently if the incident severity was P1.
• Monitor the previously affected host, the attacking source IP, and the application for 72 hours post-remediation. Create a temporary high-sensitivity detection rule scoped specifically to the recovered host with a lower alert threshold than normal. Watch for any recurrence of the exploit pattern or any new outbound connections from the application process.
• Rotate any secrets, API keys, or certificates that were accessible on the compromised host even if no direct evidence of access was found — assume compromise if the attacker had execution on the host. This includes database passwords in config files, environment variables, .env files, and any secrets stored in memory-accessible locations.
• Document the full incident timeline and conduct a lessons-learned review. Record the exploit used, the CVE, the time from public disclosure to patch application on your asset, the dwell time, and all attacker TTPs. Use this to update your patch SLA policy, prioritize the affected asset class in your vulnerability management program, and refine the detection rules with any new IOCs or behavioral patterns discovered during the investigation.