NetstatWithTimestamps

Mar 28, 2024

Current network connections are one of the typical and most valuable volatile data. It’s clearly volatile as it disappears forever the moment you shut down your computer. Theoretically, you can log connections with Sysmon, but you need to do it in advance. If you have no such log, you need to politely ask Windows to provide you with information about IPs, ports, and processes. Of course, you can do it with “netstat.exe -ano”, but when you write your own tool, such as Volatile Data Collector, you usually prefer to ask Windows about connections using some API instead of creating the netstat.exe child process.

By the way, “-ano” seems to be the best set of parameters. It does not require elevated permissions, quickly returns raw data, and the output is relatively easy to parse, as each line contains one piece of information.

Anyway, asking Windows API for the same information is not very complicated, as it is about one call for GetExtendedTcpTable() / GetExtendedUdpTable() per IPv4/IPv6 protocol. Each call fills the provided buffer with information containing a number of elements and the table of elements. Element type depends on the query, but well documented MIB_TCPROW_OWNER_MODULE is a great example.

Long story short: when I have tried to write my own netstat-like module, I have spotted that Windows keeps not only the obvious set of State/IPs/Ports/PID per connection, but also one field more: liCreateTimestamp, documented as “A FILETIME structure that indicates when the context bind operation that created this TCP link occurred.” After a moment of “Wait, what!?” I have realized that Windows stores information about the time each active connection was established. It is a true gem from the forensics perspective, but for a totally unknown reason ignored by the netstat tool.

That's exactly why my tiny NetstatWithTimestamps tool appeared on my GitHub. Of course, I am not the only (or even the first) one spotting this well-documented piece of information, but I believe publishing it as open source provides some value.

¯\_(ツ)_/¯

[©] Copyright 2024

GT

NetstatWithTimestamps

Mar 28, 2024

Current network connections are one of the typical and most valuable volatile data. It’s clearly volatile as it disappears forever the moment you shut down your computer. Theoretically, you can log connections with Sysmon, but you need to do it in advance. If you have no such log, you need to politely ask Windows to provide you with information about IPs, ports, and processes. Of course, you can do it with “netstat.exe -ano”, but when you write your own tool, such as Volatile Data Collector, you usually prefer to ask Windows about connections using some API instead of creating the netstat.exe child process.

By the way, “-ano” seems to be the best set of parameters. It does not require elevated permissions, quickly returns raw data, and the output is relatively easy to parse, as each line contains one piece of information.

Anyway, asking Windows API for the same information is not very complicated, as it is about one call for GetExtendedTcpTable() / GetExtendedUdpTable() per IPv4/IPv6 protocol. Each call fills the provided buffer with information containing a number of elements and the table of elements. Element type depends on the query, but well documented MIB_TCPROW_OWNER_MODULE is a great example.

Long story short: when I have tried to write my own netstat-like module, I have spotted that Windows keeps not only the obvious set of State/IPs/Ports/PID per connection, but also one field more: liCreateTimestamp, documented as “A FILETIME structure that indicates when the context bind operation that created this TCP link occurred.” After a moment of “Wait, what!?” I have realized that Windows stores information about the time each active connection was established. It is a true gem from the forensics perspective, but for a totally unknown reason ignored by the netstat tool.

That's exactly why my tiny NetstatWithTimestamps tool appeared on my GitHub. Of course, I am not the only (or even the first) one spotting this well-documented piece of information, but I believe publishing it as open source provides some value.

¯\_(ツ)_/¯

[©] Copyright 2024

GT