CryptoLocker Ransom Virus Cleanup

In case you haven’t discovered the CryptoLocker virus, it is a particularly nasty virus that sits unannounced on your computer and basically encrypts a whole variety of useful files that you would save with the following file extensions:

*.odt, *.ods, *.odp, *.odm, *.odc, *.odb, *.doc, *.docx, *.docm, *.wps, *.xls, *.xlsx, *.xlsm, *.xlsb, *.xlk, *.ppt, *.pptx, *.pptm, *.mdb, *.accdb, *.pst, *.dwg, *.dxf, *.dxg, *.wpd, *.rtf, *.wb2, *.mdf, *.dbf, *.psd, *.pdd, *.pdf, *.eps, *.ai, *.indd, *.cdr, *.jpg, *.jpe, img_*.jpg, *.dng, *.3fr, *.arw, *.srf, *.sr2, *.bay, *.crw, *.cr2, *.dcr, *.kdc, *.erf, *.mef, *.mrw, *.nef, *.nrw, *.orf, *.raf, *.raw, *.rwl, *.rw2, *.r3d, *.ptx, *.pef, *.srw, *.x3f, *.der, *.cer, *.crt, *.pem, *.pfx, *.p12, *.p7b, *.p7c

The virus encrypts the files using a Public AND a Private key.  The only way to decrypt the files is to pay the $300 ransom asked of you which basically provides you with the Private Key to decrypt your files.  The virus gives you a countdown warning that if you don’t pay the ransom within the ever diminishing time, then the Private key will be destroyed and your data will be toast!

Having been called to deal with another CryptoLocker virus discovered on a new customer’s computer recently, the damage to the server was overcome by restoring all data from a recent backup but I was now looking at cleaning up the infected client’s computer (which had been removed from the LAN and switched off).

To stop the warning message appearing, I used Rkill (the iexplore.exe version – I find this works more often that using the rkill.exe version) to highlight the random .exe file that is running, but as there are usually two copies of the file running, once Rkill identifies the name of the file, it will kill one of the processes, but the 2nd will spawn another version of itself and so you find that the processes are still running.

A quick DOS TASKKILL command will kill both processes off at the same time (taskkill /f /im randomexefilename.exe)

Once the processes have been stopped, I then use Roguekiller to identify and clean up the computer, noting the name of the two .dll files that are created in c:\users\USERNAME\appdata\roaming and then scour the registry for those .dll files and the original randomexefilename, removing any traces that are found.  I also check to make sure the .dll and .exe files are removed too – you can’t be too careful.  The .exe file usually resides in c:\users\USERNAME\appdata\roaming\randomfoldername.

Once the registry is clean, you can then look at recovering local files from the Shadow Copies.  There is a good write up on BleepingComputer on how to do this, so I won’t expand on what’s written there.

During my cleaning of the computer today, I noticed that the folder that contained the randomexefilename.exe file was created back in July 2012 and the two .dll files in appdata\roaming were created on the 1st October 2013.  As I had a vague idea the infection came in via Email, I looked for odd emails on the 1st October in the users mailbox and noticed that there were several emails with the Subject: “Your Amazon.co.uk order #” which all contained attachments and were all .ZIP files.  Having deleted all those emails and checked the Anti-Spam logs on the server, the emails appeared to come from Hotmail.com accounts, so I tweaked the filters on the Anti-Spam Software on the server (Vamsoft ORF Fusion) to block all .ZIP file attachments (except from trusted sources).

So it would appear that this particular virus, or at least the origins of it may have been hiding dormant in the customer’s computer since July 2012 and then the opening of the .ZIP file attachment on the 1st October added more to the virus and then it finally completed its encryption of files a week or two later at which point it popped up its ransom demand.

This particular customer was lucky because they backup their files nightly and Shadow Copies were enabled on the client computer, so encrypted files could be recovered completely, but if you are reading this now and you have the warning and don’t have a backup, then you will need to pay the $300 ransom to get your files back.  If you kill the virus off and tidy up after it and don’t have a backup, you can kiss your files goodbye permanently.

Alan

BT Should Stick to Telephones and Not Configuring Mail Servers!

Having received a call from a customer today having problems receiving mail from their customers via our Mail Servers, I looked through our Anti-Spam logs (Vamsoft ORF) and filtered the logs to show rejected mail for them and then I looked through the rejected mail for the problem sender and checked out the details of the sending server, which turned out to have the following Fully Qualified Domain Name:

HESA01UKER.HE.LOCAL

The related IP Address was 213.123.26.92 which is a BT IP Address. I then re-filtered the logs to show all mail from servers with an FQDN of *.HE.LOCAL and there were about 60 entries all coming from similar named servers:

