Evaluating malware from a network perspective
A few days ago, my HIPS software blue-screened three separate machines after an update. Fearing a problem with the HIPS software, I disabled it on all three machines while I troubleshot them.
Today while looking through my HIPS log like a good sec analyst, I see an interesting event logged on one of the hosts. The file c:\windows\system32\wbem\unsecapp32.exe (MD5: 60f8ea044b96b7ae8c1a55571d7e2c70) tried to contact 211.22.66.246 on port 7654. Google searching for the file name produced little help beyond this (the fact that AhnLab’s AV engine didn’t detect this one leads me to believe it’s a relatively new variant)
I checked the network IPS and found no alerts for the host, so I downloaded the file to my test workstation (a parallels host, go virtualization!) and scanned it with our AV and of course it didn’t detect anything. Virustotal.com was down at the time so I couldn’t upload it to have it scanned, so I decided to open a port on the firewall for the host so I could capture a full TCP session with the machine it was trying to talk to on port 7654 and lo-and-behold it joined an IRC channel and checked in as a bot (see the sample window below).
As I’m watching packet captures, I see email alerts start trickling in from my four-year-old, home brewed IDS as the compromised host scanned dark subnets in our network for port 445 (RPC DCOM, the Blaster vuln LSASS). I built the IDS with relatively high thresholds in order to reduce false positives so it evidently took a bit to reach the first of three thresholds. Evidently the scanner subsystem of the worm is either inefficient or intentionally slow-and-low. Either reason could help explain why I can’t find much information about this specific worm, bot, wormbot, botworm…whatever. UPDATE: The scan for TCP/445 was aggressive, it just started late. The host was on the enterprise network for two hours before it started the scan and in twenty minutes it tried to access 14,560 hosts.
Here is the tcp analysis of the IRC traffic:
PASS wtfsondos12345 NICK USA|XP|SP2|00|19146 USER edthawj 0 0NOTICE IRC :.VERSION sux version cftp. JOIN #w1 s USERHOST USA|XP|SP2|00|19146 JOIN #!,#^ (null) JOIN #wL4n s
After I digested everything and decided I had a genuine threat on my hands, I notified the local IT team, who walked over and unplugged the machine immediately and took it back to their department for some quick forensics.
They manually removed the bot and did a relatively thorough sweep of the machine for other nasties. They also patched the HIPS and re-enabled it. They were unfortunately not able to blow away the machine and re-image it (such is real life).
So to recap, here’s what happened:
- The host was vulnerable because the HIPS was disabled
- However, the HIPS was in logging mode (HIDS) and alerted to nefarious activity, which alerted me to take a closer look
- AV failed to detect the malware on the system
- The network IPS failed to detect the IRC /join or /nick commands, both of which its enabled to detect and block (later testing indicates it will detect and prevent XCHAT from connecting to an IRC channel)
- Egress filtering on the network firewall stopped the phone-home function of the bot, preventing an escalation of the compromise
Looks like defense in depth prevailed here.
Lessons learned:
- Whenever possible, deploy alternate protection in the event you have to disable your primary, in this case the HIPS. Had we simply enabled Windows firewall, I wouldn’t be writing this post.
- In the absence of any other protection, at least log, log, log. We covered this by switching the HIPS to HIDS mode and keeping an eye on the logs. We got lucky and caught the bug while the laptop was within our protected network.
- Maintain defense in depth! Despite the fact that I’ve deployed best-in-breed IPS units, I maintain my clunker IDS running on hand-me-down hardware, which in this case out-performed a $35,000 appliance.
- Implement draconian firewall rules. Egress filtering is truly the only thing that saved me here. The fact that the host couldn’t phone home and couldn’t scan past the firewall means that
- The compromise wasn’t escalated to an information leak or loss
- We didn’t contribute to further host carnage up stream as a result of our compromised host (we’re good net’izens after all)
- AV as we know it today sucks. 70% of the AV engines used by Virustotal.com were completely clueless that the laptop was pwned. That’s just inexcusable (though my hopeful for ‘08, Vipre, did flag it!).
I’m chalking this one up as a win and a wake-up call. You can never rest on your laurels. A constant state of vigilance is needed to maintain even a moderate sized network and when you drop your guard, even a little, you risk getting bitten in the backside.
And yes, I’ve submitted code samples and packet captures to my AV and IPS vendors and shortly to the ISC.
[...] Evaluating malware from a network perspective - Good find, process, and reporting. Today while looking through my HIPS log like a good sec analyst, I see an interesting event logged on one of the hosts. The file c:windowssystem32wbemunsecapp32.exe (MD5: 60f8ea044b96b7ae8c1a55571d7e2c70) tried to contact 211.22.66.246 on port 7654. Google searching for the file name produced little help beyond this (the fact that AhnLab’s AV engine didn’t detect this one leads me to believe it’s a relatively new variant) [...]
By www.andrewhay.ca » Suggested Blog Reading - Wednesday May 2nd, 2007 on 05.02.07 6:01 am
Hello.
First a suggestion: there are two other sites out there (that I know of) similar to Virustotal (although VirusTotal is the coolest and most actively developed one). You can use them if VirusTotal has an outage.
Second of all, in my opinion you seem to fall in the trap of the marketing people of the security vendors when you blame AV’s for not caching the given bot. AV technology is a reactive one by its nature and the whole “you can be safe just by installing our product” is propagated by the marketing department with no real technological foundation (as you just found out). Congratulation to you for having such detailed detection mechanisms which made possible to (a) find out that there is a problem and (b) get detailed data about it, but isn’t it a little overengineered? By creating a default deny policy for everything not sanctioned by the IT department these things can be easily avoided. While I realize that creating a whitelist might sound complicated and in some cases very difficult (how do you tell the CEO that s/he cant install games on her/his laptop?), ultimately it is the safest approach and will prevent 99% of the malware out there.
By Cd-MaN on 05.03.07 1:12 am
Thanks for the link. I’ll definitely check it out.
Regarding AV; I agree that in its current state it is a reactive technology and that is the whole problem. Its time that intrusion prevention gets their peanut butter stuck in AV’s chocolate. ‘Heuristics’ or similar technology in AV is key to the future of the product.
Regarding our security infrastructure being over-engineered, I haven’t heard that one before! I might understand your thinking the home-brewed IDS backing up the retail IPS might be overkill but it isn’t simply because they perform similar duties in different ways:
1. The retail IPS is a best-in-class solution that does deep-packet inspection and protocol analysis and has the ability to act on packets.
2. The home-brewed IDS monitors for deny statements based on firewall rules (configured as you said, default deny) and alerts on 3 pre-defined thresholds of X, Y and Z events.
The home-brewed IDS is much faster than the IPS because it is doing much less.
Not to mention the fact that the IPS doesn’t block a worm’s scan, only the payload delivery. Therefore with the IDS, we get a warning at the scanning phase of the worm (as long as the scans are blocked by the firewall).
By Michael on 05.03.07 9:07 am
In my opinion (and I’m by no means an expert in this), AV and IDS are both reactive technologies, in the sense that they need continious update to their engines / signatures so that they can function at their full potential. From a conceptual view they are very similar so I see no reason for one of them to be declared superior to the other. In fact they both rely on blacklisting which is (to put it mildly) not a very good security practice.
As for heuristics: they are an often misunderstood aspect of AV technology (again, mostly because of the marketing). They are not magic and are equivalent to a more permissive signature (for example one heuristic might be to flag executables which contain the algoritm to use \Device\PhysicalMemory to remove themselves from the process list). They detect “new” malware only in the sense that the detected malware wasn’t seen by a human virus analyst, but it is still based on “old” and well understood technologies. This means that heuristics can be evaded at least in two ways: (a) using new technologies or (b) hiding the usage of old technologies.
AV on company desktops is really overkill (IMHO) and also less secure than a good whitelisting product. Whitelisting is a simple and efficient way to provide a 99.99% protection and is easily applicable in a corporate environment where there is an IT department. AV products are more suitable for home users who don’t have the necesarry knowledge to decide if a piece of software is legit or not and want to run a wide variety of code on their machines.
Finally I would like to apologize if I offended you with the word “overengineered”. The truth is that I don’t have experience in managing / supporting large corporate networks, but I imagine that if I had to I could sleep sound knowing that a whitelisting solution is in place and not complicating myself if IDS’s/IPS’s.
By Cd-MaN on 05.04.07 12:52 am
No offense taken. I was just surprised to hear someone say we have over-engineered security, which is certainly a concern.
By Michael on 05.08.07 7:57 am
[...] *I had a run-in with an IRCBot a short while ago, delivered by a similar Big Yellow worm, that uses custom commands when joining the IRC server. Instead of issuing the standard “/join” and “/nick” commands, it simply uses “join” and “nick”, which sailed right past my IPS. The reason I caught it was because by default I block ports 6661-7000 outbound at the firewalls. I got curious what it was and opened the firewall temporarily while running a packet capture to see what it was. [...]
By mcwresearch.com » Micro defense in depth on 06.11.07 10:52 am