Detect Data Exfiltration via USB Cellular Modem / Mobile Hotspot Tethering (Corporate Network Bypass) in Sumo Logic CSE
Exfiltration Over Other Network Medium (T1011) covers cases where an adversary routes data over a network channel other than the compromised host's primary, monitored corporate connection. One of the most practical instances of this on modern managed endpoints is USB cellular-modem or mobile-hotspot tethering: an operator (insider or malware with local/physical access) plugs an Android device configured for USB tethering, or an iPhone in Personal Hotspot mode, into a corporate workstation. Windows enumerates the phone as a USB RNDIS (Remote NDIS) network adapter and installs it automatically using an in-box driver (usbrndis6.inf or wceusbsh.inf for Windows Mobile Device Center-class devices), creating a second, fully-routable network path that bypasses the corporate proxy, DLP egress inspection, and firewall egress rules entirely — traffic over the tethered adapter never touches the monitored network segment. This is distinct from Bluetooth-based exfiltration (T1011.001, covered separately in this corpus), which uses a fundamentally different protocol stack and driver class, and distinct from T1052.001 (Exfiltration over USB), which covers copying data to USB mass-storage rather than using USB as a network transport. Because RNDIS tethering devices install via Windows' standard Plug and Play driver framework, their arrival is reliably observable in the registry even when process-level or network-flow visibility into the tethered link itself is unavailable (the OS routes traffic over the new adapter, which most EDR network sensors do not separately attribute).
MITRE ATT&CK
- Tactic
- Exfiltration
Sumo Detection Query
_sourceCategory=endpoint/registry
| parse "host=*," as host nodrop
| parse "RegistryKey=*," as registry_key nodrop
| parse "RegistryValueData=*," as registry_value_data nodrop
| where registry_key matches "*{4d36e972-e325-11ce-bfc1-08002be10318}*" or registry_value_data matches "*RNDIS*" or registry_value_data matches "*Android Bootloader Interface*" or registry_value_data matches "*usbrndis6.inf*"
| count as EventCount by host, registry_key, registry_value_data
| sort by EventCount descSumo Logic query over endpoint registry-event logs matching the Windows Network adapter class GUID or RNDIS/mobile-tethering vendor strings in registry value data, surfacing USB tethering device installation.
Data Sources
Required Tables
False Positives & Tuning
- IT-approved break-glass internet failover using tethering during an outage
- Developers debugging Android/iOS applications over USB (adb/Xcode)
- Field workers legitimately tethering where policy permits it
Other platforms for THREAT-USBTethering-NetworkBypassExfil
Testing Methodology
Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulated RNDIS Network Adapter Class Registry Write
Expected signal: Sysmon Event ID 13 (Registry Value Set) / DeviceRegistryEvents: a value write under the test key with data containing 'Remote NDIS', 'Android Bootloader Interface', and 'usbrndis6.inf'.
- Test 2Simulated Traffic Over a Tethered-Subnet IP Range
Expected signal: Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents: an outbound connection with LocalIP/SourceIp of 192.168.42.100, matching the Android default USB-tethering NAT subnet.
Response Playbook
Triage
- Confirm whether USB tethering is a documented, policy-approved exception for the affected user or role (e.g. field technician with no other connectivity) before treating this as hostile.
- Identify the tethered device: registry PnP data (friendly name, vendor/product ID under the USB Enum key) usually reveals whether it's an Android phone, iPhone, or a purpose-built cellular modem/MiFi device.
- Check whether the endpoint is a high-value asset (holds sensitive data, has privileged access, or is a server — tethering on a server is almost never legitimate and should be treated as a strong signal on its own).
- Correlate the RNDIS installation timestamp against any preceding bulk file access, archive staging, or credential-store access (DeviceFileEvents) — tethering installed immediately after such activity indicates deliberate exfiltration-channel setup rather than incidental personal use.
- Where DeviceNetworkEvents shows traffic over the tethered-subnet IP range, review connection volume and destination to establish what left the network outside proxy/DLP visibility.
- Interview or check ticketing history for a legitimate business reason (outage, field work) before escalating as insider threat, since this technique also fires on entirely benign break-glass connectivity.
Containment
- If unauthorized, have the user physically disconnect the tethered device and, where policy allows, disable the ability to install new network adapter classes via Group Policy / MDM (e.g. blocking installation of RNDIS-class USB devices through a device installation restriction policy).
- Isolate the endpoint via EDR network isolation if correlated with prior bulk data access or credential-store access, since the tethered link itself is invisible to network isolation controls that only cover the primary corporate adapter.
- Rotate credentials accessible from the host if evidence indicates the tethering was used to move sensitive data or credentials off-network.
- For a confirmed insider-threat case, coordinate with HR/Legal before further device or account action, per standard insider-threat handling procedure.
Evidence Collection
- The registry PnP enumeration records identifying the tethered device (vendor ID, product ID, friendly name, driver INF used).
- DeviceNetworkEvents (or Sysmon Event ID 3) records for any connections observed over the tethered-subnet IP range, including destination and approximate duration/volume.
- File access and archive-staging activity in the window preceding the tethering event, to establish intent and scope of data potentially exfiltrated.
- Physical device custody information if the tethered device itself can be identified and is subject to a workplace investigation.
Escalation Criteria
- !Tethering is detected on a server, domain controller, or another host with no plausible field-connectivity justification.
- !The tethering event directly follows bulk file staging, credential-store access, or other collection-stage activity on the same host.
- !The same user or host shows repeated tethering events specifically outside documented outage windows, suggesting a persistent, deliberate bypass channel rather than a one-off.
- !No legitimate business justification can be established after user/manager follow-up — escalate to insider-threat / HR process.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Windows registry PnP enumeration under SYSTEM\CurrentControlSet\Enum\USB and the Network adapter class key ({4d36e972-e325-11ce-bfc1-08002be10318}), retained even after the device is disconnected. - >
Windows Event Log Microsoft-Windows-Kernel-PnP/Configuration (Event ID 400/410) recording device installation, as a corroborating source alongside Sysmon registry events. - >
DeviceNetworkEvents / Sysmon Event ID 3 records for connections over the tethered-subnet IP range, establishing the actual data transferred. - >
setupapi.dev.log on the endpoint, which records driver installation history for the RNDIS adapter with timestamps independent of SIEM retention.
Tuning Guidance
Build an explicit allowlist of users/roles with a documented business need for tethering (field technicians, break-glass on-call responders) keyed by AccountName plus a defined outage/maintenance window, and suppress matches within that window. Weight the network-traffic correlation signal (LocalIP in the tethered-subnet ranges) far more heavily than the registry-installation signal alone on developer workstations, since adb/Xcode debugging routinely triggers RNDIS driver installation without any actual data transfer occurring over the interface. Prioritize alerting on server-class and privileged-workstation hosts where the false-positive base rate is near zero. Because the tethered-subnet IP ranges (192.168.42.0/24 for Android, 172.20.10.0/28 for iOS Personal Hotspot) are vendor defaults rather than a protocol-level standard, periodically validate they still match current OS versions in your fleet and extend the range list if newer Android/iOS releases change the default NAT pool.
Hunting Queries
Fleet-wide hunt for RNDIS/mobile-tethering driver installation over a 30-day window, independent of any correlated network traffic — useful for building a baseline of hosts/users where tethering already occurs so the primary detection's false-positive list can be tuned.
// Hunt for any historical RNDIS/mobile-tethering driver installation across the fleet, independent of the network-traffic correlation
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryValueData has_any (dynamic(["RNDIS", "Apple Mobile Device", "Android Bootloader Interface", "usbrndis6.inf", "Remote NDIS"]))
| project Timestamp, DeviceName, AccountName = InitiatingProcessAccountName, RegistryKey, RegistryValueData
| sort by Timestamp descindex=sysmon OR index=edr (EventCode=12 OR EventCode=13)
(Details="*RNDIS*" OR Details="*Apple Mobile Device*" OR Details="*Android Bootloader Interface*" OR Details="*usbrndis6.inf*")
| table _time, host, User, TargetObject, Details
| sort - _timeHunts specifically on server-class hostnames for any tethered-subnet traffic, since legitimate tethering on servers (as opposed to field-worker laptops) is exceedingly rare and warrants immediate review regardless of volume.
// Hunt for server-class hosts (naming convention heuristic) exhibiting any tethered-subnet traffic — a much higher-confidence signal than on general workstations
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where ipv4_is_in_range(LocalIP, "192.168.42.0/24") or ipv4_is_in_range(LocalIP, "192.168.43.0/24") or ipv4_is_in_range(LocalIP, "172.20.10.0/28")
| where DeviceName matches regex @"(?i)(srv|dc|sql|file|backup)"
| project Timestamp, DeviceName, AccountName, LocalIP, RemoteIP, RemoteUrl
| sort by Timestamp descindex=sysmon OR index=edr EventCode=3
| eval TetheredSubnetMatch=if(cidrmatch("192.168.42.0/24",SourceIp) OR cidrmatch("192.168.43.0/24",SourceIp) OR cidrmatch("172.20.10.0/28",SourceIp) OR cidrmatch("192.168.42.0/24",DestinationIp) OR cidrmatch("192.168.43.0/24",DestinationIp) OR cidrmatch("172.20.10.0/28",DestinationIp), 1, 0)
| where TetheredSubnetMatch=1 AND (host="*srv*" OR host="*dc*" OR host="*sql*" OR host="*file*" OR host="*backup*")
| table _time, host, User, SourceIp, DestinationIp
| sort - _timeAtomic Red Team Tests
Simulates the registry footprint left by Windows installing a USB RNDIS tethering adapter by writing a synthetic value containing RNDIS/mobile-device vendor strings under a test registry key, validating the registry-based detection logic without requiring an actual phone to be tethered.
Command
$TestKey = "HKCU:\Software\AtomicTest_RNDIS"
New-Item -Path $TestKey -Force | Out-Null
New-ItemProperty -Path $TestKey -Name "DeviceDesc" -Value "Remote NDIS Compatible Device - Android Bootloader Interface" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $TestKey -Name "InfPath" -Value "usbrndis6.inf" -PropertyType String -Force | Out-Null
Write-Host 'Atomic test complete: synthetic RNDIS tethering registry values written'Cleanup
Remove-Item -Path "HKCU:\Software\AtomicTest_RNDIS" -Recurse -Force -ErrorAction SilentlyContinueExpected Telemetry
Sysmon Event ID 13 (Registry Value Set) / DeviceRegistryEvents: a value write under the test key with data containing 'Remote NDIS', 'Android Bootloader Interface', and 'usbrndis6.inf'.
Expected Detection
KQL/SPL detection flags the registry value write based on RegistryValueData matching the RNDIS/tethering-vendor indicator list. In production, point detection logic at the real PnP class/Enum keys rather than the test path used here; this atomic validates the string-matching logic in isolation.
Simulates the network-layer correlation signal by binding a local loopback alias to an IP address in the Android USB-tethering default subnet and issuing an outbound connection from it, validating the tethered-subnet traffic detection independent of an actual RNDIS device.
Command
netsh interface ipv4 add address "Loopback Pseudo-Interface 1" 192.168.42.100 255.255.255.0 2>$null
try {
Invoke-WebRequest -Uri "https://127.0.0.1:8443/" -TimeoutSec 3 -SkipCertificateCheck -UseBasicParsing
} catch {}
Write-Host 'Atomic test complete: simulated connection from tethered-subnet IP range generated'Cleanup
netsh interface ipv4 delete address "Loopback Pseudo-Interface 1" 192.168.42.100 2>$nullExpected Telemetry
Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents: an outbound connection with LocalIP/SourceIp of 192.168.42.100, matching the Android default USB-tethering NAT subnet.
Expected Detection
The tethered-subnet-traffic portion of the detection flags the connection based on LocalIP/SourceIp falling within 192.168.42.0/24. Adjust local lab firewall/network configuration as needed since adding a secondary loopback address requires local admin rights.