Hi,
On a server running Windows 2012R2 I use SysInternal's tcpview.exe and see SYSTEM PID 4 making unwanted connections to random public IPs on port 445. Lines appear for a few seconds, then disappear.
When watching Sysinternal's Process Explorer during that same time frame I see no new process appearing and disappearing. Even a simple netstat will give you that info (SYSTEM is trying to connect to external IPs on port 445).
If I shutdown a specific service related to remote log collection, the strange connections stop. The service's role is to connect to internal servers to poll for windows event logs.
So you have SYSTEM connecting to both internal IPs (which is ok ) and external IPs (which is not okay). Even the vendor's tech was unable to figure out what's happening. It is apparently not a configuration issue. I have multiple similar servers doing the same job with the exact same setup an configurations and only this one is acting up.
I dived into memory forensics but can't find a strangely named process, or improperly located executable, not some bad dll. 'malfind' shows nothing suspicious (as per the notes I have on SANS 508) . Netscan shows me data but I end up with lines like this which I do not find useful (unless I can make use of the memory offset value?)
0x1363b0a00 TCPv4 _server_IP_64242 80.106.26.167445 CLOSED 4 System
Any suggestions?
Thanks,
Have you checked persistence mechanisms, particularly the AppCompatFlags? I assisted with a case a few months ago where we had similar activity, and it turned out to be this
https://
Any suggestions?
Where do these IP addresses belong to? Perhaps they belong to Microsoft and and are part of their usual data collection procedures, called "Telemetry" and "User Experience Improvement".
If I were you , I would investigate these addresses first.
regards,
Robin
Check repository for any eventconsumers that are not present on other machines. That kind of stuff usually runs with high privileges, not 100% sure but probably equiv to System/NTAuthority.
EDIT Only thing i could find was that Microsoft networking runs with PID4, i.e. port 137-139 stuff. You really should disable that unless you really need it and/or firewall such connections.
Thanks for your replies
1. I checked the article from FireEye. The artifacts are not present on the system
2. The IPs are not related to Telemetry.
3. MDCR Good observation about MS networking. I did some research and cannot make sense of "Check repository for any eventconsumers that are not present on other machines." Can you expand on that concept?
https://
… I have multiple similar servers doing the same job with the exact same setup an configurations and only this one is acting up. …
Could be an advanced persistent threat (APT) using direct memory hooking, in which case you won't see an associated task other than the system.
Could be a simple typo in the remote logging configuation. Is there a DNS query associated with these strange connections? Is it actually connecting and exchanging data? (You may need to capture the traffic.)
Assuming your goal is to resolve vice prosecute, I suggest wiping the drives and rebuilding from scratch (not imaging).
Saw the IP address now, here is the Whois
https://
And yes, 445 is MS Directory services. Should never leave the network.
What i meant is that something could have infested your machines that does not show up, a place to hide out of sight of disk/processes is using eventconsumers, Fireeye got more info
https://
Normally an APT tactic, but others are quick to adapt TTPs.
You'll need this file
C\Windows\System32\wbem\Repository\OBJECTS.DATA
Part from that, maybe a rootkit. Can only speculate without sitting there and knowing your environment.
For now, just block the egress point in your network so no more connections can be established.
Turns out microsoft DNS client will append domain suffixes at the end of a hostname unless you end with a '.'
dns (internal domains - yes should have been .local ) list domain_1.com , domain_2.com , domain_3.com
Attempting to resolve ' some-host.domain_1.com. ' will stop at your internal DNS.
Attempting to resolve ' some-host.domain_1.com ' (no dot) will do
some-host.domain_1.com.domain_1.com
some-host.domain_1.com.domain_2.com
some-host.domain_1.com.domain_3.com
some-host.domain_1.com. (notice the dot)
Turns out the mostly used domain was in position 3 and the one in position 2 had it's equivalent on the internet (which had to be purchased). So folks for anything local, use mycompany.local and not mycompany.com
You see that in DNS debug mode on the client.
nslookup
> set debug
Try it.