A hacked site or server is the most common reason behind an outbreak of spamming activity. But how do hackers actually do it?

A site can be hacked through vulnerabilities in scripts. It could be through the exposure of FTP or SSH access credentials. Those same credentials might get a hacker into the server administration panel or the web hosting panel. Once in, a hacker (or a bot managed by them) puts spam scripts on the site or server and sends spam through them.

To find where spam is coming from, you should analyze the service headers of the spam email or logs of the email service. You can also look at the log file access_log.

Sometimes, the website itself is not hacked. Instead, the server (for example, a rented VPS), downloads Perl or Python scripts via SSH. Spam or tunnel distribution is then organized via these scripts.

To fix this, you must conduct a full diagnostic scan on the hacked site, searching the server for malicious scripts. You must remove the script that is sending spam, and all other scripts used for hacking. Then, you must remove the vulnerabilities to protect against repeat hacking.

Spamming without hacking

I'd now like to consider some more interesting variants of hacker techniques. How can spam be dispatched without first hacking a site and without installing spamming scripts? There are five ways.

Site scripts that don't check the values passed in via requests are problematic. Legitimate scripts can end up being used to send spam when their vulnerabilities are exploited.

One example of this was reported in the VirtueMart plugin in Joomla, where anyone could send arbitrary text to any recipient as spam.

Another popular variant is the use of feedback forms. Many have weak bot protection (e.g. a CAPTCHA) or none at all. The problem is that weak CAPTCHA is easily bypassed by modern spam bots. If the form does not contain any mechanisms to protect against bots, the probability of spam is high. Examples of troublesome forms are ones like 'Call Me' or 'Quick Order'. These are often implemented as pop-up windows using an ajax handler.

Such issues are solved by adding a special field to the form with a complex 'I am not a bot' verification mechanism. A good example of such a mechanism is Google's reCAPTCHA.

On sites where user registrations are possible, a lot of emails can be created by sending registration notifications. Here's how it works.

A special bot sends specially crafted requests to the site several times per second. This creates new users in the database. An administrator sends an email notification to approve or reject the registration. Alternatively, a simple notification message is sent saying that a new user has appeared on the forum or website. Such messages can be sent at a rate of several hundred per hour.

This problem is often found on Joomla sites with an active K2 component, or on forums where the administrator has turned on the option to send registration notifications.

Although it may seem there is no genuine spam coming from such sites, the hosting company may still block the outgoing mail from the site. They can do this if the allowed limit on the number of sent messages has been exceeded.

You can solve this problem by adding a mechanism to protect against auto-registrations, for example, Google reCAPTCHA. An interim solution is to disable user registration notifications.

Another source of spam can be from proactive protection or monitoring plugins on the site. Public web resources, i.e. those indexed by search engines, are constantly being attacked. Scanners, bots and hackers search for sensitive files and vulnerabilities in scripts. If the site has a web attack monitor plugin, any page requests generate an email notification for the site administrator.

Given that there may be dozens of attacks per second, such notifications quickly turn into spam and clog the mail server queue.

For this, the hoster can block the mail service or even the whole site. This often occurs on Bitrix sites, if proactive protection and administrator email notifications are enabled.

Fortunately, incorrectly configured SMTP on a VPS or dedicated server is rare. But it is still possible. This particular problem is called Open Relay. It's a mail server through which any unauthorized user can send mail using the SMTP protocol.

If SMTP relay is active on your dedicated server, possibly because of incorrect settings, the server can be used for spamming. It will, most likely, be blocked by the service company due to a complaint from SpamCop or some other spam monitoring service. You can check the correct SMTP configuration on the server at mtoolbox.com. If the mail server is not configured correctly, contact the administrator immediately.

Corporate emails registered in the domain of the site are increasingly being compromised. Hackers get access to the mail servers through selection, interception and theft of passwords.

This can happen when a user is working on an unsecured network connection. There may be Trojans or 'key loggers' (programs that record and transmit keystrokes) on the computer or mobile device. Or, hackers will email an accountant or manager working with clients, hoping to connect with anyone who may not be particularly interested in, or aware of, information security.

If the mail is hosted on the host's servers, spam sent through the hacked email will also go through the mail server of the hosting company. The site owner will then receive notifications of spamming. By analyzing the service headers of sent messages, you can determine which email address sent the messages.

As a preventive measure, mailbox passwords should be changed as often as possible, and set to complex and different values each time.

Often, site owners who have mail on their host's mail servers receive a so-called NDR (Non-Delivery Report). This is a notification about undelivered email messages. In such cases, the email may contain a spam message itself, such as advertising text, a phishing link or a malicious attachment. It is clear that the user of the mailbox did not send these messages. When and how can this happen?

There are two ways:

   1.   Hacking the domain mailbox (mentioned above).

   2.  Sending messages with a fake email address.

The second approach works like this: hackers can use a random sequence of characters, instead of a user name, as the sender's email address. For example: asdfjhawfkjwf@mysite.com

If the message is not delivered to the recipient, the email is returned to this address. (There may be hundreds or even thousands of such messages.) If this mailbox is not registered in the domain, the message will go to the default inbox for undelivered mails, or it will be deleted.

Having the returned mail deleted is not so bad. But, attackers often use valid email addresses for sending spam, and can send email using a real address (e.g. admin@mysite.com) in the From field. If the corresponding SPF and DKIM authentication mechanisms are not configured on the mysite.com domain on which the email is registered, then all the undelivered messages will be returned to admin@mysite.com.

The only option for dealing with them is to set up an anti-spam filter on the mail server, or a filter that will delete NDR messages automatically.

Here are some recommendations for securely configuring domain mail services:

   1.   Connect the domain to specialized mail services such as HushMail or corporate Gmail. This will ensure the correct operation of the SMTP server, and let you use secure IMAP, providing the proper level of protection against spam.

   2.   Correctly configure DMARC, SPF and DKIM for your domain to protect against sender address changes.

Conclusion

Spam is not only a technical problem, related to unsafe mail server settings or vulnerabilities on the site. It can also be due to site owners, company employees and third-party specialists not paying attention to information security issues. This problem must therefore be solved with a combination of technical and organizational measures.