GetTcpTable2 Bypass Techniques Explained

How GetTcpTable2 Works Internally

When an application calls GetTcpTable2() from iphlpapi.dll, the call chain traverses several layers before reaching the actual connection data. First, iphlpapi calls into the NSI (Network Store Interface) client library, nsi.dll, which formats the request as an NSI query. This query specifies the NSI module GUID for TCP (identifying the TCP parameter set) and the type of data requested — in this case, the connection table including local/remote addresses, ports, states, and owning PIDs.

The NSI client then communicates with the kernel-mode NSI proxy driver, nsiproxy.sys, through an IOCTL (I/O Control) call. The specific IOCTL code is IOCTL_NSI_GETALLPARAM, sent to the nsiproxy device object. Inside the kernel, nsiproxy dispatches the request to the appropriate NSI provider — for TCP connections, this is the tcpip.sys driver, which maintains the actual TCP connection state in its internal partition tables. The results flow back through nsiproxy, through the NSI client, and are formatted into the MIB_TCPTABLE2 structure that the caller receives.

Technique 1: User-Mode API Hooking

The simplest approach hooks GetTcpTable2 directly in iphlpapi.dll using inline hooking or IAT (Import Address Table) patching. The hook intercepts the return value, iterates through the MIB_TCPTABLE2 entries, and removes rows matching the connections you want to hide (by local port, remote IP, or owning PID). The entry count in the table header is decremented accordingly, and the remaining entries are shifted to fill the gap.

The advantage of user-mode hooking is simplicity and speed of implementation. The drawback is that it must be applied to every monitoring process individually, and security software with integrity checks on iphlpapi will detect the hook. Anti-cheat engines routinely scan for modified function prologues in system DLLs. Additionally, a monitoring tool that uses direct syscalls or maps its own clean copy of iphlpapi will bypass the hook entirely. For these reasons, user-mode hooking is typically insufficient against sophisticated monitoring.

Technique 2: NSI Proxy IOCTL Interception

A more robust approach targets the kernel-mode nsiproxy.sys driver by hooking its IRP (I/O Request Packet) dispatch routine. We locate the nsiproxy device object and replace its IRP_MJ_DEVICE_CONTROL handler with our own filter function. When an IOCTL matching IOCTL_NSI_GETALLPARAM arrives, we set a completion routine on the IRP and allow it to proceed to the original handler. When nsiproxy completes the request, our completion routine fires, giving us access to the output buffer containing the raw TCP table data.

At this point, we parse the NSI output format (which differs from the user-mode MIB structure — it uses parallel arrays for addresses, states, and process IDs), identify entries matching our filter criteria, and remove them. This approach works globally — any user-mode process calling GetTcpTable, GetTcpTable2, GetExtendedTcpTable, or even direct NSI queries will receive filtered results. The hook is invisible to user-mode integrity checks because no user-mode code is modified.

Technique 3: DKOM — Direct Kernel Object Manipulation

The most stealth-oriented approach avoids hooking entirely. Instead, we directly manipulate the TCP connection objects maintained by tcpip.sys in kernel memory. TCP connections are tracked in partition hash tables (the TCP endpoint partition structure), where each active connection is represented by a TCPT_OBJECT structure linked into the hash bucket. By unlinking a connection object from the hash table, we make it invisible to any enumeration path — including nsiproxy queries, netsh, netstat, and Resource Monitor.

The challenge with DKOM is that the internal structures of tcpip.sys are undocumented and change between Windows versions and patches. BypassCore maintains signature databases for each supported Windows build, using pattern scanning to locate the partition table base address and the offsets within the connection structures. We validate the structures before modifying them to prevent blue screens from corrupted pointers.

Technique 4: WFP Callout-Based Filtering

An alternative approach uses the Windows Filtering Platform (WFP) to operate at the network layer rather than the enumeration layer. While WFP callout drivers are typically used for firewalling and packet inspection, a cleverly designed callout can redirect connections through a local proxy, effectively replacing the original connection's endpoints in the TCP table with innocuous-looking local addresses. The real traffic is tunneled through the proxy, invisible to table enumeration.

This approach does not hide the connection per se but disguises it. The connection appears as a localhost-to-localhost connection owned by a system service, which is far less suspicious than a hidden entry. Combined with NSI filtering for complete hiding when needed, this provides a layered evasion strategy. BypassCore typically recommends the NSI IOCTL interception approach for most clients, with DKOM reserved for scenarios where maximum stealth is required and the target Windows version is stable.

BypassCore's Implementation

Our production TCP hiding solution combines NSI IOCTL interception as the primary hiding mechanism with DKOM as a fallback for hardened environments. The filter criteria are configurable at runtime — clients can specify connections to hide by local port, remote address, remote port, or owning process. Our kernel driver includes self-protection mechanisms to prevent removal by monitoring tools and uses obfuscated communication channels for receiving filter updates from user mode. The entire solution operates transparently with zero performance impact on legitimate network operations.

Related Articles