Introducing...Malachite! (guest staring Obsidian)
Ok, I'll admit it's rather difficult to both find the time to - as well as remember to - actually keep up a blog. But I think I came up with an idea interesting and complex enough to warrant a decent bulk of posts over the coming weeks. That said, don't >expect< too much...
So, what the hell am I talking about?
I guess you could sum it up as a ninja distributed computing platform. It's designed to be installed and run without the user ever knowing of its existence. I say "user" and not "victim" because the idea is that anyone can think of at least a few people that barely actually use their computers, yet have modern hardware. Some have massive computational power yet use practically none of it. Why not harness it?
At this point I should mention a disclaimer. This is, of course, purely educational. I just want to see if I can actually build this beast. It's an exercise in a less destructive type of intrusion with potentially no impact (if done correctly) to the user, as well as an exercise in writing a platform spread out across multiple languages and OS environments. Like running a normal distributed computing client, if it's written and managed properly it won't interfere with anything and thus be very transparent. So I don't plan on releasing this. But it's not hard to write by a long shot. If I can do it, someone else certainly has, and probably much better as well. Their hat is potentially far darker than mine. My example usage cases usually involve some sort of public system, such as a computer in a library or cafe that sits there unused half the time anyways, if that makes you feel any better.
I would like to specifically state that I haven't even considered "botnets" or "DDoSing" though. I'm not interested in such petty toys that only break everybody's shit and cause general unrest :). If you're really interested in security or distributed computing you should at the very least make sure you don't disturb anyone and learn something or do something productive/helpful </lecture>. With that out of the way, it's my pleasure to introduce you to...
Uploads client binary to system temp directory
Starts client and feeds it init data blob fetched from server
Renames client to look like a temp file
Hides client from task manager by running it under the SYSTEM or NETWORK SERVICE account (assuming possible)
Authenticates with server:port using a GUID, all supplied via STDIN (no command-line parameter or network traffic for evidence)
Fetches new work units from server and dispatches payload to process them
Sends payload results back to server for processing
All client<->server comms obfuscated in dynamic HTML pages (sent over HTTP to blend in)
Measures/calculates host metrics (CPU usage, CPU heavy processes, etc) for server to optimize client
Handles payload and work unit distribution
Can manage multiple payloads and collections of work units for each
Assigns resource hungry payloads to faster hosts (based on client metrics)
Manages authenticated client pool
Communicates with clients on random ports (clients must figure out which from a list)
Planned port-knocking feature using UPnP (only needed behind NAT) to open random client comm port based on pork knocking sequence
HTML Obfucation library planned to support additional protocols such as FTP
Encrypts large data blocks (files, work units, etc) for transmission using AES, SHA256, or RIPEMD160 (configurable per host, expanded/salted GUID key is unique to each host)
This is all still heavily under development and changes hourly so nothing is concrete. I think I've got a pretty good framework so far though. But I tend to add a new planned feature roughly every hour, so I'm excited to see what it turns into. I'll be expanding on each component in coming posts (and as they solidify a bit more). Also, the obfuscation library is most likely going to be its own external project, and I very much intend to release it since if I can make it even 1/10th of what I imagine it to be, it'll be well worth it. So if this sounds remotely interesting, then look forward to (hopefully) more details as I flesh out the rest of the framework and start implementing features.
One thing I should address quickly is that this IS designed to be silently planted via a Meterpreter session (using Metasploit). If you're not familiar with these names, what that means is that you have to find some type of exploit on the host, or use some sort of phishing or other social engineering attack (I don't suggest this at all) in order to actually drop the client. You have to pwn them. If you know the internal protocols really well, technically you could run the client binary without Meterpreter at all. I may fork the client for this purpose eventually.
If you look over the list of Malachite features carefully you'll notice that there's no persistence. I didn't mention it, but the client actually removes all traces of itself upon exit (triggered on shutdown/reboot/logout). Once the program exits, it's gone forever unless manually planted again. This is by design. It's not designed to dig in and never leave, I don't want it to be bothersome. If you were to one day discover it running (somehow), a simple logout or reboot will erase all traces of its existence. I guess I could change my mind one day, but I've got a long way to go before I'd want to write something with the potential to dig in so deep it's there for the lifetime of the device. That's a lot to be potentially responsible for.
I'd also like to throw in a plug for a project I started a few weeks back that I'd very much like to continue when I have more time to work with. It's called Obsidian (yes, I love rocks, obvious?), and it's another entry into the "control your computer from anywhere" market. But it's a little different in that it's designed to allow absolute complete control, from filesystem commands to tunneled router interface access (so you can turn off the remote admin). It has a configurable screen-capture feature with a web interface to monitor the desktop/running programs that can change the focused window. Multi-screen support of course. It's planned to eventually have some simple OCR to read values from program interfaces and allow plugins that can interact with GUI programs. You can designate a folder to drop executables to have them autorun (this will be hard to secure). I have a huge whiteboard with all my ideas for features, believe me there are plenty of interesting ones. I'll try to dedicate a post to it eventually. But one of the most important points (to me at least) is that I will attempt to secure it as best as possible. End-to-end encryption, none of this plaintext bullshit, obfuscation wherever it may help without noticeable overhead, etc. There is NO excuse to write shitty, vulnerable, insecure code.
Note: I realized technically I lied about something. The client doesn't need persistence, because it's dropped and authenticated with the server almost entirely through a Meterpreter session, which can very easily be made persistent with almost no effort. But you get the idea. The platform itself is designed to be organic and melt away once it's had its chance to borrow some CPU cycles. This isn't a big, heavy weapon. It's a small, efficient solar panel, ok?
So, remember kids: keep a leash on your monsters, or one day they'll come back and destroy everything you've worked to build ;)
