LAN to Non LAN Private Network
-
My LAN is 192.168.2.0/24. But Windows clients periodically attempt connection to 192.168.1.x network.
Specifically 192.168.1.6:60802 UDP and 192.168.1.8:38808 TCP.
Any idea what is doing that?
-
Can you ping 192.168.1.6?
-
No.
Pinging 192.168.1.6 with 32 bytes of data:
Reply from 192.168.2.1: Destination host unreachable.There is no such local network and it ends up being routed out the WAN.
-
Diagnostics/Packet Capture may give a clue…
-
Where did you notice it?
Are those connection attempts only or did they find their target? -
Where did you notice it?
Are those connection attempts only or did they find their target?Noticed when I put a float rule on WAN out that blocks RFC 1918 networks (private networks).
Connection attempts only. Target is non-existent. SYN for the TCP attempts.
-
Packet capture would be interesting.
Is it all Windows clients or a specific one?
Did the network addresses change from 192.168.1.x to 192.168.2.x recently? -
…put a float rule on WAN out that blocks...
Sure about that?
pfSense blocks ingress, not egress -
My LAN is 192.168.2.0/24. But Windows clients periodically attempt connection to 192.168.1.x network.
Specifically 192.168.1.6:60802 UDP and 192.168.1.8:38808 TCP.Any idea what is doing that?
Have you ever had any devices during the history of the windows machine that were at those ip addresses, or devices like a smart phone synched with the machine where the smart phone has connected to those ip addresses elsewhere like a work network? Old IP addresses do get cached by some apps which could explain it.
Packet capture might show up something unless its encrypted, at which point you need to find out whats trying to communicate.
If you see some software you suspect running in task manager, one way you can tell if its using the network stack is to hook into it using http://www.rohitab.com/apimonitor, select the network api's (you'll need to look these up) https://msdn.microsoft.com/en-gb/library/windows/desktop/ff818516%28v=vs.85%29.aspx tick the ones you want to monitor, then just watch & log the output, paying attention to the memory addresses & parameter values passed.
Thats assuming its a program you can see running in the taskmanger.
If its a rootkit (old dos app loaded at boot time), the api monitor wont help, but scanning through the sectors on disk can show up code in hex.
One guess is an old network connection to a shared folder and AV is attempting to scan network shares, but theres so many possibilities and limited data in which to narrow it down like history of the machine, including if a quick format was used when installing windows which can leave data (botnet suites) in rarely used parts of a spin disk waiting to be activated by mundane malware, what devices have connected to it like network printers/photocopiers with eproms of sorts, smart phones, VM's running of cloned devices, old network setups running in VMwares network configuration service, DCOM, etc etc.
Without know more about the machine, theres not alot to go on, other than suggest a process of elimination.
This is why I block everything attempting to go out except what I allow out.
-
@mer
re: packet capture; Just SYN packet. Not very interesting.
re: All or just one Windows clients; All
re: Address change recently; No recent address changes. Even happens on a recently installed machine.@jahonix
re: sure about that?; Yes. Look into firewall float rules.
re: pfSense blocks ingress, not egress; On the interface rules yes, float rules can be configured for egress.@firewalluser
At least one of the machines is new fresh install. So no history of devices at those addresses.
Packet capture is just TCP SYN.@All
Hadn't seen any since late last night. Fired up Skype (desktop version 7.8.0.102) and about 10 minutes later their it is again. Coincidence or cause? -
@mer
re: packet capture; Just SYN packet. Not very interesting.
re: All or just one Windows clients; All
re: Address change recently; No recent address changes. Even happens on a recently installed machine.@jahonix
re: sure about that?; Yes. Look into firewall float rules.
re: pfSense blocks ingress, not egress; On the interface rules yes, float rules can be configured for egress.@firewalluser
At least one of the machines is new fresh install. So no history of devices at those addresses.
Packet capture is just TCP SYN.@All
Hadn't seen any since late last night. Fired up Skype (desktop version 7.8.0.102) and about 10 minutes later their it is again. Coincidence or cause?Check the installation of agreement of skype.
Any information you pass over the skype network allows MS to investigate.
I stopped using it 4/5 years ago when Bing started probing one of my webservers trying to access a URL which is only known to me for an app I was developing and the person I gave that info to in a Skype chat.
Have you ever mentioned the ip addresses 192.168.1.6 and 192.168.1.8 in a skype call or skype chat linked to the account you are using, that you can recall?
-
Have you ever mentioned the ip addresses 192.168.1.6 and 192.168.1.8 in a skype call or skype chat linked to the account you are using, that you can recall?
Only after the fact.
-
…when Bing started probing one of my webservers trying to access a URL ...
No it's not Bing. It's an NSA proxy.
German magazine Heise had a lengthy article about it. -
Well if you can not tell anything from the sniff of what it is.. Then look on the machine for what application/service/dll is generating the traffic. Those are clearly not standard ports for services.
Simple netstat -anb should help you find the PID of the program trying to make the TCP connection. The udp might be harder to catch.
-
…when Bing started probing one of my webservers trying to access a URL ...
No it's not Bing. It's an NSA proxy.
German magazine Heise had a lengthy article about it.Aren't they all, Facebook, Twitter, Google, Yahoo, Bing, Windows, Skype, routers, disk drives, "smart" phones, etc, 3 letter agency proxies. Get people to freely hand over personal information and there is then no need for a search warrant. And even worse, no oversight.
-
Well if you can not tell anything from the sniff of what it is.. Then look on the machine for what application/service/dll is generating the traffic. Those are clearly not standard ports for services.
Simple netstat -anb should help you find the PID of the program trying to make the TCP connection. The udp might be harder to catch.
I'll give that a try.
So far it seems to have a timing correlation with Skype activity. Just sent a Skype to a friend and poof there it was again after nothing since last night.
-
Packet capture on the inbound/LAN interface should yield a MAC address.
-
Packet capture on the inbound/LAN interface should yield a MAC address.
Already know the local machines that are involved. Have a LAN firewall log and pass rule for private networks that are not LAN network. Then the float WAN out rule blocks.
-
UEFI bios? Bios virus have been around for a long time before UEFI and considering things like this, maybe flashing your bios on the machines in question might stop the behaviour?
http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/I'm assuming you've ruled out dos root kits loading before windows?
An interesting read which your economic well being amongst other things could depend on, if you want an idea of how innovative some of the thought processes can be. I'm sure some will see the links as nice propagation.
NSA Journal of Information Warfare 2015
https://cryptome.org/2015/08/nsa-jiw-2015.pdf
NSA Journal of Information Warfare 2014
https://cryptome.org/2015/08/nsa-jiw-2014.pdf -
seems odd that skype would send to those IPs.. Is that something that is resolving to those IPs.. I would flush the local cache on the machine, then doing a sniff on your pfsense with no limit on the packets (defaults to 100) and fire up your skype if you think that is what is kicking off the traffic - does it query for any names that resolve to those IPs for some strange reason?
