Malware and Webs of Trust.

Hi everyone!

This week I wanted to talk to you all about a super interesting event that happened to me at work (at least I think its interesting). As you may or may not know, I am now in the security team. Life goal achieved! So I deal with somewhat different work than I used to as a tester.

When working as a tester, the usual incidents I would have to respond to were along the lines of bug’s that were affecting customers ability to use the site. Sometimes I would have to help other testers understand the intricacies of some of the lesser used tools. Obviously lots of awesome testing too.

There is some element of that to my job now too. I am still testing things all the time, just from a different perspective. Rather than having a customer-centric usability focus, I am now focused on making the customers interaction with us as secure as possible. I also have to respond to any security related incidents that we get at work.

The latter is exactly what happened last week.

We had a malware incident whereby a user clicked on a link in an email. This is pretty standard phishing type stuff, and we get thousands of these emails a month, just like any mid-sized organisation does. Thankfully, they are largely filtered out through our various layers of security.

If you don’t know what phishing is, it boils down to attempting to gain sensitive information/money by posing as a trusted entity. Usually in emails, although there are Skype/instant messenger bots, faxes, letters etc.

You may have heard of the infamous 419 scammers, who usually tell you that a Nigerian Prince is attempting to get some money out of the country. If only you could help them, by providing your bank account details to use to hold the money, they could give you a cut of millions!

Our users are pretty smart cookies. They would not click blindly on links in emails, would not run things without scanning them. But there are obviously always exceptions. These exceptions usually arise at the end of what in avionics is called the “Chain of events” or “Error chain” .

That term is used to describe the series of events that leads to a plane crashing. Aviation is heavily checklist oriented, in order to reduce the possibility of human error. It is a very effective mechanism for reducing accidents. But sometimes humans make mistakes. And sometimes those mistakes will allow another mistake to be made, and another, and another, until catastrophe.

Usually, any one of the errors in the error chain being caught will avoid the catastrophe. As we responded to the incident last week, we noticed a similar situation. So let’s set the scene, and see what lessons we can learn, and remind ourselves that failure is OK, to be expected, and a fantastic learning opportunity.

Employee 1 receives an email. Let’s call Employee 1 ‘Hugo’ (I promise it wasn’t me). Hugo is super busy, and the email is from a postal company. Let’s call the postal company YPS (I also promise it was not UPS). Hugo doesn’t really have time for the email, which says that he has to pay a small fee (less than €5) to retrieve a package that he ordered. Hugo is ordering stuff all the time.

So Hugo sends the email off to someone else who can deal with it for him. Hugo is super busy, remember? Hugo also likes getting all the stuff that he orders. Hugo forwards the email to someone with the TLA “FYI” at the top.

Employee 2 receives this email, which comes from Hugo. Let’s call employee 2 Boromir (I promise we don’t have the character from Lord of the Rings working with us). Boromir is also super busy, and he gets an email from Hugo with a FYI at the top, so assumes that Hugo wants them to fix the delivery charge and organise re-delivery.

There is a link to retrieve information about the package, which Boromir clicks on, and sees a .zip file downloaded. Boromir unzips the file, which reads something like “YPS.retrieve.package.file” . Boromir clicks on the file, and his screen flashes but then nothing happens. Boromir has a new message from Hugo on the corporate chat client. Hugo is asking what Boromir did with that email.

B: “What did you want me to do with this? What was it your ordered?”

H: “I don’t know, I just didn’t want to click on any random link in an email though.”

B: “Why did you send it to me then!?”

So what was created here is a web of trust. Boromir trusted that email because it came from someone they trusted to send benign content, Hugo. Hugo just wanted to get the email out of his inbox, and dealt with. Delegation.

Once it was inside the web of trust, the email was treated in the same way an email from any other person would have been. It and it’s attachments/links were trusted explicitly. Why would Hugo send something non-trustworthy anyway?

This is the most common way for attackers to attempt to breach an organisation. You can even buy phishing training for your employees. This is where you contract an external security consultant or organisation to attempt to phish your employees. You give the contractor a list of email addresses, and they try to make an email that they think will get clicked on. You can then see how many of your employees click on the link once they are sent out by the contractor, and customise the message that the employee will see once they click through to the “trusted” site.

One thing you will learn for sure is that phishing works.

I would hazard a guess that 90% of those big breaches that you always hear about in the news (Yahoo, LinkedIn, Adobe etc), likely occurred through phishing. It is the easiest, cheapest and least labour-intensive way into an organisation, because you will always be dealing with something that cannot be patched. Humans.

So we know that phishing works. Let’s try to reduce the effect it can have, and educate all the people that we work with around how best to deal with it when it does happen, because it is going to happen.

Also something else to note is that the communication on if this was a trustworthy email was sent in a side-channel, not the original method of communication.

