T1016.001: Internet Connection Discovery
Adversaries may check for Internet connectivity on compromised systems. This may be performed during automated discovery and can be accomplished in numerous ways such as using Ping, tracert, and GET requests to websites, or performing initial speed testing to confirm bandwidth.
Adversaries may use the results and responses from these requests to determine if the system is capable of communicating with their C2 servers before attempting to connect to them. The results may also be used to identify routes, redirectors, and proxy servers.
Security context for executives and security teams
Internet Connection Discovery is a simple but useful adversary check: after access, malware or hands-on operators may test whether a host can reach the Internet, what path traffic takes, and whether proxies or redirectors are in the way. For leaders, the risk is not the ping or web request itself; it is that this behavior can precede command-and-control setup and help an intruder adapt to enterprise egress controls.
Executive priority
Treat this as a discovery behavior that tests the organization’s outbound-control and monitoring assumptions across Windows, Linux, macOS, and ESXi. It matters for resilience because an attacker that can quietly verify Internet reachability may be better positioned to establish C2 or understand where defensive logging exists. Priority questions: Which systems are allowed direct Internet access? Are proxy and egress logs retained and searchable during IR? Can the SOC distinguish normal connectivity checks from suspicious checks performed by unusual processes or compromised hosts?
Technical view
ATT&CK lists this sub-technique under Discovery and as a sub-technique of System Network Configuration Discovery. The official description cites ping, tracert, GET requests to websites, and speed testing as examples, with possible use of results to assess C2 reachability, routes, redirectors, and proxy servers. Because no official detection text is provided, validation should focus on behavioral detection logic such as DET0357, correlated with process execution, outbound network activity, DNS/proxy evidence, and host context. Relationship context shows use by multiple campaigns, groups, and malware families, including GoldFinder, which is described as an HTTP tracer tool used to log routes between a compromised network and C2 during SolarWinds-related investigation context.
Likely telemetry
- Endpoint process creation and command-line telemetry for utilities such as ping and tracert where applicable
- Outbound network connection logs from hosts, firewalls, proxies, and secure web gateways
- HTTP request logs, including destination, method, user agent where available, and initiating host or process where available
- DNS query logs for external connectivity-test or unusual destinations
- Proxy route and authentication logs that show whether traffic is direct or mediated
Detection direction
- Validate behavioral detection for Internet reachability checks from unusual processes, newly observed hosts, service accounts, or execution chains rather than alerting on every ping or web request.
- Correlate connectivity checks with earlier execution, persistence, credential, or network-configuration discovery events to reduce false positives.
- Tune separately for administrative tools and health checks, which may legitimately test Internet access or bandwidth.
- Look for route-discovery or proxy-discovery patterns, especially repeated traceroute-like activity or HTTP GETs that appear designed to map egress paths.
- Use relationship context to prioritize detections that catch both commodity backdoor behavior and custom tooling patterns, without assuming any specific actor is present.
Mitigation priorities
- Inventory and restrict which hosts require direct Internet egress, with particular attention to servers and virtualization infrastructure.
- Require outbound traffic to traverse controlled and logged paths such as approved proxies or egress gateways where operationally feasible.
- Ensure proxy, DNS, firewall, and endpoint telemetry is retained long enough to support incident response reconstruction.
- Baseline legitimate connectivity testing by IT tools so the SOC can identify anomalous sources, processes, and timing.
- Include Internet reachability and route-discovery checks in purple-team or detection validation exercises mapped to T1016.001 and DET0357.
Additional notes and limits
This object is a sub-technique of T1016 and is limited to the Discovery tactic. The supplied relationships show broad historical use across campaigns, groups, and software, so the decision value is in control validation and telemetry readiness rather than attribution. GoldFinder is especially relevant because its supplied description directly aligns with route logging between a compromised network and C2.
MITRE provides no official detection text for this object. The supplied fields do not define specific log source requirements, command variants by operating system, or guaranteed analytics. Local baselines, approved admin behavior, proxy architecture, and endpoint visibility are required to determine practical detection quality.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Internet Connection Discovery
Adversaries may check for Internet connectivity on compromised systems. This may be performed during automated discovery and can be accomplished in numerous ways such as using Ping, tracert, and GET requests to websites, or performing initial speed testing to confirm bandwidth.
Adversaries may use the results and responses from these requests to determine if the system is capable of communicating with their C2 servers before attempting to connect to them. The results may also be used to identify routes, redirectors, and proxy servers.
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.