In this week’s Monday Malware Analysis, we look at another piece of malware (Another Trojan) that was delivered to me via Phishing email. This one was once again delivered as a zip attachment under the guise of a payment receipt – Meaning I had to open up the attachment to open the receipt and figure out what was going on.

Lets play the fool and open up the attachment to see what will happen. As a note, this attachment analyses as Upatre or a generic trojan, depending on who you ask (VirusTotal Link).

I have a feeling it will follow a similar process to the last Trojan we looked at.

Disclaimer: This is all carried out in a controlled, isolated environment. Do not try this at home. Seriously. I will not be held responsible if you infect yourself, chances are all sorts of nasty things will happen (E.G. the theft of your online banking details).

As before, this is a Windows 7 Virtual Machine running in a DMZ isolated from the rest of the network, but still with a (firewalled) internet connection. Snort IDS is running on the DMZ interface as well as a packet tracer. No Antivirus is running on the system.

So lets extract the zip and open whatever lies in wait…

This one shows up disguised as an Adobe PDF icon, by displaying the icon you would expect to find on a PDF. Windows identifies the file type as a screen saver (.scr), which is somewhat suspicious:

What happens when we open this “PDF”?

As soon as we run it the file disappears and we make some HTTP requests to download a RAR file. Shortly afterwards we see a windows firewall prompt asking to allow access the internet.

As expected, we create some outbound connections (via UDP). We also make some connections to google, which oddly enough just make a request to google and nothing else. This could simply be checking for connectivity (Who doesn’t visit google to test your Internet connection?)

Apart from making a few requests to google, at this stage it doesn’t appear to be doing much, just sitting idle. Lets take a further look at what is happening on the system. As common with these types of Trojans, the dropper installs some stuff in the users %APPDATA% folder, then, the malware installs itself as a service set to start on boot-time:

It also seemingly installs a bunch of data on the registry. This is interesting, so we’ll check that out later.

Taking a look at the process that has installed itself and is now running, unfortunately most of the strings are encrypted. (I also took a very quick look in a debugger, and the code area is encrypted, which will make disassembling the file difficult, and is fairly common in malware… plus I never learned to read Assembly). However, we can at least see from the in-memory strings that the executable has HTTP and SVN capabilities:

Although we already knew about the HTTP stuff – but the SVN is unusual. I will need to look into this when I try to delve further into the executables.

Now comes the interesting part – Whilst delving into the URI’s and IP addresses that the Trojan dropper reaches out to upon initial execution I found something interesting. Normally, the majority of systems that a malware will grab a payload from are either compromised servers, other zombies in a botnet or operator controller systems (Hidden behind layers of obfuscation).

It seems that this particular malware is making use of unsuspecting home routers.

Casually portscanning one of the addresses peaked my interest, especially amongst the recent talks of the Internet of Things being the next large target:

That’s right, this appears to be someones home router – a “2Wire 2700HG-B wireless ADSL modem” (According to the nmap aggressive OS scan)… one of these babies:

Now unfortunately for this person (UK based, attached to the service provider BT, in case anyone is interested) their router is exposing a HTTPS web interface to the public internet (The customer probably isn’t aware). Upon further poking, this appears to be a management interface for the ISP to push configuration updates to the modem… A CPE-WAN type interface, a variant of TR0-069 I would imagine.

I wasn’t able to access the interface, but to be honest I only tried a few well-known default passwords.

Moving on to the other addresses we contacted, one is registered to South Korea (On the “Korean Education Network”). Unfortunately I was unable to reliably determine the type of device this was running.

The other, however was also running a common home router system. In this case it was running DD-WRT, located in the US on AT&T:

This particular device is exposing a HTTPS interface to the public Internet. On attempting to access the page, I was greeted with a blank HTML document. It’s entirely possible that this interface was actually created by whatever exploit was carried out on the device.

Both devices I was able to analyse are hosting binary files which at first glance appears to be perhaps a configuration package for the malware that I executed on the test machine.

The CPE-WAN exploit is interesting, and one I shall look into further. Whether this was the attack vector, or simply a means of hosting out files remains to be seen.

This is going to be an exponentially increasing problem I foresee as the security in mainstream operating systems comes up to scratch. We are going to see all sorts of poorly-protected home routers, internet-connected fridges and even internet-connected underwear be exploited due to their reliance on “Security through obscurity”.

Given the wide user base of these types of systems, much of which consists of non-technical people, vendors really need to play some part in ensuring at least a basic level of security. When it comes to devices connected to the public Internet, security should be implemented at the core of the system right from the start – not as an afterthought.

As a closing note – the fact that the malware on the virtual machine isn’t doing anything is not boring, quite the contrary I find it extremely interesting and will need to performa deeper analysis over the next few weeks to discover it’s true purpose…