When I came into work after the weekend, a very interesting e-mail message was waiting for me. The message, with the subject line "Account Alert", appeared to be from our helpdesk. It requested that I read an attached document pertaining to my user account.
The attachment was named "account-info.exe." This was very alarming. We have invested heavily in various technologies to prevent e-mail with executable file attachments from making it through our external mail gateways, but it looked like one had gotten through. My fears were validated when others in the IT department said that they had received the same e-mail. Of course, a good percentage of the people in the IT department know that executable file attachments should never be opened, since they are often used as vehicles for distributing malicious code.
Unfortunately, there is apparently a substantial number of employees in our company who either didn't know this or were fooled into believing that the e-mail originated from a trusted source.
The timing of this message couldn't have been worse. As part of the process of synchronizing our user accounts, we have been sending out official communications to our users regarding the upcoming resetting of passwords. So users have grown accustomed lately to seeing important e-mail from the IT department. This e-mail didn't follow the official company communications format, but a lot of users didn't pay much attention to that. The result: lots of users opened the attachment, and their machines got infected.
After we analyzed the attachment, we realized that our network was infected with the W32.Mytob.DP@mm worm. This worm is nasty. It does a lot of the usual stuff, such as adding entries to the host file, registry keys, services and so on. But it also includes its own mail relay, which allows it to find e-mail addresses, distribution lists and address books located in popular e-mail programs and send e-mail, including that executable attachment, to everyone it can find. In this way, it replicates itself. But W32.Mytob.DP@mm also attempts to open an Internet Relay Chat session within a certain chat room. If the worm is successful in connecting to the chat room, it sits idle, waiting for a command from the IRC server. This command can cause the infected system to download files or conduct other malicious activity.
I've seen such worms install keystroke-capturing programs and periodically send the keystroke information to the IRC server. That sort of activity wasn't observed in this case, but its potential to damage the company was still high.
The problem with worms like this is that traditional virus-protection software rarely detects them. We usually don't find out about worms or Trojan horses until we get a call from our network engineers complaining about excessive bandwidth or latency problems, or when the help desk informs us that it's getting bombarded by calls from employees whose desktops aren't working properly.
To deal with this latest worm, our intrusion-detection system guru simply looked for outbound, external connections to Port 4512, which is the rogue IRC port that we determined was waiting for infected machines to "call home". When we identified traffic connecting to that port, we could then trace the IP address back to a switch port. If the IP address was that of a desktop, all we had to do was disable the switch port until a helpdesk technician could be dispatched to remove the worm. The helpdesk put together a script that goes through an infected desktop and removes all the actions that the worm has initiated.
After this incident was somewhat resolved, I had an interesting conversation with a couple of my security engineers. We talked about the current use of the IDS. Several years ago, we deployed the IDS to watch for signs that a hacker was attempting to compromise our network. Among other things, we looked for various types of buffer overflow exploits, port scans, denial-of-service attacks and other attempts to take advantage of a publicly advertised weakness in some application.
But I noted that in the past several years, our IDS has been used more for detecting policy violations (such as the use of peer-to-peer file downloading and chat rooms) and tracing malicious code (worms, Trojan horses and viruses). I couldn't remember the last time our IDS was used to catch a hacker targetting our company via a buffer overflow or other sophisticated attack. We still configure our IDS rule base to look for those types of signatures, but we really haven't seen anything substantial.
Most of the time, the worst that happens is that our external network is constantly being probed by hundreds of suspect IP addresses every hour. We used to try to contact service providers to let them know that someone within their network was probing us, but we never got any type of disposition, so we limit the complaints to only the top offenders.
Our IDS infrastructure currently monitors about 98 percent of our network. We are constantly getting calls from the network team, helpdesk staffers and desktop support people to assist them with monitoring and analyzing network traffic and to help them discover malicious activity on the network. The IDS might be our most valuable and prized piece of infrastructure, and it's probably saved the company hundreds of thousands of dollars in support calls and unneeded resources.
The next step is to get a robust event management infrastructure and automate much of what we do, so that we can offload a lot of this activity to the newly created security operations team.
This journal is written by a real security manager, "Mathias Thurman", whose name and employer have been disguised for obvious reasons