The error-chain eventually looked like this.

  1. Hugo receives an email from YPS.
  2. Hugo forwards the email, with a message for Boromir.
  3. Boromir sees that he has a task from Hugo to deal with and trusts it implicitly.
  4. Boromir clicks on the link in the file, downloads the JavaScript, and runs it.
  5. Communication occurs between the two about the email and the file in a side-channel.

True to the error-chain description, if any of these events had been avoided, there would have been no incident.

  1. Hugo could have made sure the email was from a trustworthy source (It was possible to tell that it was not).
  2. Hugo could have checked if he was actually expecting a package through YPS, instead of assuming that it was legitimate.
  3. Boromir could have checked up on the details in the email. Verified that the sender was legitimate.
  4. Boromir could have checked the details in the email on the official YPS site, instead of trusting the link in the email. This would have revealed that the email was bogus. Boromir could also have run the JavaScript file through the Anti-Virus, to check if it was doing something suspicious.
  5. Communication about the task could have been kept inside the same medium of communication. An email with the text “I don’t remember ordering anything, do you? I don’t want to click on any links in an email!” will arouse far more suspicion that “FYI”.

So now that we know what happened to Hugo and Boromir, let’s look at the file itself, so we can see what happens inside a malware attack.

Boromir said that the file they clicked on made the screen flicker, and then nothing else happened. The link inside the email only downloaded the zip file, which I happen to have right here. Let’s dive in!

I initially sent the file from the zip that Boromir clicked on to myself. I zipped it up with a non-trivial password, and disguised it as a file called “this_is_malware.zip”. Once I downloaded it, and opened it in a vim terminal, I got the following.

Google removed the zip, and replaced it with just a text document telling me my malware had been removed! Well I guess I should be thankful that they are looking out for me. That is something at least.

I re-downloaded the .zip file, which I had stashed in a couple of other places, just in case of something like this.

So now we unzip and examine. It turns out that there is a javascript file inside. I renamed it “malware.js” Lets take a look at the first few hundred lines.

That is a LOT of variables. What could you even do with them? The names don’t seem to make much sense either. Let’s take a look further down the script and see if there is anything other than a mess of variables.

So here there are like a hundred functions. They are all named weird things too. The name “zoplyzu” does not mean anything to me. Don’t these malware authors know that you are supposed to name your functions well so that you know what they do!?

The top three hundred or so lines are just like this, weirdly named variables and weirdly named functions. At the very bottom there is something that seems to make fractionally more sense. Let’s take a look at it.

This at least looks like code. I mean in-so-much as there is an if statement, there is a new ActiveXObject (eek!), and right down at the bottom there is an evaluation (if flargleblargle == 200, do this stuff).

That 200 at the end there is probably the result of attempting to get something from the internet. 200 is the status code for “Everything went fine”. You may be more familiar with 404, which means that the thing you were looking for was not there. No-one really reports that everything is working fine, you just expect it to work.

This file is heavily obfuscated. The real code has been fed into another program, which chops up the real code, and replaces it with gibberish. This is entirely in order to confuse humans. If you run this file, it will de-obfuscate itself, and then do exactly what it would do if you ran the code pre-obfuscation.

How can we be sure of this being obfuscated? Well there are a couple of tell-tale signs. The best of which is probably in those gibberish functions we saw earlier on. Let’s take a closer look at one of them now.

The function is called nucbahf, but lets call it “FUNC_1”. It declares a junk variable (var dzoqgiz = “agebykwivq”) then declares another variable that is made up of other previous weirdly named variables, then declares another junk variable, then returns the sum of the weirdly named variables.

If you called this variable, it would just return a string to you. That string would be whatever you got if you added the four variables mentioned in that giant list together. The first and third variables are just there as fluff. When we look again at all the functions in the list, we can see that they all do exactly the same thing.

They all declare a first and third variable that are never used, nor mentioned anywhere else, and they all return a string comprised of variables mentioned in the super long list. Obviously we want to de-obfuscate this safely, which means not running it. Let’s make a python script to see if we can replace everything auto-magically.

 

This is what I came up with in the end. After running against the obfuscated file, I was greeted with one of the two states that any programmer will ever see.

It didn’t work! And not only that, it kind of did. But it also kind of did not. I have underlined in blue the bits above that actually replaced the parts they were supposed to. How frustrating!

Rather than spend an hour or so debugging the code, which would inevitably turn out to be a missing comma or something trivial somewhere, I decided to de-obfuscate it by hand. I went through the list of variables and replaced them one-by-one.

Much better! We can see that there is a fully formed URL in one of the functions, which I have censored. There is one that is just GET, probably for the GET request that will go to that URL. There are some other things in there too, GetSpecialFolder, whatever that is, and some backslashes.

