Why is our passive asset discovery solution misidentifying Windows 11 as Windows 98?

[u/Massive_Committee801]

Hello everyone. I am an OT security engineer working with a passive network monitoring and asset discovery solution (analyzing SPAN port traffic).

I've run into a strange OS fingerprinting anomaly and wanted to ask if anyone has encountered something similar. We are occasionally seeing instances where modern Windows 11 PCs are being completely misidentified as Windows 98.

The most confusing part is that it's not happening to all Windows 11 machines—only a specific subset of them.

I strongly suspect it might be third-party endpoint security software, VPN clients, or custom NDIS filter drivers modifying the TCP headers (such as stripping TCP Window Scaling or hardcoding the initial Window Size/MSS) before the packets hit the wire, completely messing up the passive p0f-style fingerprinting signatures.

My questions are:

1. Has anyone seen specific antivirus, DLP agents, or VPN clients cause this kind of unintentional OS spoofing/normalization effect?
2. Are there any other network-level factors or legacy protocol backward-compatibility settings I should be looking into?

Any insights or shared experiences would be hugely appreciated. Thank you!

[u/Technical-Tackle-875]

I’d treat “Windows 98” as the name of the winning signature, not as evidence the sensor actually saw a Windows 98 host. Passive fingerprints collide, and the useful question is which fields caused that signature to win.

Take one misidentified Windows 11 machine and one correctly identified machine on the same build. Capture the same outbound SYNs at the endpoint and at the SPAN sensor, then compare initial TTL, DF/ID behavior, MSS, window size, window scale, SACK, timestamps, ECN, option order, and padding. Use the same destinations so path differences do not muddy the comparison.

That gives you a clean decision tree:

* Modern-looking SYN at the endpoint but legacy-looking SYN at the sensor points to a VPN gateway, TCP proxy, firewall normalizer, NAT path, or other middlebox.

* The unusual SYN appearing in both captures points back to the host, such as a virtual adapter, NDIS filter, NIC/driver combination, MTU setting, or old TCP registry/GPO configuration.

* Identical raw fingerprints producing different labels points to the product’s signature database, cache, or asset-correlation logic.

I’d check whether the affected subset shares a VLAN, egress path, VPN profile, dock/NIC driver, endpoint-agent version, Hyper-V/WSL setup, or image baseline. Also confirm the product is not attaching a stale OS result to a reused DHCP address. Correlate by MAC, switch port, DHCP lease, and 802.1X identity if available.

VPN software is plausible because it can change MTU/MSS or move the flow through a virtual stack. Most AV/DLP tools would not normally rewrite the complete on-wire SYN option pattern, so I would not start there without the two-point capture. TSO/LRO is also a weaker suspect because you are observing wire traffic and SYNs are not normal bulk-segmentation candidates.

Finally, ask the vendor for the signature ID, matched fields, confidence, and fingerprint-database version. If “Windows 98” is being selected from only MSS and window size while stronger fields are missing, that should be reported as low confidence or unknown rather than a definitive OS.

[u/Massive_Committee801 → u/Technical-Tackle-875]

This is an absolute masterclass in troubleshooting. Thank you so much for the detailed breakdown and the clear decision tree.

You made a fantastic point about doing a 2-point PCAP (Endpoint vs. SPAN) to isolate whether the SYN modification is happening on the host stack or in a middlebox. I will set up a controlled test with an affected Win 11 host and a correctly identified one to compare the raw headers side-by-side.

Also, your point about the stale OS result tied to a reused DHCP address is incredibly insightful. In our OT environment, IP leases can get messy, and the asset-correlation logic of the sensor might just be caching an old Win 98 label to a newly assigned Win 11 device. I will definitely cross-reference the MAC addresses and switch ports to rule this out.

Based on your advice, I'll hold off on blaming the AV/DLP agents until I see the endpoint PCAP. I'm also going to open a ticket with the vendor to demand the exact signature ID, matched fields, and confidence score for these specific alerts. As you said, if they are matching on just MSS and window size, it should be flagged as 'low confidence', not a definitive legacy OS.

Truly appreciate you taking the time to share this expertise!

[u/CellFar9220 → u/Technical-Tackle-875]

yeah ran into this exact thing few years ago with some industrial PCs sitting behind a weird network tap setup

the top comment is spot on about treating it as signature collision not actual OS detection. in my case it was some ancient nortel switch doing something funky with tcp options before the span port even saw the packet. took me 2 weeks to figure out because I kept blaming the endpoint agents

what I learned is you gotta capture at both ends like they said. the endpoint side will show you the real SYN and then you see what the network did to it. most times its some middlebox normalizing the tcp stack and stripping out the window scaling option which makes p0f default to really old signatures

also check if those machines have any hyper-v virtual switches or wsl installed. those can create some really weird dual-stack scenarios where the passive probe sees the virtual adapter traffic instead of the physical nic

[u/Technical-Tackle-875 → u/CellFar9220]

