Best methods for tracing a mass-mailing worm infected workstation ona network?

  • Thread starter Thread starter BadBoy House
  • Start date Start date
B

BadBoy House

I've had instances in the past where a workstation has been infected
with a mass-mailer worm and whilst I resolved the issue in the end I
encountered the following circumstances in relation to the infected
workstation:-

- no up-to-date anti virus package found any mass mailer worms. I
tried Panda, McAfee, Norton.
- no port 25 traffic (other than the mail server) was going through
the router (I checked all the logs/tables)

In the end, via a process of elimination and used malware bytes anti
malware to find, and remove the virus.

I'm interested in finding out about any other proven methods for
tracking down mass-mailer infected workstations. It seems it can be
like finding a needle in a haystack.


What methods would you suggest?
 
From: "BadBoy House" <[email protected]>

| I've had instances in the past where a workstation has been infected
| with a mass-mailer worm and whilst I resolved the issue in the end I
| encountered the following circumstances in relation to the infected
| workstation:-

| - no up-to-date anti virus package found any mass mailer worms. I
| tried Panda, McAfee, Norton.
| - no port 25 traffic (other than the mail server) was going through
| the router (I checked all the logs/tables)

| In the end, via a process of elimination and used malware bytes anti
| malware to find, and remove the virus.

| I'm interested in finding out about any other proven methods for
| tracking down mass-mailer infected workstations. It seems it can be
| like finding a needle in a haystack.


| What methods would you suggest?

Packet tracking for oddball address patters.

Which "mass-mailer worm" or is this really a spambot infection ?
 
BadBoy said:
I'm interested in finding out about any other proven methods for
tracking down mass-mailer infected workstations.
Click to expand...

What are you using for a network switch or hub?

Most of the larger units have a web interface that lets you look at
various interface (port) statistics, maybe even let you block TCP port
25.
 
From: "Virus Guy" <[email protected]>


| What are you using for a network switch or hub?

| Most of the larger units have a web interface that lets you look at
| various interface (port) statistics, maybe even let you block TCP port
| 25.

You mean a "Managed Switch".
 
Well whatever. The lack of reply from the original poster is telling.

Perhaps he got wiped out by his own mass emailing worm :-)
 
Packet sniffing for port 25 is a technique I already use. As is
blocking port 25 however what if you get an infection that uses a
different port??
 
BadBoy said:
Packet sniffing for port 25 is a technique I already use. As is
blocking port 25 however what if you get an infection that uses a
different port??
Click to expand...

Trojanized or botted PC's that are used as spam proxies will be
performing direct-to-mx spam runs and will be using port 25 because it's
the universally recognized port.

You might want to block MX lookups on your network, or at least look for
any PC that's performing a lot of them.
 
BadBoy said:
however what if you get an infection that uses a different port??
Click to expand...

To expand on that a little:

While port 25 is the defacto, world-wide port that is universally
recognized for client-to-MTA or MTA-to-MTA email communication, there
are other ports:

Port 366 (TCP,UDP) On-Demand Mail Relay
Port 465 (TCP) SMTP over SSL (usually the default for Outlook)
Port 587 (TCP) message submission port (usually SSL)

I would expect that the success rate of a spam relay trying to use those
ports to be quite low.

Those are the SMTP ports. Not mentioned are the IMAP protocal ports
(143, 993). And also not mentioned are the POP ports (used to retrieve
email, not send it).

Most organizations and ISP's block out-bound port-25 on their network
boundary from all their internal machines or IP space except those
machines that are dedicated MTA's or out-bound SMTP handlers. All
internal PC's are supposed to send mail through those machines on
port-25 or any of the above ports.

Again, one way to find a spamming PC on your network is look for the PC
that's trying to send a lot of traffic on port 25 to IP's other than
your designated out-bound SMTP handler. Or look for a PC that's doing a
lot of MX lookups.

