GetTcpTable Bypass & TCP Hiding
BypassCore makes TCP connections completely invisible to userland monitoring tools, anti-cheat network scanners, and forensic analysis. Our GetTcpTable bypass operates at the kernel level, intercepting the data pipeline between the TCP/IP stack and any application that queries connection state.
The GetTcpTable API Pipeline
When any application calls GetTcpTable, GetTcpTable2, or the newer GetExtendedTcpTable, the request flows through a well-defined pipeline. The iphlpapi.dll userland library translates the call into an IOCTL request to the NSI (Network Store Interface) subsystem. This request reaches the nsiproxy.sys kernel driver, which queries the TCP/IP stack (tcpip.sys) for the current connection table. The data flows back through the same chain: tcpip.sys returns raw connection entries to nsiproxy.sys, which serializes them into the NSI response format, which iphlpapi.dll parses into the MIB_TCPROW structures your application receives.
Tools like netstat, TCPView, CurrPorts, and most anti-cheat network scanners all ultimately rely on this same pipeline. Even PowerShell's Get-NetTCPConnection cmdlet queries through NSI. This means that a single interception point at the right layer can hide connections from every userland tool simultaneously.
Nsiproxy Hooking — The Primary Bypass
BypassCore's primary GetTcpTable bypass operates by hooking the Nsiproxy dispatch routines. Nsiproxy.sys handles IOCTL requests through its IRP_MJ_DEVICE_CONTROL handler. We install a filter that intercepts the IOCTL_NSI_GETALLPARAM request with the TCP parameter ID. When the legitimate response returns from tcpip.sys, our filter examines the output buffer containing the array of connection entries and removes any entries matching our hidden connections before the buffer is returned to the caller.
// TCP hiding pipeline:
- 1. App calls GetTcpTable → iphlpapi.dll
- 2. iphlpapi sends IOCTL → nsiproxy.sys
- 3. nsiproxy queries → tcpip.sys (full table)
- 4. [HOOK] Our filter removes target entries
- 5. Filtered table returned → app sees clean data
The filtering is precise. We match connections by local port, remote address, remote port, or owning PID — configurable per deployment. The entry count in the response header is decremented to match the filtered data, and the buffer is compacted so there are no gaps or null entries that could indicate tampering. From the caller's perspective, the hidden connections simply do not exist.
DKOM — Direct Kernel Object Manipulation
For scenarios requiring deeper hiding, BypassCore employs DKOM techniques against the TCP/IP stack's internal data structures. The Windows TCP/IP driver (tcpip.sys) maintains connection state in a partition-based hash table — the TCB (Transmission Control Block) table, organized within Partition structures accessed through the PartitionTableglobal. By directly manipulating these internal structures, we can unlink a connection's TCB from the hash table, making it invisible even to kernel-level queries against tcpip.sys directly — not just nsiproxy filtering.
The challenge with TCB DKOM is maintaining connection functionality. Simply unlinking the TCB would break the connection because tcpip.sys needs to find it for incoming packet processing. BypassCore solves this by maintaining a shadow reference to the TCB through a separate lookup mechanism. We hook the packet receive path at the NDIS level to route packets for hidden connections through our shadow lookup, bypassing the standard hash table entirely. The connection remains fully functional — sending and receiving data normally — while being completely absent from any enumeration of the main TCB table.
Shadow Networking & Covert Channels
Beyond hiding existing connections, BypassCore can create entirely shadow network channels that never appear in the Windows networking stack at all. Our shadow networking implementation operates by creating a raw NDIS protocol driver that binds directly to the network adapter, below the TCP/IP stack. This driver implements its own minimal TCP implementation, handling SYN/ACK handshakes, sequence number management, window sizing, and retransmission — all outside the Windows tcpip.sys driver.
Since these shadow connections are managed entirely by our NDIS driver and never touch tcpip.sys, they cannot appear in any connection table query regardless of the monitoring tool's privilege level. Even a kernel debugger examining tcpip.sys internal structures would not find these connections, because they literally do not exist within the Windows TCP/IP stack. The traffic is real TCP on the wire — fully compatible with any remote server — but the local endpoint is entirely invisible.
Use Cases & Applications
Anti-Cheat Evasion
Hide cheat/overlay tool network traffic from anti-cheat TCP scans and connection monitoring
Red Team Operations
Make C2 channels invisible to host-based network monitoring and EDR solutions
Covert Data Exfiltration
Shadow networking channels for data movement that bypasses DLP network monitoring
Anti-Forensics
Connections that leave no trace in standard forensic analysis of network state
Evasion Against Advanced Monitoring
Some advanced monitoring solutions bypass GetTcpTable entirely, instead capturing packets at the NDIS or WFP (Windows Filtering Platform) level. BypassCore addresses this with WFP callout drivers that filter our hidden traffic from WFP inspection layers, and NDIS filter drivers that selectively hide packets from higher-level NDIS light-weight filters used by security products. For ETW (Event Tracing for Windows) based monitoring, we disable the Microsoft-Windows-Kernel-Network provider's TCP events for our connections, preventing ETW-based tools from seeing connection events even when GetTcpTable hiding would not be sufficient.
Need to Hide TCP Connections?
BypassCore builds custom TCP hiding solutions — from simple GetTcpTable filtering to full shadow networking stacks.
> Get in Touch