Since a time ago, they are beginning to appear a new wave of malware targeting Automated Teller Machines (ATM): Backdoor.MSIL.Tyupkin, Backdoor.Padpin, the newer GreenDispenser, etc… All of them seem to be using the eXtensions for Financial Services (XFS) library to manage ATM. If you try to debug/analyze or you introduce a sample of these malware families into a Cuckoo sandbox, it won’t run because it will fail to load msxfs.dll.
The problem is that XFS seems to be a private library. Simulators and debug environments are private software, and expensive to buy. I have been not able to find a open source solution. For this reason i decided to implement a fake msxfs.dll. It will have the same exports than the original one. There isn’t enough documentation and it’s hard to create a perfect simulator dll, I tried to simulate the most typical commands that these malware families are using, for example for returning random digits from the pinpad when the trojan tries to recover them.
In my previous post i described a vulnerability that would let configure DNS in multiple models of Comtrend routers by clicking an url like this:
I am pretty sure that many models of Comtrend and other manufacturers suffer vulnerabilities of this type. In this post i am going to describe how to attack a router Linksys WAG120N in a similar way.
It is well known by all the poor security of SOHO routers distributed by ISPs. Vulnerabilities, default passwords,… These routers expose inexperienced users to be hacked.
I want to share here a method which I have been playing that would let us to configure some router models when a user clicks a link created by us. I have not read about this method on the internet, sorry if I am wrong and it’s not new. The method is quite simple. It is usual to find routers with default passwords. And these devices usually offers a HTTP based interface to configure them. And some models accept configuration parameters through the URL.
BusyBox, called the swiss army knife of embbeded linux, is a software application that combines tiny versions of common unix utilities into a single small executable, as we can read in the busyBox project page. It is widely used in embedded devices, specially in modem/routers, thought it is used too in other type of devices like music systems, ebooks (i.e. kindle), phones, etc…
BusyBox is single binary. It is implemented having in mind size-optimizations and limited resources environments. It implements a lot of common unix commands. To use each command, you should call BusyBox giving the command as parameter, i.e.: /bin/busybox ls. Usually, commands that are implemented by busybox have fewer options than the original full-featured command. BusyBox uses ash shell (/bin/busybox sh).
As we said, a lot of router devices are using BusyBox. It is quite probably that a router shows to you a limited command line interface to manage it, for example when you connect via telnet. However, these limited shells use BusyBox for executing some of the commands that they offer, and it is common to find devices that are vulnerable to command injection attacks that would let us to use directly the busybox ash shell.
In this article I am going to describe a way to execute code in windows kernel by using windbg local kernel debugging. It’s not a vulnerability, I am going to use only windbg’s legal functionality, and I am going to use only a batch file (not powershell, or vbs, an old style batch only) and some Microsoft’s signed executables (some of them that are already in the system and windbg, that we will be dumped from the batch file).
With this method it is not necessary to launch executables at user mode (only Microsoft signed executables) or load signed drivers. PatchGuard and other protections don’t stop us. We put our code directly into kernel memory space and we hook some point to get a thread executing it. As we will demonstrate, a malware consisting of a simple batch file would be able to jump to kernel, enabling local kernel debugging and using windbg to get its code being executed in kernel.
The article has five parts:
- Dumping files embedded into the batch file: a couple of methods for embedding and dumping binary files into the batch file.
- Executing the batch file as administrator: here a method to show the UAC prompt from the batch file (without using powershell, vbs…)
- Enabling local kernel debugging: how to enable local kernel debugging from the batch.
- Patch kernel memory with windbg to inject and execute our code in kernel mode: a way to patch kernel memory and execute our code in kernel by using windbg local kernel debugging from the batch file).
- Finally, we will put all these things together to make a proof-of-concept batch file that will target a windows 8.1 x64 machine, and we will do some tests.
There are lot of ransomware families around the world, however, since long time ago, they contain no new interesting features. VirRnsm.A is a malware that mixes characteristics of ransomwares and infectors. It is a ransomware capable to infect executable files (or an infector capable to encrypt your files). Technically, It doesn’t seem a great malware, but it is worth a look because, from my point of view, in the future we are going to start to see a lot of malwares of this type. Ransomware’s behaviour could end up being a payload of worms and infectors, rather than a malware by itself.
In spite of the fact that VirRnsm.A is an evolution in the ransoms world, probably, it would have spread itself faster if the malware, after infecting files, didn’t block the screen, showing a rescue message and revealing itself. Instead, imagine a worm or infector (a conficker, a sality,…), that arrives to a machine and hides itself with stealth techniques, trying to spread itself as much as possible, and waiting for a date to execute its payload (payload with ransomware behaviour). It could be a enormous chaos.
It’s common to reverse malware (or any type of software) that creates multiple processes or loads drivers, and it is useful to be able to debug the new created processes or loaded drivers from entry point.
To break at the entry point of the processes you can modify CreateProcess parameters to create child processes suspended (to attach debugger later), or introduce 0xCC at entrypoint on disk of the PE file that is going to be launched, or use plugins for debuggers to attach to child processes… There are lot of methods. From kernel mode you can set conditions that break into the debugger: sxe ld ntdll.dll, sxe cpr, etc… For breaking at a driver entry point you can use: bu <drivername>!DriverEntry (though, i don’t know why, sometimes it doesn’t work for me).
I will talk here about a couple of ways to do this from windbg kernel mode debugger, without needing to restart computer to enable exceptions that break into debugger, or modifying PEs in disk,…