Security teams detect Chisel by looking for unauthorised tunnelling between internal and external systems, especially long-lived connections that carry forwarded ports or proxy traffic. Correlate endpoint process execution with network sessions to unfamiliar destinations, then check for local services exposed through the tunnel. Investigate any use that bypasses standard egress controls or remote access policy.
What Chisel activity looks like on the wire
Chisel is easiest to spot when you treat it as a tunnelling and forwarding problem, not just a binary on disk. The telltale pattern is a process that creates an outbound connection and then carries interactive traffic, port forwards, or proxy-like relay behaviour through that session. Watch for internal services suddenly becoming reachable from an unexpected host or through an unusual path, especially when the traffic does not match normal remote access tooling.
A practical detection posture starts by baselining which processes are allowed to establish long-lived sessions to external destinations, then flagging any process that also spawns child activity, binds local listeners, or opens forwarded ports. For a broader C2 and tunnelling playbook, Command and Control (C2) Guide is the most directly relevant internal reference because the same tradecraft often shows up as beaconing, protocol tunnelling, or egress abuse.
At network level, the strongest signal is a stable connection that persists far longer than ordinary user traffic while carrying small bursts of bidirectional data. If that traffic lands on unfamiliar infrastructure, a cloud tunnel, or a consumer-facing endpoint that should not host remote administration, treat it as suspicious until you can explain the business purpose and owning user.
How to correlate host and network evidence
Detection is much stronger when endpoint telemetry and network telemetry are joined. On the host side, look for the parent process, command line, start time, and any local port listeners or reverse connections. On the network side, tie that same endpoint to unusual destination IPs, ports, domains, or session durations. The key question is whether a process that should not be brokering access is instead acting like a relay.
Correlate this with authentication and remote access logs. If the same endpoint is also involved in remote login, jump host use, or administrative access that bypasses standard pathways, the tunnel may be providing a covert alternative to approved access controls. MITRE ATT&CK Enterprise Matrix is a useful external reference for mapping this behaviour to adversary tradecraft, especially command and control, lateral movement, and credential-access-adjacent activity.
One of the most useful investigative pivots is local exposure. If the tunnel makes an internal service reachable from outside its normal network segment, enumerate what has become exposed and whether that service was intended to be reachable through the tunnel at all. That often reveals the operational purpose of the channel faster than looking only for the Chisel process name.
What usually separates benign tunnelling from hostile use
Not every tunnel is malicious, so the detection question is really about intent, control, and policy breach. The same technical mechanism can support legitimate support workflows, but hostile use is more likely when the connection is undocumented, long-lived, hard to attribute, or paired with privileged access to sensitive internal systems. Another warning sign is when the tunnel creates a path that sidesteps approved egress filtering or remote access policy.
For defenders, the decision point is whether the tunnel is part of an authorised workflow with traceable ownership and change control, or whether it is an unauthorised access path that weakens segmentation. The latter is especially concerning when it provides access to admin interfaces, databases, or internal services that were never meant to be directly exposed. NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor that control view through monitoring, access control, and system integrity expectations.
Because tunnelling tools are often repurposed, the detection strategy should focus on behaviour rather than filenames. Renaming the binary does not change the traffic pattern, the persistence behaviour, or the exposure created by a forwarded service.
Risk and Threat Considerations
Unauthorised tunnelling can quietly defeat segmentation by turning one compromised endpoint into a bridge to otherwise inaccessible services. That makes it attractive for both stealthy access and follow-on movement, because the network path looks like ordinary outbound connectivity unless defenders inspect the process and session context together.
Failure mechanism: The tunnel creates a trusted-looking channel that bypasses egress policy, hides the true source of service access, and can expose internal ports or administrative endpoints through a single long-lived session.
Impact: An attacker or insider can reach internal systems without using approved remote access, increasing the chance of lateral movement, service abuse, and delayed detection.
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 SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Chisel activity commonly uses proxying and tunnelling to relay traffic. |
| Recommendation — Map tunnel behaviour to Proxy techniques and hunt for relayed access paths. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Detection depends on correlating endpoint and network audit data. |
| AC-4 — Information Flow Enforcement | Chisel can bypass intended egress and segmentation controls. | |
| Recommendation — Correlate process, session, and remote access logs to expose unauthorised tunnelling. Enforce flow controls that block unsanctioned outbound and forwarded access paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Detecting tunnel traffic requires monitoring for unusual connections and destinations. |
| CIS-12 — Network Infrastructure Management | Tunnelling exploits weakly governed network paths and exposed services. | |
| Recommendation — Monitor for long-lived, unusual outbound sessions and investigate unexpected listeners. Harden egress and remote access paths so forwarded services cannot bypass policy. | ||
Practitioner Guidance
What to verify: Confirm which process established the session, which local port or service it exposed, and whether there is a business ticket or change record for that access path. If the answer is no, treat the tunnel as suspect until proven otherwise.
Decision rule: If the tunnel reaches a production service or an administrative interface, prioritise containment and credential review before spending time on binary attribution. The access path is the operational risk, even if the executable name is unfamiliar or the payload is still being analysed.
Practitioner takeaway: The most reliable Chisel detections come from joining host execution, long-lived network sessions, and unexpected service exposure, because the tunnel itself is often less visible than the access it enables.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
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.
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