ROKSO Home  |  ROKSO FAQs & Policies  |  About Spamhaus  |  FAQs
The Register of Known Spam Operations
Ruslan Ibragimov /

Evidence Menu:

Ruslan Ibragimov / Index

Country: Russian Federation
Stealth spamware creator. One of the larger criminal spamming operations around. Runs a CGI mailer on machines in Russia and uses hijacked open proxies and virus infected PC bots to flood the world with spam.

Ruslan Ibragimov / SBL Listings History
Current SBL Listings
Archived SBL Listings

How to fix a hacked Send-Safe DNS server? (& get off of SBL)

Spamhaus tries to help stop spam problems in many different ways. We would like to offer technical instructions to prevent this intrusion onto your server and advice on how to remove it once it's been hacked. Here are some reasonable ideas from server admins who have dealt with this problem. If you have more knowledge to share about this problem, please let us know.

Here are suggestions from several admins:

I don't know for sure, but my assumption is the server was hacked into on Remote Desktop, either by stolen password or by RDP vulnerability. (a Windows box)

> You don't fix it because you can't be sure of anything. It's no longer
> your server. You cannot trust anything because it just isn't safe to.
> Any application you use to check the system could be compromised too,
> either directly or through operating system utilities...
> Flatten & Rebuild is the only way to be sure...

>What was weird is that I blocked mail services and port 53 in the firewall. I then restarted the server and checked for outstanding MS updates. Suddenly, there was a whole bunch of them that showed up.
>Keep in mind, they have 4 DNS servers, and we did them all at the same time. Prior I was able to telnet to port 53. So I compared that traffic on another clients server and noticed I was no longer able to randomly connect from the outside on port 53 after repatching.
>Once all these servers were patched/repatched, I reenabled the services I blocked and it tested out good.
>So that this never happens again from any type of virus or malware, we still plan to implement the firewall rule to lock down the DNS servers to only communicate DNS with $ISP.

Related URLs

Machines infected with SendSafe or AMS mailer (which is different than the DNS hack above) get listed on XBL. Checking a listed IP in the Spamhaus Blocklist Removal Center will lead those addresses to the CBL page with these instructions:


IP Address [YOUR.IP.ADDRESS] is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet.

It was last detected at [DATE TIME] (+/- 30 minutes), approximately [N] days, [N] hours, [N] 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 [ABUSED.SMARTHOST.IP].

NOTE When a sendsafe infection starts to send email to the compromised mail server (at [ABUSED.SMARTHOST.IP]), 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 [ABUSED.SMARTHOST.IP].

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 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 [ABUSED.SMARTHOST.IP].

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.

The Register of Known Spam Operations (ROKSO) collates information and evidence on entities with a history of spamming or providing spam services, and entities affiliated or otherwise connected with them, for the purpose of assisting ISP Abuse Desks and Law Enforcement Agencies.
The address of this ROKSO record is:

The above consists of information in the public domain. The Spamhaus Project makes every effort to avoid errors in information in the ROKSO database, and will correct any errors as soon as it is able to verify the correction, but accepts no responsibility or liability for any errors or omissions, or liability for any loss or damage, consequential or otherwise, incurred in reliance on the material in these pages. The Spamhaus Project makes no warranties or representations as to the accuracy of the Information in ROKSO records. The information in the ROKSO database is for information purposes only and is not intended as legal advice of any kind.

For information on contacting the ROKSO Team regarding any factual errors in this record, see the ROKSO FAQs.
© 1998-2019 The Spamhaus Project Ltd. All rights reserved.
Legal  |  Privacy