HESA02UKER.HE.LOCAL
HESA03UKER.HE.LOCAL
HESA06UKER.HE.LOCAL
HESA06UKER.HE.LOCAL
HESL01UKER.HE.LOCAL
HESL02UKER.HE.LOCAL
HESL04UKER.HE.LOCAL

Well – all the related IP Addresses are BT IP Addresses and half of the sender addresses were *@BTCONNECT.COM addresses, which would suggest to me that they are all BT Mail Servers.

So – what’s the problem? Well, the problem is that any mail server that is configured with an FQDN ending .LOCAL is not RFC Compliant (email standards) because the FQDN must resolve back to the IP Address that the server is connected to the internet with but a .LOCAL FQDN cannot be resolved as .LOCAL domain names are only resolvable internally and thus when a receiving server sees a .LOCAL FQDN, then server may reject the connection attempt because it cannot resolve the FQDN in DNS and thinks the server is a spamming server.

So – BT need to get their act together and configure their servers properly as their customer’s emails will be getting rejected by some other mail servers (including ours) and as usual, the people sending the emails will think that it is a problem with the receiving server, which it isn’t.

Constantcontact.com Mail Servers Cannot Send mail to servers using Greylisting!

We have recently started using Constantcontact.com to keep our customers up-to-date with the goings on at our company and have been very happy with the service until today when we looked at the number of invalid email addresses that were being reported. Upon investigation, we even discovered that the emails to our own servers that use Vamsoft ORF for Anti-Spam filtering, with Greylisting configured, was not receiving any of the emails being sent from Constantcontact.com.

For those of you that don’t know what Greylisting is, it is a method used by Anti-Spam software to reject the first send attempt from an email address that the server has not received mail from before. Because most spammers will only try to send a message once, then move on to the next target, they don’t usually come back to try again. As an anti-spam tool, this technique is incredibly effective. If the sending mail server tries to send the message again, then the receiving server using Greylisting will not reject the second connection attempt unless it has other issues with the sender, the sending server or the sender’s IP Address etc.

Getting back to Constantcontact.com – having contacted their support team, it was determined that their servers only ever send a message the once and if they encounter a server that uses Greylisting, their servers cannot distinguish between an invalid email address rejection message (550 5.1.1 Unknown User Error) and a Temporary Rejection Message (451 4.7.1 Temporary Rejected – Try Again Later), so they fail the send attempt and class this as an invalid email address. They advise that an email will get tried again 16 days later, but most Greylisting software has a timeout of 24 hours, by which time if they haven’t heard back from the sending server, they then temporarily reject the next connection attempt and then start the 24-hour countdown again. With a 16-day retry interval, the mail from Constant Contact will NEVER reach a mail server using Greylisting.

The support team at Constant Contact’s advice was to contact the recipients and request that they Whitelist (expressly allow mail from their mail servers) the Constant Contact IP Addresses. Considering that we had about 150 “Invalid Email Address” rejections out of about 500 messages, we didn’t find the suggestion that we should contact every customer who they couldn’t email to ask them to Whitelist the Constant Contact mail server addresses a very helpful or indeed practical solution.

As an Exchange Administrator – I am reluctant to Whitelist IP Addresses / mail servers as this can open up the receiving server to problems should the sending server that is Whitelisted become infected. As the problem would appear to be an issue with the mail server configuration at Constant Contact not retrying an email, we have decided to look for an alternative provider that can work properly with servers using Greylisting.

If you send out messages using Constant Contact and have plenty of “Invalid Email Addresses” in your mailing list, then you need to think about using a different provider until they change their working practises because the chances are your email addresses are perfectly valid, but you won’t ever be able to send them emails using Constant Contact.

You have been warned.

****** UPDATE *******

Further to the above information, it now appears that Constant Contact can work happily with Greylisting servers, but the bigger problem that they face at the moment is being blacklisted on pretty much all their servers by UCEProtect Level 1.

Exchange 2007 / 2010 Queues Filling Up With Postmaster Mail to Invalid Domains

If you have an Exchange 2007 / 2010 Server and you notice that your queues are filling up with mail for domains that do not seem to be going anywhere and no-one internally has emailed those domains, you need to check to see who it is that is sending these emails.

Open up the Exchange Management Console, then click on the Toolbox, Open the Queue Viewer and then double-click onto a queue that is for a domain that you don’t recognise.

If you see as the Sender, then your server is sending out Non-Delivery Reports back to emails that are received at your server for recipients that don’t exist.

To check your server configuration, please open the Exchange Management Shell and type in the following:

get-recipientfilterconfig | ft RecipientValidationEnabled

You will most likely see the result showing as False, meaning that your server is not filtering Recipients on your server.

