There are five main steps to fixing a hacked website, and they MUST all be completed:

1. If it is at all possible, the website/server should be taken offline while it is being fixed.
2. All of the infected files must be removed.
3. The CMS and all plugins and extensions must be updated to the latest and most secure versions.
4. Be sure the server itself is secure, or ask a system administrator to perform a security audit.
5. All passwords must be changed. Strong passwords should be used, and two factor authentication added wherever possible.

Take your website offline: The whole time that a server is infected, it poses a threat of some kind to the rest of the Internet (spam, DDoS, botnet command node, malware infector, phishing websites, etc).

• Domain reputation will suffer as a result of any infection. That drop in reputation will affect not only websites but also email… and not just due to Spamhaus listings.
• It is very important to temporarily suspend an infected website, if possible, while it is repaired and secured.
• Taking it offline will help protect domain and email reputation: this is a strategic decision with the fewest bad consequences for both the website operator and the Internet at large.

A good place to start is with Spamhaus’ news blog on how to Stop Spammers from Exploiting your Webserver. Additional in depth information:

• Spamhaus CBL’s page about CMS vulnerabilities.
• MELANI.admin.ch offers a paper to on how to clean up hacked websites. They also offer one on how to prevent a compromise.

Website software known as Content Management System (CMS) is a common vector for security attacks on websites. This can result in domains being listed by Spamhaus.

In all cases, the website’s software – including the CMS and any related extensions or plugins – must be patched to a secure version and the infected files must be removed and the server itself must be secure in order for a domain to stay out of Spamhaus lists.

• If hacked pages are detected after a domain has been de-listed, the domain will quickly be re-listed.
• That re-listing should serve as an alert that the website and/or web server are still compromised, and that quick corrective action is required.
• If re-listing happens too many times, we will prevent further removals until we are assured that the problem has been properly fixed.

All webservers, webserver software operating systems (OS) should also be checked and all patched to current versions. Please, secure your server(s).

These infections can and do affect any operating systems (OS). We see these infections on Windows/WINNT, Linux, FreeBSD, Darwin and more, and on Apache, nginx, squid, Microsoft-IIS and other web servers, too.

Anti-virus scans usually do not detect these infections. Running an a/v scan is a good thing to do, but negative results do not mean that the website or server are clean of infection.

We are also receiving reports of accounts with compromised FTP passwords.

• Be sure that the FTP password is strong and secure.
• Use secure SFTP for end-to-end encryption to avoid having passwords stolen during transmission.

For ISPs: some possible solutions – unknown, untested and not vouched for by Spamhaus but still of possible interest:

• Patchman.co
• Sucuri.net
• Owasp.org
• Github WPSscanteam

Hacked websites in the news (Arstechnica); old but still relevant: Active malware campaign uses thousands of WordPress sites to infect visitors – Sep 18, 2015, by Dan Goodin

NOTE: This FAQ applies specifically to IPs listed in CSS due to a compromise, insecurity or infection. For listings related to low reputation, unsolicited mail, etc, please refer to our FAQs for marketing and bulk email

Why was this IP listed?

This IP was listed because we have evidence suggesting that the IP or something behind it is compromised, insecure or infected.

What should be done about it?

The situation requires correcting: Spamhaus has detected spoofed SMTP connections coming from this IP address.

• To stop the abuse immediately, close port 25 on the router or firewall and restrict port 25 access to known email servers.
  • Note: this will only prevent the abusive connections from leaving your network. If the problem is (for example) an infected mobile phone, when it moves to another insecure network, it will resume its activity without restriction.

Due to the complexity of the threat landscape, we are unable to advise on the exact nature of the problem. Also, we can only see what’s coming from the public IP and have no insight into network configurations. We hope the following information might be of help.

• For Windows operating systems the following free tools can sometimes help: Windows Defender, Malwarebytes, Norton Power Eraser, CCleaner and/or McAfee Stinger.
• All operating systems: Check tool-bars, extensions and plug-ins on each browser for anything you don’t recognize. Look for for “free” VPNs or other heavily-monetized apps, which often have a great many advertizements. We have seen many mobile devices (mostly Android phones) being turned into spam proxies as a result of installing questionable apps.
• Calling your provider, IT department, or taking your suspect machine(s) or device(s) to a competent tech support service might also be useful.

Is this IP a NAT gateway, firewall or router?

• Is the IP a NAT gateway, firewall or router? The infected devices are usually computers or other devices behind the router.
• In some cases, the compromised device CAN be the router itself.
  • Ensure that telnet port 23 (UDP and TCP) is not accidentally left open.
  • Please consult the documentation of your device regarding how to make sure its software is up to date, and how to ensure that the device is properly secured.
• You can use packet sniffing or logging at the router or firewall to see what’s trying to use port 25. Only mailservers should be generating such traffic, since software for sending or reading email relies on the dedicated ports 587 or 465.
  • Wireshark is a good (free) tool to investigate network traffic.

