Solved

Our IP keeps getting listed to CBL

Posted on 2011-09-23
24
2,706 Views
Last Modified: 2013-11-21
Hello, We are running an MS Windows SBS 2008 Network with about 50 Workstations...plus a few remote users.  Some remote users RWW in to the network.  Plus, we also had a seperate Windows 2003 Terminal Server for other users. I say 'had' because recently I realized that we were hacked on the TS and security compromised by a program called 'Frae Raper'. Once it gained access, it installed a program called MASS SENDER (AMS) and started spamming.  Once I found the program and saw the logs there of the hack attack, I immediately pulled the TS off the network and also ran the uninstall program on it. It's powered off and is in line to be rebuilt. I then removed our IP from the CBL list.  Next day, I came in and once again...we were on the CBL list.  I thought that possibly messages were 'queued' and already sent relisting us. But I continued to hunt.  No sign of Mass Sender (or any hack on our SBS server/Mail Server)  and I checked each machine on our network myself for it, plus ran TSVIEW on them all to see if I would see any weird traffic... I did not.  Day 3...we're listed again!  I unlisted us and continued to hunt...running scans on the server with fresh copies of both MALWAREBYTES and SBS AVG... no malware found.  We also changed firewall rules around (SonicWall TZ190) to lockdown SMTP traffic and only allow pass with our domain.  Day 4 we were NOT listed... and so I thought we were out of the woods.  But today (Day 5) I came in and we were once again listed.  I'm not sure what to do with this thing...can't find it, to fix it.  Any help would be greatly appreciated!  
0
Comment
Question by:MkMx22
  • 15
  • 7
  • 2
24 Comments
 
LVL 21

Expert Comment

by:Papertrip
ID: 36589279
Block internal -> internet:25 for everything except your mail server, then monitor mail servers logs for suspicious activity and try to reference CBL timestamps if they exist.
0
 

Author Comment

by:MkMx22
ID: 36589535
Thanks for your response.  Yes, we had done that already on day 3...  But apparently the Mass Sender program doesn't utilize the mail program to send it's mails.  So I don't see any activity.  were also just listed again (second time today) just now.  Here's what it says when I click the link in the RBL notification below.  I also tried to look thru the Firewall logs for that IP it mentions below...but found nothing.


==========================

is listed in the CBL. It appears to be infected with a spam sending trojan or proxy.

It was last detected at 2011-09-23 18:00 GMT (+/- 30 minutes), approximately 2 hours ago.

It has been relisted following a previous removal at 2011-09-23 13:56 GMT (5 hours, 40 minutes ago)

This IP is operating (or NATting for a computer that is operating) the "sendsafe" or similar (such as Advanced Mass Sender - AMS) bulk emailing malware. This software is almost exclusively used for sending "Nigerian 419"/"advance fee" frauds or phishing attempts. It is also used occasionally to send pharmaceutical spam.

Sendsafe works by acquiring userid and password (usually stolen) for a valid email account on a mail server. Then, a machine compromised by sendsafe (in this case your IP) makes a SMTP connection to that mail server, authenticates with the compromised email login credentials, and proceeds to send spam emails.

One way to look for this is to look for authenticated outbound SMTP connections from this IP address either on port 25 or port 587. This particular detection was of a SMTP connection made from your IP address to IP address 221.12.20.122.

NOTE When a sendsafe infection starts to send email to the compromised mail server (at 221.12.20.122), it usually sends VERY VERY large quantities all at once. The compromised mail server probably can't relay it as fast as it's receiving it, so will queue it for later delivery. The timestamp we give above is the time which the recipient's mail server received it, _not_ when sendsafe sent it. Therefore, the reception timestamp may be as much as 4 days _after_ the sendsafe infection sent it. So, if you have firewall logs, search for at least the 4 previous days for connections to 221.12.20.122.

DO NOT BOTHER looking for emails in your mail server logs, because these infections DO NOT use your mail server software, and will obviously not show up in your mail server logs.

In some cases it turns out to be a SSH login account (with a weak or compromised password) used to proxy inbound connections to outbound SMTP connections. Check your SSH logs for logins from unusual places (such as Nigeria).

A number of these turn out to be "Mass Sender" (aka "Advanced Mass Sender 4.3", aka "AMS"). These often appear have been installed via some sort of remote desktop connection (such as RDT or VNC), and operated by the remote desktop connection. The criminal had gained access to the remote desktop connection via stolen/cracked/keylogged userid/password. First check Windows Installed applications (eg: Control Panel => Add or Remove programs...) and see if anything unexpected is there.

AMS can sometimes be found by doing a file search for the file "AMS43.exe" or a directory called "MassSender". Here is a report from one of our correspondants:

