T1190: Exploit Public-Facing Application
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Exploited applications are often websites/web servers, but can also include databases (like SQL), standard services (like SMB or SSH), network device administration and management protocols (like SNMP and Smart Install), and any other system with Internet-accessible open sockets.CitationNVD CVE-2016-6662CitationCIS Multiple SMB VulnerabilitiesCitationUS-CERT TA18-106A Network Infrastructure Devices 2018CitationCisco Blog Legacy Device AttacksCitationNVD CVE-2014-7169 On ESXi infrastructure, adversaries may exploit exposed OpenSLP services; they may alternatively exploit exposed VMware vCenter servers.CitationRecorded Future ESXiArgs Ransomware 2023CitationArs Technica VMWare Code Execution Vulnerability 2021 Depending on the flaw being exploited, this may also involve Exploitation for Stealth or Exploitation for Client Execution.
If an application is hosted on cloud-based infrastructure and/or is containerized, then exploiting it may lead to compromise of the underlying instance or container. This can allow an adversary a path to access the cloud or container APIs (e.g., via the Cloud Instance Metadata API), exploit container host access via Escape to Host, or take advantage of weak identity and access management policies.
Adversaries may also exploit edge network infrastructure and related appliances, specifically targeting devices that do not support robust host-based defenses.CitationMandiant Fortinet Zero DayCitationWired Russia Cyberwar
For websites and databases, the OWASP top 10 and CWE top 25 highlight the most common web-based vulnerabilities.CitationOWASP Top 10CitationCWE top 25
Security context for executives and security teams
T1190 matters because an Internet-facing weakness can become the first doorway into the enterprise, cloud, container, virtualization, or network-device environment. For leaders, the practical question is not only “are we patched?” but “do we know every exposed service, can we prove it is hardened, and would we see exploitation followed by abnormal process activity or outbound traffic?”
Executive priority
Treat public-facing application and service exposure as a resilience and governance priority. This technique is linked in ATT&CK to campaigns involving espionage, ransomware, network appliances, ESXi/vCenter exposure, and even a cyber-physical heating disruption context. Prioritize evidence that externally reachable systems are inventoried, scanned, updated, access-restricted, segmented from critical assets, and monitored well enough to support rapid incident decisions.
Technical view
This is an initial-access technique across Containers, ESXi, IaaS, Linux, macOS, Network Devices, and Windows. ATT&CK provides no native detection text, but the related detection strategy DET0080 points to multi-signal correlation: suspicious request activity, application or service errors, then post-exploitation process execution or egress. SOC and IR teams should validate coverage for websites/web servers, databases, SMB/SSH-style services, network administration protocols, exposed ESXi OpenSLP or vCenter services, cloud-hosted applications, and containerized workloads. Pay special attention to edge devices that may not support robust host-based defenses.
Likely telemetry
- Authoritative external asset and exposed-service inventory
- Vulnerability scan and patch status for Internet-facing systems
- Web server, reverse proxy, load balancer, and application logs
- Database and standard service logs where services are Internet-accessible
- Firewall, IDS/IPS, VPN, and network device administration logs
Detection direction
- Validate correlation from inbound request or connection to application/service error conditions, then to unusual child processes, credential access indicators, API access, or outbound connections.
- Tune detections around known exposed assets first; unknown Internet-facing sockets are a major blind spot for this technique.
- Separate expected scanner noise and routine application errors from sequences that include post-exploitation behavior or unexpected egress.
- For network appliances and edge infrastructure, confirm whether logs are centralized because host-based EDR may be unavailable or limited.
- For cloud and containers, look for exploitation paths that could expose instance metadata, container APIs, or weak IAM boundaries, as described by ATT&CK.
Mitigation priorities
- Start with complete exposure management: identify all Internet-facing applications, services, sockets, network devices, ESXi/vCenter services, cloud workloads, and containerized applications.
- Use M1016 Vulnerability Scanning to find misconfigurations and unpatched software, then prioritize remediation by business exposure and impact.
- Use M1051 Update Software to patch operating systems, applications, drivers, firmware, and externally exposed platforms.
- Apply M1035 Limit Access to Resource Over Network and M1037 Filter Network Traffic so only required sources and protocols can reach public services.
- Use M1030 Network Segmentation to limit movement from exposed systems to sensitive internal, cloud, or operational environments.
Additional notes and limits
The ATT&CK object is broad by design: it covers exploitation of Internet-facing software bugs, glitches, and misconfigurations across web, database, standard services, network devices, ESXi, cloud, and container environments. The relationship set reinforces that this behavior appears across many campaign types, including espionage, ransomware, edge appliance exploitation, and one cyber-physical incident context, but those relationships should guide defensive prioritization rather than imply local exposure.
Official ATT&CK detection guidance for this object is not provided. Local conclusions require asset inventory, exposure data, vulnerability status, architecture, and telemetry validation. This take does not assert active exploitation, specific adversary targeting, or guaranteed detection coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Exploit Public-Facing Application
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Exploited applications are often websites/web servers, but can also include databases (like SQL), standard services (like SMB or SSH), network device administration and management protocols (like SNMP and Smart Install), and any other system with Internet-accessible open sockets.CitationNVD CVE-2016-6662CitationCIS Multiple SMB VulnerabilitiesCitationUS-CERT TA18-106A Network Infrastructure Devices 2018CitationCisco Blog Legacy Device AttacksCitationNVD CVE-2014-7169 On ESXi infrastructure, adversaries may exploit exposed OpenSLP services; they may alternatively exploit exposed VMware vCenter servers.CitationRecorded Future ESXiArgs Ransomware 2023CitationArs Technica VMWare Code Execution Vulnerability 2021 Depending on the flaw being exploited, this may also involve Exploitation for Stealth or Exploitation for Client Execution.
If an application is hosted on cloud-based infrastructure and/or is containerized, then exploiting it may lead to compromise of the underlying instance or container. This can allow an adversary a path to access the cloud or container APIs (e.g., via the Cloud Instance Metadata API), exploit container host access via Escape to Host, or take advantage of weak identity and access management policies.
Adversaries may also exploit edge network infrastructure and related appliances, specifically targeting devices that do not support robust host-based defenses.CitationMandiant Fortinet Zero DayCitationWired Russia Cyberwar
For websites and databases, the OWASP top 10 and CWE top 25 highlight the most common web-based vulnerabilities.CitationOWASP Top 10CitationCWE top 25
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.