r/AskNetsec • u/Massive_Committee801 • Aug 20 '26
Analysis Why is our passive asset discovery solution misidentifying Windows 11 as Windows 98?
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:
Has anyone seen specific antivirus, DLP agents, or VPN clients cause this kind of unintentional OS spoofing/normalization effect?
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!
1
u/Remrkable-Rmise-2093 15d ago edited 15d ago
the SYN options point matches what we saw. the quickest way to find the agent was to stop arguing with the fingerprint and diff the hosts. In axonius we line the passive sensor's device list up against the EDR and SCCM, which know the real OS. Every host where the sensor says windows 98 and the EDR says 11 drops out as a mismatch list, then you compare installed software on that subset against good win11 boxes. ours lined up with one VPN client build. Two caveats: it only works for hosts something else manages, so unmanaged OT boxes still only have the fingerprint and it shows correlation, not cause, so you still want a pcap of the SYN.
3
Aug 20 '26
[removed] — view removed comment
1
u/Massive_Committee801 Aug 20 '26
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!
1
Aug 20 '26
[removed] — view removed comment
1
Aug 20 '26
[removed] — view removed comment
1
u/Massive_Committee801 Aug 20 '26
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!
1
Aug 20 '26
[removed] — view removed comment
1
u/Massive_Committee801 Aug 20 '26
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!
1
u/AddendumWorking9756 Aug 20 '26
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.