About 4:30pm CST I believe I found the actual culprit, Mass Sender
was installed on my terminal server last Wednesday.

I removed this software.  Here is a copy of some of its
install Log that I saved:

  ***  Installation Started 06/07/2011 13:39  ***
  Title: Advanced Mass Sender 4.3 Installation
  Source: C:\Documents and Settings\scanner\Desktop\ams\AMS43.exe | 06-07-2011 | 13:39:26 | 3919332
  Made Dir: C:\Program Files\MassSender
  File Copy: C:\Program Files\MassSender\UNWISE.EXE | 05-10-2001 | 10:04:28 | | 162304 | 432c52a3
  RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\Advanced Mass Sender 4.3
  RegDB Val: Advanced Mass Sender 4.3
  RegDB Name: DisplayName
  RegDB Root: 2
  RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\Advanced Mass Sender 4.3
  RegDB Val: C:\PROGRA~1\MASSSE~1\UNWISE.EXE C:\PROGRA~1\MASSSE~1\INSTALL.LOG
  RegDB Name: UninstallString

But remember, these detections aren't always AMS, so not finding AMS doesn't mean that you're not infected.

Important: If this IP is a NAT gateway/firewall, it could be any windows computer on your LAN. Examining your firewall logs for remote desk top connections from outside may help identify which computer it is. Obviously, if this IP is a NAT, you will have to scan all of your machines as described above.