The problem with this is that if your server accepts all messages, then tries to deliver them, realises that some are destined for email addresses that don’t exist, your server becomes responsible for sending back a Non-Delivery Report. Now suppose that the email is spam and that the spammer has made-up the sender address. Your server will then be sending a Non-Delivery Report back to either an invalid email address, a valid email address for which the recipient had not sent the email in the first place, or worst of all, a honeypot email address (one that has never been advertised but has been hidden for spammers to find) designed to trap spam mail. If an NDR email arrives at a honeypot address, YOUR mail server will end up getting blacklisted on such sites as Backscatterer.org, causing you problems sending mail to some domains.

How to fix this problem?

Well, if you have an Edge Transport server, simply run the following command in the Exchange Management Shell:

Set-RecipientFilterConfig -RecipientValidationEnabled:$true

This simple command will tell your Exchange server to check the Recipient email address for any inbound email and if the address does not exist on the Exchange Server, it will immediately reject the message, resulting in the sending server becoming responsible for sending a Non-Delivery Report.

If you don’t have an Edge Transport Server – only a Hub Transport Server, you will need to install the Anti-Spam Agents by running the following comand in the Exchange Management Shell:

Exchange 2007:

Install-AntiSpamAgents.ps1

Then, run the above command also in the Exchange Management Shell:

Set-RecipientFilterConfig -RecipientValidationEnabled:$true

Exchange 2010:

Read the following article for how to install the Anti-Spam agents:

http://technet.microsoft.com/en-us/library/bb201691.aspx

then run the Set-RecipientFilterConfig command.

If you find that you have not got Recipient Filtering enabled and have to Enable it by using the command above, please pay a visit to MXToolbox, enter your Mail Server’s IP Address and see if you are Blacklisted on Backscatterer.org (or any other blacklist sites for that matter) and request de-listing if you have fixed the problem.

Demon’s (Thus Telecom) Response about their mail server’s being Blacklisted – Do they give a damn?

A customer of ours was having trouble sending us emails recently and the usual reason is that the IP Address of the mail server that was sending the mail to us is blacklisted (our servers check against various blacklists to cut down on spam just like every other good mail server should).

So, after receiving a copy of the email headers from our customer, we checked the sending server’s IP Address 195.173.77.148 and sure enough, on checking on MXToolbox we discovered that they were on 3 blacklists (Lashback / Redhawk and SORBS).

So we asked our customer to get in touch with their ISP (Demon / Thus) and ask them to request that the IP address gets de-listed. That was when the fun started!

After a couple of emails back and forth between us, our customer and Demon (Thus), we received the following response:

—————————————————————————————————————
“It appears that it-eye.co.uk are using SORBS to filter their mail.

There are many blacklists available on the Internet but not all blacklists are created equal. We actively monitor a number of the larger public ones to ensure that we are aware of problems with both our service machines and our customers.

However, it is our opinion that this particular list is a rather aggressive one and sees abuse teams as the enemy rather than an ally.

They also do not appear to provide any evidence for their listings so we will not be submitting any removal requests.

Recipients must understand that if they use such lists, they may very well be losing legitimate mail.

If this is causing you difficulties then there are 2 options available to you:

1. Alter your configuration to send mails directly rather than via our smarthost (if your systems are able to support this).
2. Send your mails to one of the smarthost machines that aren’t presently listed; this is a list of the current machines:

195.173.77.132
195.173.77.133
195.173.77.134
195.173.77.148
195.173.77.149
195.173.77.150

Please note that this is only given as a possible fix for a temporary problem and that you generally should only refer to the smarthosts as ‘post.demon.co.uk’.

—
Network Abuse Team
THUS
a Cable&Wireless Worldwide business”

—————————————————————————————————————
Having picked myself up off the floor, I decided to check out the IP addresses that they listed and guess what, here are the results!

195.173.77.132 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs
195.173.77.133 – Blacklisted on Lashback & Sorbs
195.173.77.134 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs
195.173.77.148 – Blacklisted on Lashback, Redhawk & Sorbs
195.173.77.149 – Blacklisted on Lashback & Sorbs
195.173.77.150 – Blacklisted on Backscatterer.org – (badly configured server) plus Lashback & Sorbs

Now you don’t get listed on Backscatterer.org unless your servers are badly configured and send out Non-Delivery Reports to spammers, so it is very clear that Demon do not have a clue about configuring mail servers and clearly don’t care that their IP Addresses are blacklisted and are not prepared to do anything about it. Please read the Wikipedia explanation of what Backscatter is.

So – ask yourself – are you going to use Demon as your ISP? I certainly know that they won’t be appearing on my top 1 million ISP’s 🙂