Routers and firewalls should be configured with port 25 disabled and SMTP Authentication enabled.

CSS listings expire automatically a set number of hours after last detection.

To ensure uninterrupted email delivery, it is critical that all technical settings be correct. In case of difficulty, they should be double checked.

• Misconfigured SMTP servers may have problems delivering email to many networks, including ones that do not use Spamhaus data.

SMTP servers should be configured with correct forward and reverse DNS and HELO/EHLO values.

• DNS is used to resolve a domain name to an IP address. This act is known as a forward DNS and is performed every time you visit a site on the internet. Reverse DNS (rDNS) is a method of resolving an IP address back to a hostname. Your hosting company or email service provider can help set this up or correct it.
  • If you need to correct your rDNS and are using OVH cloud or Amazon cloud (Lightsail) they have information on their websites that can help.
  • The forward DNS lookup (domain name to IP address) of your IP should match the HELO value set in your server.
• HELO is an SMTP command sent by an email server to identify itself when connecting to another email server, to start the process of sending an email. It is followed with the sending email server’s hostname.
  • One way of testing whether an SMTP server is misconfigured is to send an email from it to helocheck@abuseat.org. A bounce will immediately be returned that contains the required information.
  • Common misconfigurations of HELO are: “localhost.localdomain”, “WIN-XYZPDQ01” or “mail”.
  • A HELO/EHLO value should be a fully qualified domain name (FQDN)
• About loadbalancers:
  • Some sites place their mail servers behind load balancers. While this may have some advantages, this practice has the side-effect of giving the public-facing IP the appearance of being infected by malware. If this is the issue, then the solution may require an engineering design change.

NOTE: If the IP is not a mail server, or the HELO settings are in fact correct, check for malware or a misconfigured process. You may need to contact your IT department, network engineer, MTA vendor or hosting company for help.

Misconfigured Plesk hosts can have unexpected outcomes – the behavior of such a host closely mimics the behavior of a certain type of spambot.

Plesk’s online guide describes the “Outgoing mail mode” option and its three settings:

• • Send from domain IP addresses:

By default, mail from each domain is sent from the domain’s IP address. The host name used in the SMTP greeting is the Plesk server host name specified in Tools & Settings > Server Settings. Selecting this option may result in mail sent from some or all domains being marked as spam if the Plesk server host name fails to resolve properly, or if the domain’s IP is different from the one to which the Plesk server host name resolves.

This option works best if it is required to have a single IP address on the Plesk server.

• • Send from domain IP addresses and use domain names in SMTP greeting

If selected, Plesk changes the mail server configuration so that the SMTP greeting contains the name of the domain from which the email message is sent.

Warning: Selecting this option may result in mail sent from some or all domains being marked as spam if the destination mail server uses Spamhaus XBL and more than one domain on the Plesk server uses the same IP address.

In addition, selecting this option on Plesk servers hosting a large (more than 100) number of domains will likely result in significantly increased server load.

This option works best if there is allocated a dedicated IP address to every domain hosted on the Plesk server, and the number of domains hosted on the server is not very large.

• • Send from the specified IP adresses:

If it is required to use certain IPv4 and IPv6 addresses for all outgoing mail.

If None is selected, outgoing mail will not be sent.

The first setting is shown as ‘enabled’ in the section circled in red, in the screen shot below:

We recommend you use the first or third option in virtually all cases.

The second option, “send from domain IP addresses and use domain names in SMTP greeting” can lead to reputational and XBL issues, and should be used with extreme care:

• Many Plesk installations are unable to bind to different IP addresses to send email on behalf of each hosted domain. This is especially true if the web server uses a single IP address to host multiple domains by “virtual host” – there are no other addresses to bind to, so, it’s using the same IP address all the time.
• The “send from domain IP addresses and use domain names in SMTP greeting” option should only be used if you’re certain your installation can successfully bind to specific outbound IP addresses, and that each IP address will only be used for at most 2-3 different domains.

Bots can operate on nearly any internet-capable device!

• These devices can include (but are not limited to): laptops, tablets and pads, mobile phones, servers, desktop computers, code embedded in games, “Internet of Things” products like light bulbs and appliances, Fire TV sticks and even WiFi routers themselves.
• As of Q2 2020, our systems are detecting many bot connections coming from mobile devices, particularly those using Android OS with 3rd party apps installed.

When any of those bots emit spam, the connection may be detected by Spamhaus, and the originating IP listed by Spamhaus systems. Due to the fact there is such a variety of bots that operate in different ways, we are not able to give specific advice. Here some general ideas about identifying, securing or de-weaponizing an affected device.

• For Microsoft Windows operating systems any or all of the following free tools may help: Windows Defender, Malwarebytes, Norton Power Eraser, CCleaner, or McAfee Stinger.
• For all operating systems: Check tool-bars, extensions and plug-ins on each browser for anything you don’t recognize. Look for “free” VPNs and other heavily-monetized apps. We advise disabling these as part of the process of elimination outlined below.
• Calling your ISP, IT department, or taking your suspect machine(s) to a competent tech support service might also be useful.

