SamSam is a ransomware that is written in C#. It’s not an interesting malware, it hasn’t new interesting features or tricks to comment, however I wanted to write a post about the tools that I use to analyze .Net malware since long time ago, and this was a good opportunity to do it.
Lately, while reviewing and classifying samples, I have been seeing an increase in CoinMiners, specially CoinMiners oriented to mine Monero virtual coin. For this reason I decided to write a short article about virtual coin mining and this kind of malware.
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.