Best methods for tracing a mass-mailing worm infected workstation on a network?
BadBoy House
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?
David H. Lipman
Packet tracking for oddball address patters.
Which "mass-mailer worm" or is this really a spambot infection ?
--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp
Virus Guy
> I'm interested in finding out about any other proven methods for
> tracking down mass-mailer infected workstations.
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.
David H. Lipman
| BadBoy House wrote:
You mean a "Managed Switch".
The Central Scrutinizer
Perhaps he got wiped out by his own mass emailing worm :-)
--
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:hdifk...@news3.newsguy.com...
BadBoy House
blocking port 25 however what if you get an infection that uses a
different port??
Virus Guy
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.
Virus Guy
> however what if you get an infection that uses a different port??
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).
Dustin Cook
49e5-ad0c-e...@g23g2000yqh.googlegroups.com:
> 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.
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.
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?
Wireshark.
--
Dustin Cook [Malware Researcher]
MalwareBytes - http://www.malwarebytes.org
BugHunter - http://bughunter.it-mate.co.uk
Bill Kearney
> tracking down mass-mailer infected workstations. It seems it can be
> like finding a needle in a haystack.
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).
David H. Lipman
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.
Bill Kearney
> Wireshark on that PC
> will "...listen to the other traffic going through it"
If it's connected to a hub then it will hear all traffic.
> The statement, "A switch won't" is misleading. A managed switch
> supporting RMON probes
> will.
Semantics.
A great many sites don't have managed switches. It's reasonable to assume
this. Thus the suggestion of using a hub. It would allow inserting the
listening machine into the network without any changes to the network. No
router access or configuration changes required.
This, tangentially, is why it's important to make sure your network hardware
is physically secure. You don't want just anyone with a hub and a PC
connecting in there and sniffing the traffic. But that's a side issue.
And making changes to a managed network switch or router isn't necessarily a
trivial process. Make the wrong config changes and you risk crashing the
network. Done right, it works well. Done wrong and people get fired. It's
hard to explain to manglement why your attempts to fix something they didn't
know was 'broken' lead to a disaster. Transparently sniffing the traffic
doesn't disrupt things in the same way.
> 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.
Correct.
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.
-Bill Kearney
David H. Lipman
>> 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"
| 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.
>> The statement, "A switch won't" is misleading. A managed switch
>> supporting RMON probes will.
| Semantics.
This is NOT semantics. It is an important fact that can not be casually left out and
needs to be clarified.
Char Jackson
<wkear...@hotmail.com> wrote:
>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.
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.
Bill Kearney
"Char Jackson" <no...@none.invalid> wrote in message
news:u1p0g5lb8o3ldiqc0...@4ax.com...
That's a great example.
I made it clear at one site that if illegal material was discovered I would
not be held responsible for it. After I'd left that site, and they'd let
the filtering system go lax, they made the papers when one of their senior
employees was arrested for soliciting a minor online. It was with some
delight when I made the "I told you so" phone call. And even better when I
spoke with the police about their indifference about it some months before
the problem.
Bill Kearney
> 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.
If the adapter is one supported by Wireshark (relying upon WinPcap when
running in Windows) then it's a non-issue. A great many are. I'm sure you
can find edge cases that aren't. Feel free to burn your cycles doing so.
It's perhaps reasonable to point out that on the outside chance someone's
dealing with a network interface that won't work then it's probably a very
good idea to just purchase one that can. Start with what you've got and
confirm that it does the job.
> | Semantics.
>
> This is NOT semantics. It is an important fact that can not be casually
> left out and
> needs to be clarified.
Consider your nit picked.
And if you're going to be that way at very least get the spelling correct.
http://en.wikipedia.org/wiki/Promiscuous_mode
Can you move on to actually being helpful now?