With NAT gateways, frequently the best way to find it is to put in a network sniffer (make sure you understand the difficulties of sniffing packets in a switched network - see the sections on network sniffing in Advanced techniques and look for connections to 221.12.20.122

If all the above fails to find it, and you're redetected frequently, you may have to resort to "bisecting your network". For example: turn off half of your computers, and wait a day. If your IP relists, the "on half" of your computers contains the infection, and if it doesn't relist, the "off half" does. Then divide the infected half in half again and repeat until you've narrowed it down to one computer. Don't forget little-used computers in the "back room", terminal servers or the like.

After finding and removing the infection, make sure it doesn't happen again by securing your remote desktop connection as tightly as possible. Close the firewall to that port if possible. Change all passwords etc.

In some cases, it turns out to be that the machine has the "bitvise reverse tunneller" installed. It should be removed.

In other cases it appears to be a virus infection that may have disabled your Anti-Virus software. If you have Anti-Virus software, make sure it's operational and up-to-date.

0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36589648
That link lists pretty much everything to do, have you tried them all?
0
 

Author Comment

by:MkMx22
ID: 36589860
Yes, I've tried all of those as best possible. Searched the firewall logs for  221.12.20.122  IP and also anything that looks unusual. Checked all computers on the network for AMS43.exe and MASSSENDER...nothing found. (except for on the TERM SERVER which I already removed fromt the network. MASSSENDER Found there).  I don't really understand the reference to "In some cases, it turns out to be that the machine has the "bitvise reverse tunneller" installed. It should be removed."  So I'm not sure what to look for/remove?  But other than that...tried all of the above.
0
 
LVL 39

Expert Comment

by:footech
ID: 36596812
In other words, it may not be only the Mass Sender program causing the issues.

You stated:
We also changed firewall rules around (SonicWall TZ190) to lockdown SMTP traffic and only allow pass with our domain.
Can you clarify this?

Port 25 traffic should only be allowed from the IP of the SBS.  You may also want to disallow port 587.  Try a test from a workstation to make sure the rules are effective (telnet to port 25 on some external mail server).

You can check the logs in the SonicWall for port 25 connections.  Also you might want to run TCPView to check which processes are using port 25 on the SBS.
0
 

Author Comment

by:MkMx22
ID: 36600361
Thanks for your input FooTech. To answer your question, we created two rules on the Sonic Wall.

Rule 1
DENY all SMTP traffic LAN to WAN for any Source, Any Destination and this rule is ALWAYS On.

Rule 2
ALLOW SMTP traffic LAN to WAN...only from SOURCE = 10.0.0.10 (The internal IP of our Mail Server) to ANY destination and this rule is ALWAYS On.

I will try your TELNET and TCPView suggestions now and will write again with results.  
The only ports we have open at the moment are: 25,80, 443, and 8080.
Also, I had all users shut down their systems this weekend.  Only a 5 people work on the weekends. So I wanted to see if we would be listed or not.  These Users came in at all different times... from 8AM to about 11AM.  We were listed by 3:10PM.  Not sure if that's useful info or not.  But figured I'd include it.
0
 
LVL 39

Expert Comment

by:footech
ID: 36600522
Also, your TZ 190 isn't the model with wireless is it?  That would entail another rule to add if so.

One thing I'd like to mention, I'm a bit concerned that if you keep delisting your IP from CBL, and it keeps getting re-added, that when you do finally clear everything up they won't delist your IP for a long time.  Just a thought.
0
 

Author Comment

by:MkMx22
ID: 36600546
Yes, I'm concerned about the same.  Just don't know if we have many options here.  When we are listed...Mail is stopped for OPTONLINE, YAHOO, and some other accounts and is hindering business big time.  So I really have no choice but to delist...and keep digging.  The TZ we have is NOT the wireless version.  There is tho a wireless router inside our network (FIOS Actiontech).  But it is setup with encryption and a good password.
0
 

Author Comment

by:MkMx22
ID: 36600949
Tried telnet on port 25 to an external mail server to test FW rules.  Rec'd response: COULD NOT OPEN CONNECTION TO THE HOST ON PORT 25. CONNECT FAILED.   So it appears the rules are working.
0
 

Author Comment

by:MkMx22
ID: 36718792
Didn't see anything unusal with TCPview.  And we ended up on the list again yesterday.  Ughh.  Really running out of ideas here guys... Anyone have any input?
0
 
LVL 39

Expert Comment

by:footech
ID: 36719961
Is all traffic routing through the SBS (and then through the Sonicwall)?  If so, we haven't limited down which machine is the source of the email.

If you have a compromised account, emails could be using your Exchange instead of a separate program, which would explain why nothing's been detected by MalwareBytes, etc.  Have you checked Message Tracking to see if you see evidence of the messages going through there?

It wouldn't be a bad idea to make everyone change their passwords.

I would really think that the logs on the Sonicwall would provide the most information, assuming you can see far enough back.

0
 

Author Comment

by:MkMx22
ID: 36720145
Exactly what I was thinking FooTech!  I made everyone change their pass's today.  I also added another firewall rule to DENY all traffic on port 587.  And we enabled logging for TCP traffic from the mail server IP to 221.12.20.122 (which is the destination IP according to the RBL notification).  Though no traffic logged yet.  I will be calling SonicWall today as well to see if they can see or help in anyway with the firewall logging.  And to answer your question, Yes, all traffic is routed thru the SBS server, then the Firewall (going outbound...and vice versa of course coming inbound).
0
Do email signature updates give you a headache?

Constantly trying to correctly format email signatures? Spending all of your time at every user’s desk to make updates? Want high-quality HTML signatures on all devices, including on mobiles and Macs? Then, let Exclaimer solve all your email signature problems today!

 
LVL 39

Expert Comment

by:footech
ID: 36720771
OK, so you could have any machine on your network sending out the traffic, and the Sonicwall rules won't prevent it since it's appears to be coming from the SBS IP from the Sonicwall's point of view.

In addition to the Message Tracking to see if the mail is using Exchange, running Wireshark on the SBS to look at traffic would be a good next step.
0
 

Author Comment

by:MkMx22
ID: 36729497
Ok, will do. I will report back with any updates tomorrow.  Thx!
0
 

Author Comment

by:MkMx22
ID: 36818237
Update... we were listed again at 4AM last night, I released and we were off by 5AM.  Then we were listed again at 2PM today, and this time there's no link to delist.  Says... DELISTING INHIBITED.  So i guess we are sometype of probationary period.  Uggh. Feared this... Any one have any idea how long they will keep us on without allowing us to delist?  

I haven't done anything with Wireshark yet.  One of my tech friends said I need to put a PC with WIRESHARK on it between the firewall and the network switch...with two NIC's.  One NIC then goes to the switch, and one NIC goes to the FW. Thereby making the WireShark PC the intermediatarly to scan all packets. Is this the correct way to do this?

Also as a 'double check' I checked with SonicWall to see if there was any other ways to log more than we are now... in short the answer was no.  They also inspected my rules and all seemed fine.

But I did make some headway... when I requested the user Password change.  I realized there are a few users that we setup with OUTLOOK on their remote laptops that DON'T use RWW to pull in their mail.  We put the settings in outlook to connect back to the Mail Server directly so they wouldn't have to use OWA or RWW.  2 of those users, when I questioned them, told me that they think they may have viruses on their machines. So I've asked them to stay off their computers and bring them into me ASAP.  Hoping that is the hole...and I'm thinking it very well may be.   Maybe they have the bots on their PC's and it's just pulling the trigger to use our mail server to send the mail.  And that's why I'm not seeing anything on our internal network.  We'll see once I can get my hands on them.  Will keep u posted. Meanwhile, if you have any ideas... I'm all ears. ;)  Thanks.
0
 
LVL 39

Expert Comment

by:footech
ID: 36818353
Having read some of the information on their site, the only thing I can suggest is to email them and let them know that you are working on clearing up the problem and see if they will delist you in the meantime.

