Too many long nights and early mornings were partially to blame for the precipitation of a sense of panic that ensued when the following was seen in ISA's live query:
So, a quick search for the destination port of 5571 turns up: Trojan "Lamer Variant".
ISA: Unidentified IP Protocol: Source Port 1175, Destination Port 5571
The next step was to figure out what the program/service was and where it was.
The inital PortQry using the GUI version turned up (unknown service) for the sending port of 1175. That was not too encouraging.
SysInternals' Process Explorer was also turning up nothing out of the ordinary.
The next step was to run the SysInternals Rootkit Revealer. After 45 minutes of scanning - this particular server has huge arrays - nothing out of the ordinary seemed to be there. The scan kept on going with nothing to show for it.
The Symantec A/V on the server was up to date and running with no indications of any interference.
By now, the panic has set in, and the thoughts swirling around were along the lines of, "Mr. Client, we need to perform a Swing Migration in the next 5 minutes." Not really a bad thing given they have a secondary AD server that also has the arrays mirrored. Or is it? With the possibility of rootkit infection, we may be pulling just the data from backups.
Mr. Client's reaction would probably not be too happy. :(
So, as a final effort before having to consider the above meeting, a full port analysis was needed - just in case.
In the command line PortQryV2 directory the following was done:
- portqry -local -l serverlog.txt [Enter]
After the serverlog.txt file was created, we opened it in NotePad, and did a find for 1175 to see if anything came up and low and behold:
Bingo. Open the Task Manager and shutdown the javaw.exe service, and the UDP errors in ISA disappeared.
Process ID: 2476 (javaw.exe) on UDP Port 1175
Java is required for the Intel Management software that runs on the server. We had updated it during the last update run last week on that particular SBS box. So, something has changed in the program.
The DNSStuff.com report for the IP:
Reverse DNS for 188.8.131.52
strul.stupi.se. (an authoritative nameserver for 229.in-addr.arpa., which is in charge of the reverse DNS for 184.108.40.206)
says that there are no PTR records for 220.127.116.11.
A Whois for the mentioned .se server turned up Switzerland with no details. Not sure what Java is up to there.
For now, we will leave Java running, but not allow the UDP communication to pass through ISA to that 229 IP. We may even place a full ISA application restriction against it just in case.
After all of that, a huge sigh of relief and a little Irish kick! We got to smile and say, "Good day" to Mr. Client on our way out. ;)
UPDATE 2007-10-12: One thing that wasn't considered was searching for the actual IP listed. It seems that the IP is drawing people to the blog via search.
A question on Experts Exchange: Possible Hacker 18.104.22.168 mentions that the IP address may be an internal "Multicast" IP for the 229/8 range.
It would possibly explain why the Destination Network in ISA was Internal and the Source was the Local Host. It would also explain why there were no rDNS PTR records for the IP.
From the Internet Assigned Numbers Authority we have the following document: Internet Protocol V4 Address Space that indicates:
229/8 Sep 81 IANA - MulticastPersonally, this is not one of my strong points. So, please feel free to comment on whether this is the right direction or are we barking up the wrong tree?
Microsoft Small Business Specialists
*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.