Now that we have everything in all the functions, we can turn our attention to the code at the bottom of the page. There were a few functions in there (that we probably just de-obfuscated) that will put all the strings together and try to do something with. Let’s put it all together and see what we have.

Here we can see at point 1 the script is setting up some stuff, environmental variables, creating a new ActiveXObject. Then it tries to make a GET request to whatever resource is at the URL at point 2. If it is successful (that 200 status code we were talking about earlier), then it will save it to a file at point 3. Finally at point 4 it will run that file.

So let’s Curl that URL and find out what is hiding there! I saved the output to a file called simply ‘malware’.

Well it seems like it is some kind of executable, intended for Windows. I uploaded the file to Virus Total, which is a website designed to identify malicious files, such as this one. Virus Total will take the file you upload, and then run 56 different types of Anti-Virus against it. Everything from Malware Bytes to McAfee to Symantec. There are even some in there that I have never heard of.

Virus Total is a great site, and if you ever think that something is pretty shady, then you can upload it to Virus Total to scan it. Be forewarned though. They keep a copy of everything that they scan, so don’t upload sensitive company documents or anything like that. If you have those kicking around, odds are that you have a professional anti-virus system installed already. This is what Virus Total found.

Not only had 6 Anti-Virus programs flagged this as suspicious, but someone else had recently uploaded exactly the same file! This was a week ago, so the definitions of those Anti-Virus programs have been updated since. A lot more than 6 will now correctly flag this file as malicious.

I checked out the comments section to see if there was anything that could lead me to understand what the file was, but found only one single comment.

TorrentLocker is a variant of the Crypto Locker ransom ware. A user, such as Boromir, will click on a link or a JavaScript file, commonly known as a ‘dropper’. That more or less means it is meant to be dropped onto the computer one way or another, and then executed by the user. The dropper, when executed, then goes off and downloads the binary, which then runs on the computer.

Ransom ware has been in the news a lot recently, and works in the following manner. The program will encrypt the users files, send a unique key off to a command and control server somewhere, and then put up a payment notice to the user. They will demand a couple of bitcoins (something like $1500) and then upon payment, will de-crypt the files of the users.

TorrentLocker (and perhaps other variants, I don’t know) does not actually encrypt the whole file, just the first 1MB. Either way, the files are useless. It will also not work if it cannot contact the Command and Control server, which is either via TOR, or I2P.

So what can we do? How can we prevent this?

Well first of all, we can educate our users. I think that as people in information security, we have to consider the fact that we have a finite number of “No”‘s that we can use. Maybe as little as once or twice a year when it comes to how the business operates.

That may sound like far too few to those of you reading, but consider this. If every time people come to you to ask you if they can use this shiny new feature or product, you say “No”, then how often will they keep coming back to you? There is very little place for negative reinforcement in the work place.

People can and will go or work around you if they think you are hindering their ability to get their job done. A shadow IT industry will be created where everyone is just using cloud services for things that IT deemed too sensitive to be done in-shop or on-site.

So let’s avoid that. In the situation above, with the web of trust, no-one got fired. No-one was given a warning. In fact I took candy to one of the people involved. The candy made my visit not at all a pain in the ass, quite the opposite. It made a “visit from the security person” a completely painless situation. No hand-wringing and just friendly advice on how to avoid such situations in the future. Also there was candy.

Other remediation steps we can take, when it comes to the malware itself, are blocking binaries from running from the %APPDATA% and %TEMP% paths. The malware will attempt to save itself to these places, and then run itself. If you have a corporate network, likely you can set a group policy to effect this. Do it now.

The malware also communicates over Tor and I2P, so if you can block those on your firewall, then do so. It won’t run if it can’t communicate with the Command and Control server in order to give you the ransom ware note.

Also do not click on all email attachments, when you cannot implicitly guarantee where they originated from. Sometimes this will make your work life slower. Sometimes this will make your personal life slower.

So will unlocking doors. That is the way to think about this. This is just a cost of working with email these days. Just like the cost of living in society is that you have to have a lock on your door so that no-one comes into your house and makes off with your collection of antique Cabbage Patch Kids bubblegum cards. You have to lock that door every time you leave the house, and unlock it every time you get back in.

It is worth the investment in time, as otherwise you may have to pay either $1500, or risk losing all the files on your computer that you care about.

Also, make backups! There is an old joke about backups that goes “There are two types of people. Those that make backups, and those that have yet to lose everything in a catastrophic system crash.” Sadly restore points will not help either, as this type of ransom ware will silently delete all the restore points on your machine before it starts to encrypt things. Sneaky!

As for the actual malware file, well I ordered this book in the last 48 hours, so you can probably guess what the next blog post is going to be about.

I hope you all have a super kick-ass week!

Leave a Reply

Your email address will not be published. Required fields are marked *