Anatomy of a failed virus attack
It happened to me
Analysis Here follows a short story of a failed virus attack on me and my company, and why e-mail from strangers, hostile or otherwise is not a problem for us. I would like to draw your attention to two major points about security and e-mail, but which are also applicable to any other Internet protocol in this brief essay.
1. You need effective technology to protect you from the many unscrupulous people out there on the Internet who want to damage your systems, scam you or generally subvert your computing resources for their own ends.
2. Security via technology alone is not sufficient to combat the cyber-criminals who are out to get you, your business, and your computers. You need to be aware of what is going on around you and take control of the situation before you are compromised. Just as Ignorance of the law is no excuse, ignorance of your computing environment can also land you in deep trouble.
Back to the main plot. This morning I received the following e-mail which allegedly came from the address: firstname.lastname@example.org
*Dear user jim.kissel, *
You have successfully updated the password of your Osml account.
If you did not authorize this change or if you need assistance with
your account, please contact Osml customer service at: email@example.com
Thank you for using Osml! The Osml Support Team</p>
+++ Attachment: No Virus (Clean) +++ Osml Antivirus www.osml.co.uk
The address “firstname.lastname@example.org” was a syntactically correct “mailto:” link, and the “www.osml.co.uk” was a valid link to our web site. The time stamp on the e-mail was 06:55. For the record, “osml.co.uk” is "owned" by Open Source Migrations Ltd, and myself and Jack Knight are co-directors of this company.
Now I'm suspicious, even before I open this e-mail. I am not the administrator of our core machines, but Jack, who is, keeps me well informed of developments and we certainly hadn't discussed the need for a "register" user id. Even if Jack had needed to reset any passwords, he would have warned me, so I am already fairly certain that this is some form of malicious e-mail.
We have multiple lines of defence on our systems, one of which is in itself the Thunderbird e-mail client. This is further hardened by running on a Linux operating system. (I'll come to the other lines of defence later). There are a number of things you need to configure for safer e-mail in Thunderbird and indeed any other e-mail client software you may be using, namely:
- Block loading of remote images in mail messages
- Use secure connections (SSL) when retrieving and sending email
- Set View Message Body as Plain Text
These are minimum settings you should ensure you have set in your email client, and will block the most obvious attack vectors. Unfortunately not all of these are set as default when you install Thunderbird, but given these settings, I am fairly certain that I can safely open a email without suffering any damage. However, I can also see there is an attachment, and opening the message shows that it is a zip file. This is even more suspicious given that the source of the message is in doubt. Thinking about it logically, even if the message was legitimate, why would I be sent a zipped attachment with a change of password notification?
So my guard is up - what next? Let’s walk through the content of the message. The next give away is the greeting. "Dear user jim.kissel," - it looks like a robot or programmed reply. Most humans would realize that I'm Jim Kissel or Mr. Kissel, or Jim, not "jim.kissel,". So now I know we’re dealing with a spammer/scammer. The next step is to look at the email headers. Easy with Thunderbird, just hit control-U.
Analysing email headers can be a serious technical task, but is this case, there is a single line:
Received: from murder ([unix socket])
In any normal Internet message we would expect to see something like this line, and at least one other line with “Received:” at the start, as legitimate email MTA’s (Message Transfer Agents) add this information as a matter of course, and failure to record the path the message took from source to destination is a violation of the SMTP protocols.
The lone "unix socket" line suggests that there is a program and not a human on the other end of the line. Now, as said, this can under certain circumstances be perfectly normal, but the fact that this “Received:” line is flying solo, and there are no other instances of machines which have relayed this message is a very strong, if not irrefutable alert that this isn't a legitimate message. Even if a message is sent point to point over a corporate intranet, we would expect more than one “Received:” record line, and we would expect to see real machine names, or at least IP addresses in there.
Another line reveals:
Received: from osml.co.uk ([184.108.40.206])
Another giveaway. The IP address here is NOT ours, so someone is masquerading as us.