Fixes

I fixed the implant, added a flake for my nixOS config.

Defense evasion

So, I kinda wanna avoid defenses in a proper way… So I start making encrypted creds.

Phew, We came quite a long way this time. So I wrote the implant program in C, and added a DNS query thing (Thanks Silver Moon). I optimized for filesize. I later on daemonized and obfuscated the location of the program in the process tree, basically meaning that the process name will be something in the style of “kworker” which is an internal kernel worker, or “sh”, which is a commonly used scripting shell. I also made sure that no signals terminate the program.

Then I added querying on startup with a unique compile-time UUID that was sent along with the hostname of the machine when starting up.

Changelog

• Compile-time UUIDs, query c2 on startup
• Daemon and hiding
• DNS
• Makefile dev profile with debugging
• make

Now I tried if writing the implant application would be viable in C or C++, due to the difficulties in nostd rust with udp sockets

Now I created a table for the DNS records in the database, created a configuration file, merged everything. I made a script that automatically runs cargo fmt.

Redo, again.

So previously I used the dns-server crate for DNS server, due to it’s simplicity (and efficiency). But sadly, it couldn’t meet my requirements, and wasn’t reliable enough to be approved by me. This was a mistake from me because I didn’t do much research. So I migrated to hickory-proto and a normal UDP socket. This might change in the future, because hickory-proto for some reason added around 300KB of libraries that I frankly, don’t need for some parsing. Either way, I also removed the prototype DNS client from the implant, as I deemed it to be unethical and potentially insecure to have code that you don’t understand in your codebase, so I’ll rewrite that in the near future.

Other than that, I added a database and encryption keypair. This will be used later, but at the moment is kinda useless.
Summary:

• Rewrite DNS logic for server (again)
• Work on the implant
• Add encryption and database logic

Full remake, start

Hello. I thought, why are C2 data usually transmitted over DNS? Turns out, detection and response systems usually doesn’t have as strict filtering rules for that. You can also in a way “proxy” the information, or more technical, the recursive DNS resolver resolves to your nameserver and returns any potential information.

So, this time, I completely scrapped my previous attempt on the server (though the client might be reused) and started writing it for DNS instead. This time, I’ve also started writing the client/victim payload.

All programs are currently written in rust for security, but the client is in unsafe rust.

See https://github.com/a-rvid/tuxmux/tree/dns branch.

The plan is to use encryption to hide the data between clients and analysts.

Optimization, commands

Temporarily disabled client connection (you’ll be able to listen with :l command and connect to BIND with :b later). I optimized the Cargo.toml file for binary filesize. I added a notification and MOTD system (with MOTD being the “welcome message” displayed).

So I had this idea one day that I would write a terminal multiplexer, such as tmux, because I’m too bad at using tmux (meaning I’m too lazy to change the bindings). So I started on a base, see these commits:

• pty start implementation
• base
  They were fine and all. But you always want something more, so instead of writing a terminal multiplexer, I started on a reverse/bind shell handler, you could call it a C2 server. Today I created a server which listens for incoming connections at a specified port and connects to bind shells. A client using ratatui, and connect it all up with a UNIX socket.