WiFi networks and apps can often be diagnosed by a process of elimination.

• Remove all devices from the wifi system.
• Wait a few days to see if it relists in our data.
• Reconnect the devices, one by one, waiting a few days to see if a listing occurs, before adding the next one.
• When the IP relists, it is likely the newest device.
• When the problem has been located and fixed, please open a ticket for removal of the IP.
  • You can also use the lookup tool to monitor your IP’s status if you are concerned about another device or a re-listing.

NOTE: While each device is connected, open and use all the apps on it, since sometimes it is the use of the app which triggers the bot.

• Be particularly careful of recently installed or 3rd party apps. We have also found that malicious code is sometimes detected even in long-installed apps that have been recently updated.
• Removing or disabling apps, then slowly adding them back one by one, with several days in between, may work to identify the vulnerable software.
  • We are VERY interested in the specific app, version, and even the installed code of such apps, if you are able to provide that to us. Such information helps us help others.
• Do you supply a guest network or free wifi? If so, those often have a lesser security profile and should be reviewed.
  • Please close port 25 on your router or firewall, and also for your guest network if you have one.

If none of this works, professional help may be required. Please call your provider for information.

Routers and firewalls should be configured with port 25 disabled and SMTP Authentication enabled.

• Disabling port 25 will not stop mail software from working normally. The software for email clients, used to read and send email, operate on different ports (587 or 465), and such clients are able to access your ISP’s mail servers after being correctly configured with SMTP Authentication. From the user’s perspective there is no difference.

  • The majority of home networks will not be running a private mail server.
  • Some routers will allow you to configure a specific device, and only that device, to access port 25, and those can allow a mail server to operate on the router as well as preventing other devices from making malicious SMTP connections. If a private mail server is being used, this is the ideal solution.

• Closing port 25 will only prevent the abusive connections from leaving your network. If the problem is (for example) an infected mobile phone, when it moves to another insecure network, it will resume its activity without restriction. To find and eliminate the source of the problem, the process of elimination outlined in the WiFi and Home Networks FAQ should work. If not, seek professional help.

• Most routers provided by ISPs will have documentation regarding their configuration available on the ISP’s website. Enterprise equipment will have documentation online, or already provided to your IT department, and both types of gear should offer telephone support.

• When configuring a router to block port 25, it is best to not specify the source port (or use the ranges 0-65535 or 1-65535 if you cannot leave the source port values blank), and instead to only specify the destination port, as it can happen that a rule written that specifies both, will only catch traffic that matches both criteria of the rule.

  • Make sure you reboot the router when finished; some routers require this action before changes to the rules take effect.

• Mikrotik routers had vulnerable software. Most Mikrotiks have been patched, but in case yours still needs an update, you can find the current version on their website.

For help with any configuration of routers, devices, or email software, please refer to the device documentation, your ISP or IT department for assistance.

WordPress has an FAQ in serveral languages: “My site was hacked!” that has many tips and links.

• Ensure that the most current secure release of WordPress is being used.

Joomla has a Security Checklist, and specifies what to do if a site using their CMS has been hacked or defaced.

• Ensure that the latest release of Joomla is being used.

Drupal has an extensive security page, which has a link to their latest information on how to secure a Drupal installation.

• Ensure that the most current Drupal version is being used.

If TYPO3 is being used, ensure that the most current version of it is being used.

Spamhaus systems detect many StealRat remote access trojan (RAT) infections on CMS systems.

• XBL/CBL is also detecting and listing IP addresses with StealRat infections.
• CBL also mentions the “ebury SSH rootkit”, a sophisticated Linux backdoor. It is built to steal OpenSSH credentials and maintain access to a compromised server. Suggested reading regarding ebury:
  • Welivesecurity offers an in-depth analysis of Linux/Ebury.

You can check your website’s IP here.

For experienced administrators, a packet sniffer is a useful option to track down undesired network traffic. The key feature of a packet sniffer is that it captures data as it flows across a network and makes it available for review. There are many such tools available, both paid and free of charge.

• Wireshark and tcpdump are free of charge. A web search for “packet sniffer” or “network sniffer” will find many other options.

Some Wireshark usage suggestions to help track unwanted traffic to port 25

• Capture filter options – set to: port 25
• Display filter – set to: smtp.req.command == "HELO" or smtp.req.command == "EHLO"
• If the exact HELO string to look for is known: {smtp.req.command == "HELO" or smtp.rec.command = "EHLO) and (smtp.req.parameter contains "[HELO string]")

NOTE: Ensure that the above is adjusted so it only applies to sessions that are initiated from the problem IP – not to the IP.

This may work:

• ip.src == "insert problem IP"

If the packets being captured are carefully reviewed to locate anomalies, it should be possible to identify where they are coming from.