You might also want to look for traffic on the above ports (366, 465,
587) because trojans that discover that you've blocked port-25 might try
those (you should block 366 and 587 as well as 25).
 
I've had instances in the past where a workstation has been infected
with a mass-mailer worm and whilst I resolved the issue in the end I
encountered the following circumstances in relation to the infected
workstation:-

- no up-to-date anti virus package found any mass mailer worms. I
tried Panda, McAfee, Norton.
- no port 25 traffic (other than the mail server) was going through
the router (I checked all the logs/tables)

In the end, via a process of elimination and used malware bytes anti
malware to find, and remove the virus.
Click to expand...

It likely wasn't a virus. :) As our software doesn't really deal with
those. You may wish to consider the commercial/pro version as it offers
realtime protection against nasties known to it, as well as IP blocking
of known malicious websites. It's a onetime registration, not a yearly
deal unless your a company...
I'm interested in finding out about any other proven methods for
tracking down mass-mailer infected workstations. It seems it can be
like finding a needle in a haystack.
Click to expand...

Watching router traffic can often tell you which computer might be
responsible for consuming a large portion of the bandwidth for spamming.
What methods would you suggest?
Click to expand...

Wireshark.
 
I'm interested in finding out about any other proven methods for
tracking down mass-mailer infected workstations. It seems it can be
like finding a needle in a haystack.

What methods would you suggest?
Click to expand...


Wireshark - monitor the network for a few hours and then review the
report. You can filter by port, ip (destination or sending), protocol
etc. No network admin should be without.

Did I mention it is freeware?
 
| Simplest way is to use a computer running Wireshark and a network HUB (*not*
| a switch).

| Unplug the connection between the main internet source and put the HUB
| in-between them. A hub will let you listen to the other traffic going
| through it. A switch won't. This will let you listen transparently to all
| traffic running through the hub. Then filter for mail traffic from anything
| other than your legitimate internal mail server host(s).


Assuming that the NIC PC connected to the hub is promiscous, then Wireshark on that PC
will "...listen to the other traffic going through it"

The statement, "A switch won't" is misleading. A managed switch supporting RMON probes
will.
An unmanged Ethernet Switch won't because, by its nature, each port is a traffic cop only
allowing traffic be passed to each switch port based upon the MAC address of the traffic.
 
| If it's connected to a hub then it will hear all traffic.


No. Not true. If the NIC of the node using WireShark or other protocol capturing decoder
is NOT able to be in a permiscuous mode then it will not see all the traffic on the hub,
only those packets intended for that node on the hub.


| Semantics.

This is NOT semantics. It is an important fact that can not be casually left out and
needs to be clarified.
 
As an additional side note, be careful about sniffing network traffic.
You're going to possibly collect or see information that people might not
otherwise like to know you've seen. This is an area where logic doesn't
matter, it's all about perception. The fact that you've seen what people
might consider "personal", even while they're at work, might have disastrous
side-effects on your continued employment. Be extra careful not to
accidentally make enemies... Focus on a specific problem, document the
problem and your proposed solution and present it to management. Get their
buy-in on the full scope of your solution AND STICK WITH THE PLAN. Even
this is no guarantee. But at least you'll have that plan as CYA material
when things go pear-shaped.
Click to expand...

Ahh, yes, the memories. <g> A year or two ago, a vendor was brought
into a wireless carrier's data center to help resolve some issues with
that vendor's equipment. Part of the troubleshooting involved running
automated tests against a list of web sites, with the list being
created from sites that had been recently visited. As it turned out,
one of the target sites was a gay pr0n site, but the bigger question
at the time was whether it was actually gay kiddie pr0n. I've never
seen such a case of 'hot potato', where no one was willing to do
anything other than pass the issue up the management chain. Quite
humorous when viewed from a distance, but probably not nearly as
humorous for those who were directly involved. I don't _think_ anyone
lost their job over it, but I know there were multiple frantic and
heated phone calls at the executive level as a result.
 
Back
Top