Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› How can security teams detect ngrok activity?
Threats, Abuse & Incident Response

How can security teams detect ngrok activity?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

Security teams detect ngrok by identifying unauthorised tunnels that create inbound access to internal hosts from external relay infrastructure. Watch for unusual agent processes, outbound connections to tunnel endpoints, and newly exposed local services that were not approved by operations. Confirm whether the tunnel supports sanctioned development or remote support before allowing it to remain active.

What ngrok activity looks like in a monitored environment

ngrok is easiest to spot when it creates a new path from an internal host to an external relay service that was not part of the approved access model. That changes the traffic pattern in a way defenders can usually see: a local process starts brokering inbound access, an internal service becomes reachable from outside, and the host may expose ports or protocols that were previously private. The signal is less about the brand name and more about the sudden appearance of a tunnel with business-impacting reach.

For detection, focus on correlation rather than a single indicator. A suspicious tunnel often combines a new or rare process with outbound connections to known tunnel infrastructure, followed by inbound requests to an internal service that should not be internet-reachable. Endpoint telemetry, network flow logs, proxy records, and DNS data are all useful because each one may show only part of the path.

On Linux, Windows, and macOS alike, the practical clue is often that an agent process appears without a matching change request or support ticket. The process may be started interactively, by automation, or as a service, but the deciding question is whether it has a legitimate operational purpose and whether the exposed local port matches an approved use case.

Telemetry that helps distinguish approved tunnels from abuse

Security teams should look for the combination of process lineage, network destination, and service exposure. If a user launches a tunnel client from a workstation or server, review the parent process, command line, listening ports, and the remote endpoint it contacts. If the tunnel exposes a local web app, admin interface, or remote shell, confirm that the service owner expected that exposure and that the asset is permitted to accept it.

Endpoint detections are stronger when they are tied to proxy, firewall, and DNS evidence. A tunnel client may connect to a small set of relay endpoints over a long-lived session while the internal host suddenly receives traffic that bypasses normal ingress controls. That pattern is especially useful on systems where developers, contractors, or support teams are allowed to use tunneling tools in limited circumstances.

ngrok-specific hunting is most effective when teams baseline normal remote access methods first. If the environment already uses jump hosts, VPN, remote support tools, or sanctioned reverse proxies, those should be the reference point. Anything outside that baseline, especially an unsigned or rarely used binary creating public reachability, deserves review.

How to investigate suspected ngrok use without missing the real issue

Once a tunnel is found, the priority is to determine whether it is sanctioned, who started it, what it exposes, and how long it has been active. Review recent changes, support requests, and developer activity before treating the event as hostile. If the exposure is legitimate, the control gap may still be that the tunnel was not inventoried, monitored, or time-bounded.

If the tunnel is not approved, preserve the process details, remote endpoint, local port mapping, and any authentication material used to start it. Then assess whether the exposed service has already been queried from outside, whether the tunnel enabled data access that should have stayed internal, and whether the host shows signs of follow-on activity such as credential use, file transfer, or new admin sessions. For a broader detection pattern around relay infrastructure and beacon-like behaviour, the Command and Control (C2) Guide is the most direct internal reference for this kind of traffic analysis.

Risk and Threat Considerations

Unauthorized tunnels bypass the normal perimeter model by turning an internal host into its own ingress point. That matters because the exposure is often invisible to perimeter-only monitoring, and the tunnel can persist as long as the agent process remains active. When attackers use this pattern, they gain a stable route into a host that may otherwise be unreachable from the internet.

Failure mechanism: A tunnel client establishes outbound trust to external relay infrastructure, then forwards inbound sessions to a local service that defenders did not intend to expose. If teams only watch for classic inbound scans, they can miss the fact that the exposure is created from the inside out.

Impact: The exposed service can be accessed from outside policy, which increases the chance of unauthorized administration, data access, remote command execution, or credential harvesting on the bridged host. Once the relay is active, the tunnel itself can become a durable access path until the process is killed and the underlying authorisation issue is corrected.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKT1090 — Proxyngrok creates relay paths that hide or forward inbound access through intermediaries
Recommendation — Hunt for proxy-based inbound access paths and correlate relay sessions with unusual host exposure.
NIST CSF 2.0DE.CM-01 — Monitoring for Unauthorized Connections, Devices, Software, and External SystemsDetecting ngrok depends on spotting unauthorized software and external connectivity
Recommendation — Monitor for unauthorized tunnel clients, outbound relay connections, and unexpected external reachability.
CIS Controls v8CIS-12 — Network Infrastructure ManagementNetwork control and visibility are needed to identify unauthorized tunnel exposure
Recommendation — Inventory and monitor network paths that create inbound access through unapproved relay infrastructure.
NIST SP 800-53 Rev 5AU-6 — Audit Record Review, Analysis, and ReportingLogs must be reviewed to correlate tunnel processes, endpoints, and exposed services
AC-4 — Information Flow EnforcementUnauthorized tunnels weaken intended boundaries by bypassing flow restrictions
Recommendation — Correlate endpoint, proxy, and flow logs to validate whether the tunnel is sanctioned or suspicious. Enforce approved information flows and block unapproved relay paths into internal hosts.

Practitioner Guidance

What to verify: Determine whether the tunnel was requested, approved, and time-limited before deciding whether to block it. If the answer is unclear, treat the connection as suspicious until the service owner, asset owner, or support team can justify it.

Decision rule: If the tunnel exposes a production service, an admin interface, or any endpoint that accepts credentials, prioritise containment and exposure review over debating whether the tool itself is malicious. The operational question is whether the organisation intended that host to be reachable that way.

What good looks like: Approved tunnels are rare, documented, short-lived, and tied to named use cases. Unapproved tunnels should stand out immediately in endpoint, network, and asset-inventory telemetry because they do not match the normal remote-access pattern.

Practitioner takeaway: The useful detection goal is not “find ngrok binaries,” it is “find unexpected internal services made externally reachable through an unapproved relay path.”

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org