You can do that, but since all traffic is flowing through your SBS already, it wouldn't give you any more information.  Wireshark on the SBS will see all traffic from the workstations to or from the internet and SBS, and the SBS to/from the internet.  The only concern I would have about running it on the SBS would be a matter of system resources.

Were you ever able to check the Message Tracking in Exchange?
0
 

Author Comment

by:MkMx22
ID: 36818504
I haven't enabled Message Tracking yet. I'm a little leary to do this because we area also running out of space on our harddrive and the logs may throw us over the edge.

Also, would you know how to email CBL? I can't find any contact info at all.  I will definately do this if this is possible.
0
 

Author Comment

by:MkMx22
ID: 36818511
Also does anyone know how the probation period works...once they don't allow you to 'delist' yourself.  How long til we can get off?
0
 
LVL 39

Expert Comment

by:footech
ID: 36890146
The Message Tracking should take little space, and if you want you can disable it after.  I would find a way of deleting or moving some other files to free up space.  Obviously you need more information about what is going on to figure out how to stop it, and this could give it to you.

Please see the page at http://cbl.abuseat.org/faq.html and scroll down to the "General Questions" section for more information and instructions.  Their email is listed there.
0
 

Author Comment

by:MkMx22
ID: 36892868
Thanks... I just emailed them.  I will enable the message tracking as well. Will report back.
0
 

Accepted Solution

by:
MkMx22 earned 0 total points
ID: 36893978
Got some news!  I rec'd a mail back from the CBL Group...  Seems like they feel we've already wiped it out..but the queues are still sending (and may for weeks).  Here's what they say:

Hi Michael, there's a good chance you nuked it already. You are infected with Sendsafe somewhere. The problem with sendsafe is that so much email is sent that it clogs up the queue and can take days or even weeks to finish sending. So you may have swatted it but we will continue seeing mail just now make it's way out of the queue. For example, mail we are seeing today was originally sent on the 18th... So I will put in a lengthy deferral and keep your fingers crossed. Complete whatever tests you want to perform and simply wait and see.

On your step number 7, ('searching the firewall for TCP traffic to IP 221.12.20.122 (the destination IP according to the RBL notification') remember that you should be checking as far back as the 17th for these connections to 221.12.20.122. That was originally when these connections were made.

As a heads up as well, it appears that the times these connections were made were the 17th at 22:00GMT - 18th 05:00 GMT. This could be that the attacker is limiting his attacks to the overnight or that simply so much mail has filled the queues that we aren't seeing mail yet from later on the 18th..

I've removed the entry from the list and inhibited redetections for the next 15 days.

It may take a few hours to propagate to the public nameservers. The CBL will relist the IP if it detects the same thing again after 15 days from now.
0
 
LVL 39

Expert Comment

by:footech
ID: 36894566
That IS good news.  It's worth following up just a bit more to make sure everything's clear, but in the meantime you won't have keep delisting yourself every day.  Hopefully it was just limited to the one TS server and you've already knocked it out.
0
 

Author Comment

by:MkMx22
ID: 36894595
Yes, we will continue to monitor closely.  And glad to not be delisting everyday!  I sadly couldn't retrieve logs back as far as they requested.  Apparently, when u power cycle the firewall it wipes out the logs and you start fresh from there.  So I could only go back a few days (with his suggestion of going back to the 17th in the logs).  Lesson learned... have a STRONG admin password even if it's only a terminal server.  And if anything...this exercise, made us batten down the hatches here.  So I guess it's all good in the end.  I'll keep this case open a bit longer in case anything further happens.
0
 

Author Closing Comment

by:MkMx22
ID: 37126815
Thanks everyone who tried to help with this issue... As it turned out... we had the problem licked from day 1, but the abundance of the mail that the MASS SENDER program had previously sent out was the real issue here.  Once that all filtered out... within about 2 weeks.  Along with the steps that we had already taken; Removing the terminal server from the network, and battening down the hatches network wise... (close all unneeded ports, Disallowed port 25 for any mail items NOT coming from 1 of our internal IPs (firewal rule), and making sure all users and server had NEW PASSWORDS, and up to date virus/spyware protection.  That was the fix.  Again, many thanks for your input along the way it was appreciated.
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

The new Microsoft OS looks great, is easier than ever to upgrade to, it is even free.  So what's the catch?  If you don't change the privacy settings, Microsoft will, in accordance with the (EULA) you clicked okay to without reading, collect all the…
Citrix XenApp, Internet Explorer 11 set to Enterprise Mode and using central hosted sites.xml file.
Windows 8 comes with a dramatically different user interface known as Metro. Notably missing from the new interface is a Start button and Start Menu. Many users do not like it, much preferring the interface of earlier versions — Windows 7, Windows X…
Viewers will learn the different options available in the Backstage view in Excel 2013.

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now