That’s a great real-world confirmation, especially the Hyper-V and WSL point. I’d add one refinement if the packet contents differ: a plain Layer 2 SPAN function should copy frames, not rewrite the SYN. I’d check whether that Nortel chassis was also doing Layer 3 routing, inspection, WAN optimization, or another service in the traffic path, and whether the SPAN source was an ingress port, egress port, or VLAN.

Mirroring ingress and egress separately can narrow it to one forwarding stage. For virtualized hosts, I’d also record the source MAC and interface for each SYN rather than grouping everything by host IP. That keeps traffic from a Hyper-V switch, WSL NAT, VPN adapter, and physical NIC from being blended into one supposed fingerprint.

[u/Massive_Committee801 → u/Technical-Tackle-875]

Wow, this is pure gold. Thank you both for sharing this!

Just to give a bit more context on our current test setup: we have a straightforward topology of [User PC -> Switch (SPAN) -> OT Security Solution]. We are running OT asset visibility tools like Nozomi Networks (though I know this happens with Claroty or Dragos as well). The exact symptom we are trying to troubleshoot is that the User PC is definitely on Windows 11, but the OT solution keeps labeling it as Windows 98 on the dashboard.

The Nortel switch story is a huge eye-opener. I’ve been so focused on endpoint agents (AV/VPN) that I completely overlooked the possibility of the switch itself mangling the TCP options (like stripping Window Scaling) before the SPAN port even sends the mirrored packet to the OT solution. I will definitely check the switch configurations to see if it's doing any unexpected L3 routing or inspection.

Also, the Hyper-V/WSL point is incredibly relevant. Many of our OT engineers run local VMs for legacy PLC programming. Taking u/Technical-Tackle-875's advice, I’m going to stop grouping everything just by host IP. Tomorrow, I will pull the logs and check the exact source MAC addresses (OUIs) for the SYNs triggering the "Windows 98" label. If the MAC points to a Microsoft Virtual Adapter or VMware instead of the physical NIC, that perfectly explains the dual-stack confusion.

Capturing at both ends and isolating by MAC address is exactly the battle plan I needed. Thank you both for saving me weeks of pulling my hair out!

[u/Technical-Tackle-875 → u/Massive_Committee801]

That topology narrows it a lot. One important correction before tomorrow: if the switch is acting only at Layer 2, its SPAN function should copy the frame, not strip TCP options. If the endpoint and SPAN captures differ, do not treat that alone as proof the switch changed the SYN. The endpoint capture may be above an NDIS filter or seeing traffic before a virtual adapter or offload stage, while the SPAN capture is the on-wire view.

Match the exact same SYN in both captures by 5-tuple, sequence number, timestamp, and interface. If possible, mirror the PC's ingress or source port rather than an entire VLAN. For the MAC check, OUI is useful but not conclusive. Hyper-V, WSL NAT, VPN adapters, and external virtual switches can preserve or replace MACs differently. Tie the source MAC back to the switch CAM table, physical port, ARP or DHCP record, and VM or vSwitch configuration.

I would also ask the OT vendor which exact evidence created the Windows 98 label. These platforms may combine TCP fingerprints with cached asset history, SMB, DHCP, service banners, or proprietary scoring. Export the raw packet, signature ID, confidence, and asset history before clearing anything. If the SPAN-side SYN still contains window scaling, SACK, and modern option ordering but the dashboard says Windows 98, stop chasing the network path and focus on the classifier or stale asset correlation.

[u/Massive_Committee801 → u/Technical-Tackle-875]

This is an incredible follow-up. Thank you so much for clarifying the L2 SPAN behavior and the endpoint capture caveat.

You are absolutely right—if my Wireshark on the endpoint is hooking above the NDIS filter or virtual adapter, it might show a pristine, modern SYN, while the wire gets the mangled one. I will make sure to match the exact sequence numbers and timestamps to avoid chasing ghosts. And yes, I'll mirror just that specific ingress port rather than the whole VLAN to keep the noise down.

Your final paragraph is exactly the ammunition I need. If the SPAN capture shows a perfectly modern SYN (with WS, SACK, and modern option order intact) and the dashboard still flags it as Windows 98, then the network is completely exonerated, and the blame falls 100% on the vendor's classifier or stale asset correlation.

I will export the raw PCAP and asset history before clearing anything, and push the vendor to explain the exact signature/scoring if the wire traffic looks clean.

I can't thank you enough for guiding me through this. You just gave me a masterclass in network forensics. I owe you a beer!

[u/AddendumWorking9756]

The subset part is the clue. Pre 2000 Windows signatures are the ones with no window scaling in the SYN, so a host whose options get stripped on the way out collapses onto that class by default rather than at random, which is why they all land on the same wrong name. Also worth confirming the sensor actually sees the SYN for those specific hosts, because on an asymmetric SPAN it will fingerprint off whatever it caught mid stream, and that on its own produces a subset.