T0819: Exploit Public-Facing Application
Adversaries may leverage weaknesses to exploit internet-facing software for initial access into an industrial network. Internet-facing software may be user applications, underlying networking implementations, an assets operating system, weak defenses, etc. Targets of this technique may be intentionally exposed for the purpose of remote management and visibility.
An adversary may seek to target public-facing applications as they may provide direct access into an ICS environment or the ability to move into the ICS network. Publicly exposed applications may be found through online tools that scan the internet for open ports and services. Version numbers for the exposed application may provide adversaries an ability to target specific known vulnerabilities. Exposed control protocol or remote access ports found in Commonly Used Port may be of interest by adversaries.
Analyst context for executives and security teams
This ICS technique matters because internet-facing software can become the first bridge from the public Internet into industrial networks, especially where remote management, visibility, VPN access, firewalls, application servers, or operator/engineering workstations are exposed. The business risk is not just a vulnerable application; it is the possibility that an exposed service provides a path toward systems that support industrial operations.
Executive priority
Leaders should treat this as an exposure-management and resilience question: which ICS-supporting services are reachable from the Internet, why are they exposed, who owns them, how quickly can vulnerable versions be remediated, and what compensating controls exist when operational downtime limits patching. Priority should go to reducing unnecessary exposure, proving segmentation between Internet-facing services and critical process control systems, and maintaining audit-ready evidence of vulnerability scanning, privileged access control, software update decisions, and network boundary rules.
Technical view
MITRE provides no official detection text, platforms, or tactics for T0819, so SOC and IR teams should validate coverage around the assets identified in relationships: workstations, application servers, VPN servers, and firewalls. Practical validation should focus on whether teams can inventory public-facing services, identify exposed versions and known weaknesses, observe inbound access to remote management or control-related services, and correlate exploit-protection, vulnerability scanning, authentication, and network boundary telemetry. The related detection strategy DET0740 indicates detection content exists for this behavior, but local applicability must be confirmed against the actual ICS architecture and exposed services.
Likely telemetry
- External attack surface and asset inventory records for Internet-facing ICS-related services
- Vulnerability scanning results and software/version inventory for exposed applications and network services
- Firewall, VPN server, and boundary device logs showing inbound connections and allowed services
- Application server and workstation logs for web, remote access, authentication, and error activity
- Exploit protection or application isolation alerts where deployed
Detection direction
- Confirm that all public-facing ICS-related applications and services are known, owned, and mapped to business justification.
- Tune monitoring around exposed VPN, firewall, application server, and workstation services without assuming all scanning is malicious; Internet-wide scanning can create noisy false positives.
- Correlate exposed version information with vulnerability scanning results so alerts are prioritized by exploitability and operational criticality.
- Validate whether segmentation logs can show attempted or successful movement from Internet-facing zones toward ICS networks.
- Use the related DET0740 detection strategy as a starting point, but test it against local protocols, remote access patterns, and maintenance windows.
Mitigation priorities
- Start with M0930 Network Segmentation: place Internet-facing services in controlled boundary zones or DMZs and restrict access from enterprise or Internet-facing networks to critical process control systems.
- Use M0916 Vulnerability Scanning to identify exploitable public-facing software and exposed service versions, with care for ICS-safe scanning practices.
- Apply M0951 Update Software through planned maintenance windows, documenting compensating controls where immediate updates are not operationally feasible.
- Strengthen M0926 Privileged Account Management for accounts that administer exposed applications, VPN services, firewalls, and engineering workstations.
- Deploy M0950 Exploit Protection and M0948 Application Isolation and Sandboxing where compatible with the exposed application and operational requirements.
Analyst notes and limits
The ATT&CK relationship context identifies Sandworm Team as using this technique, which is useful for threat-informed prioritization, but it should not be read as evidence that any specific organization is currently targeted or compromised. The key decision value is whether the organization can prove which ICS-adjacent services are exposed, whether known weaknesses are being tracked, and whether segmentation prevents a public-facing compromise from becoming an industrial operations incident.
The supplied ATT&CK object has no official detection guidance, no specified tactics, and no platform list for the technique itself. Platform references come only from related ICS assets. Local architecture, asset inventory, vulnerability data, and boundary telemetry are required to assess exposure and coverage.
Exploit Public-Facing Application
Adversaries may leverage weaknesses to exploit internet-facing software for initial access into an industrial network. Internet-facing software may be user applications, underlying networking implementations, an assets operating system, weak defenses, etc. Targets of this technique may be intentionally exposed for the purpose of remote management and visibility.
An adversary may seek to target public-facing applications as they may provide direct access into an ICS environment or the ability to move into the ICS network. Publicly exposed applications may be found through online tools that scan the internet for open ports and services. Version numbers for the exposed application may provide adversaries an ability to target specific known vulnerabilities. Exposed control protocol or remote access ports found in Commonly Used Port may be of interest by adversaries.
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.
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[7]
All related ATT&CK context
Mitigation direction
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | d1a2f29ee182… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack T0819Open source URL
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.