SentinelOne's Isolation meets DNS C2

Bypass Device Isolation in Sentinel One and DNS C2 survival

During a recent purple team exercise, we demonstrated that a DNS‑based C2 implant can remain operational on a Windows host even after SentinelOne initiates Device Isolation. Despite the isolation state, the implant was still able to execute commands and exfiltrate data.

SentinelOne’s Device Isolation feature is intended to quarantine a compromised system by blocking most outbound network communication, which typically disrupts C2 channels that rely on HTTP or HTTPS. However, DNS‑based C2 traffic is not blocked. According to SentinelOne’s documentation, DNS remains enabled during isolation to preserve communication between the endpoint agent and the SentinelOne management console.

As a result, DNS C2 channels can continue to function even when the device is isolated, allowing an attacker to maintain persistence and control.

Technical Execution

1. Initial Compromise & C2 Setup

   • A DNS-based Sliver implant is deployed on the target Windows machine running SentinelOne.

   • The implant communicates with the C2 server via DNS queries (e.g., random.1.domain.com), which are often allowed even in restricted network states.

   • Verification is done by executing a simple command (e.g., ps, info) and confirming the response is received via DNS exfiltration.

2. Triggering SentinelOne Detection & Isolation

   • We intentionally perform suspicious behavior by running default mimikatz.exe that triggers a SentinelOne alert.

   • The SOC responds by enabling Device Isolation, which blocks standard C2 channels (e.g., HTTPS,HTTP, SMB, RDP,ICMP).

   • Confirmation of isolation is done by checking:

     • SentinelOne console showing "Isolated" status for the host.

     • Loss of standard network connectivity (e.g., https & http & ping fails).

3. Testing DNS C2 Resilience

   • Despite isolation, the DNS-based implant remains active because:

     • SentinelOne allows outbound DNS (UDP 53) even in isolated mode.

     • DNS tunneling encodes data in subdomains, making it stealthy and difficult to block without deep packet inspection.

   • We execute additional commands (e.g., pwd, whoami) and confirm that output is still exfiltrated via DNS.

4. Why This Works

   • SentinelOne’s Isolation primarily blocks TCP-based communication but leaves UDP/DNS unrestricted.

   • Sliver’s DNS C2 encodes data in TXT, A, or CNAME records, blending with legitimate traffic.

---

Live PoC

After the Security Incident Response team initiated device isolation through the SentinelOne console, the DNS‑based C2 implant continued to operate without interruption. It was still able to receive tasking, execute commands, and exfiltrate output to the C2 server exactly as it would under normal conditions, effectively behaving as though the device had never been isolated.

---

Finalizing the Walkthrough

Now that screenshots and video evidence have confirmed that the DNS‑based C2 implant (Sliver) successfully operated despite SentinelOne’s Device Isolation, the following section summarizes the key findings and outlines defensive considerations.

Summary

Initial Compromise: The Sliver DNS implant was deployed on the target host, successfully establishing a covert command‑and‑control channel.

SOC Response: SentinelOne identified malicious activity and placed the device into isolation, blocking traditional outbound communication channels such as HTTP and SMB.

Bypass Confirmed: Despite the isolation, DNS tunneling allowed the implant to remain fully operational. It continued to execute commands, including whoami and ipconfig, and exfiltrated data through encoded DNS queries and responses.

The accompanying video and screenshots demonstrate that the isolated host maintained uninterrupted communication with the C2 server, effectively nullifying the SOC’s containment efforts.

Blue Team and SOC Analysts

Restrict outbound DNS to internal resolvers only. All DNS traffic should be routed through controlled internal servers capable of logging, inspecting, and blocking suspicious query patterns.

Implement DNS tunneling detection. Indicators include unusually long or encoded hostnames, such as g1h2x3.[malicious.domain], and an abnormal volume of TXT or NULL record requests. Monitoring tools such as Splunk, Zeek, and SentinelOne’s threat‑hunting capabilities can assist in identifying these behaviors.

Ensure network‑level isolation is comprehensive. Effective containment should block all outbound traffic, including DNS, unless specific exceptions are intentionally defined.

Conclusion: A Lesson in Assumed Security

SentinelOne’s isolation controls are not fully effective against low‑and‑slow DNS‑based C2 channels. This limitation allowed the implant to maintain communication even after the device was isolated. A service ticket has been submitted to SentinelOne to report and address this behavior.