Origins

The idea came from one bored day at work when I was working at an arcade and had 0 customers. At which point, I’d already completed all my tasks for the day; no repairs, no customers, no restocking– nada. So I pulled out my notebook from my bag and after giving my coworker an elongated spiel about the infinite monkey theorem, I came up with the idea for trying to create a bruteforce generator using the infinite monkey theorem.

Of course, using a random generation for each password was going to be super inefficient, but I was curious to see if I was able to make it– and sure enough with the help of some early AI tools I was able to make it.

only small parts of the project used AI generated code. At the time I was comfortable with AI tooling. Nowadays I reject it all together for the sake of our planet’s survival, and for political and moral implications.

The project was originally written in C, but as time went on; I kind of abandoned the old project. I was relatively new to writing C, so a lot of the code used was rather redundant, buggy or outright just bad. The code base could have been so much more efficiently written, but that was on me.

So after a while, the project was abanoned– until the next year.

Revival

At the time I wanted to give other languages a try. I wasn’t a large fan of the way that C’s functional programming style was and writing a project in a language without modern features can be a bit of a pain in the ass, especially as a solo-dev. The thing was was that I didn’t want to abandon the speed of C, and more importantly; I wanted to be able to add more features fast and easily.

I gave it some thought, and I decided that my best course of action forward was to write it in Rust due to its Zero-Cost Abstractions. I’ve experimented a little in Rust, but unlike how I started with Genpass, I didn’t want to use AI for generating any code. Instead, I opted for reading documentation and learning features from the official Rust Book and using my project to solidify the fundamentals.

This project I learned about how Cargo worked and it was an absolute life-saver when it came to finding crates that would help speed up the development process. Of course, it didn’t come without some trial and error, but I eventually got things to work out.

Implementing Features

For a period of time, I had liked a lot of features that KeePassXC had in their tool, so I decided to copy some over into genpass-rs. I mostly liked the estimation of password strength that they had using zxcvbn, and the password management feature which made things pretty easy to find. However, I wanted to make something different– I wanted to not just make a regular old password tool; you can just use KeePassXC for that. I wanted to make something more fun, but still useful, which is when I implemented the steganography module for the tool. Luckily, there already was a library written that I could use to implement that feature.

What was missing was that added layer of protection before hand before inserting the bytes into the images, so for a period of time I used another crate to implement that cryptography feature before just handwriting that one feature instead of loading all of that project’s depenedencies.

Now, the project was practically complete, but to this very day I still come up with new ideas for it.

What I learned

From this project, I gained a lot of insight into how Rust works as a language, and numerous security concepts regarding safe password generation. For Rust, I learned about how the language works:

• How it differs from other OOP languages when it comes to polymorphic behavior.
• The language’s strengths and weaknesses.
• How it handles strings and character types.
• Most importantly how to efficiently use references and memory.
• How to write better and cleaner Rust for maintainability.

These became heavily influential in other projects, but more than that what drives me to continue improving the project all together.

In regards to my security journey, development on this project taught me:

• How CSPRNGs differ from normal Random Number Generation.
• How bit entropy works for measuring password strength.
• How to measure password strength with different algorithms (and why zxcvbn is the industry standard)
• Symmetric encryption.

About

I already have a super-extensive readme that you can go checkout here. You can also watch my youtube video about it: here.

Happy Time

Such a strange name isn’t it? I think that’s what makes it so eye-catching. happytime is a malware evasion proof of concept based on old leaked CIA documents from 2016 under the code name Hive. It originally was designed to be used as a part of their infrastructure to delete the reverse shells and tools off of their C2 clients. It never made it to the final implementation because of issues with system clock configurations.

How it Works

Essentially, the program starts a thread inside of this main function here:

fn main() -> Result<(), Box<dyn Error>> {
    /* Main Function */
    eprintln!("Started self-deleting malware testing.");
    let mut bin_path: path::PathBuf = match get_malware_path() {
        Ok(v) => v,
        Err(e) => {
            eprintln!("can't get path to binary: {e}");
            PathBuf::from("")
        }
    };

    let pid = process::id();

    // thread for process daemonization
    let handle = thread::spawn(move || {
        dbg!(&bin_path, pid);

        let mut counter: u64 = 0;
        loop {
            bin_path = get_malware_path().expect("something went wrong within the thread");
            if timer(counter, SECONDS_BEFORE_DELETION) {
                match delete(&bin_path) {
                    Ok(()) => (),
                    Err(e) => eprintln!("{e}"),
                }
                break;
            }
            // sleep 1 second.
            thread::sleep(time::Duration::from_secs(1));
            counter += 1;
        }
    });
    match handle.join() {
        Ok(()) => (),
        Err(_e) => {
            process::exit(1);
        }
    };
    Ok(())
}

Essentially what it’s doing is finding the process path to the executable inside of a symlink in the /proc directory and continuously tracking the binary’s location. After a set period of time, the process will then delete the binary at the path. Below is the source code overlining this process:

fn get_malware_path() -> Result<path::PathBuf, Box<dyn Error>> {
    /*In Linux, we can get the path of a binary
     * from /proc/PID/exe, which is a symlink to
     * the binary.
     *
     * This will be the path that the software to use to delete the binary.
     * */
    let pid = process::id();
    let formatted = format!("/proc/{pid}/exe");

    let path = fs::read_link(path::PathBuf::from(formatted))?;
    match fs::exists(&path) {
        Ok(_v) => eprintln!("binary found @ {}", &path.to_string_lossy()),
        Err(_e) => {
            eprintln!("failed to get legitimate binary path.");
            let _ = get_malware_path();
        }
    }
    Ok(path)
}
fn delete(abs_path: &PathBuf) -> Result<(), Box<dyn Error>> {
    /*Deletes the path of the binary*/
    eprintln!("Deleting {BIN_NAME} @ path={:?}", abs_path);
    fs::remove_file(abs_path)?;
    Ok(())
}

Note: On failure, get_malware_path() will make a recursive call to retry and obtain that binary path.

Applicable use

While the proof of concept’s live branch lacks any malicious code at the moment, it’s use as a part of a larger malicious ecosystem would make it invaluable to hiding any semblance of a trace inside of a target’s machine. In addition, the modularity of the project allows it to implement different forms of deletion conditions, or even allowing different levels of deletion such as overwriting the path with garbage information before deletion.

The reason that this works as effectively as it does is because of the nature of how executables work on linux, which I will briefly explain here:

1. When an executable runs on a machine, the process will remain in memory until the process completes.
2. Linux follows the UNIX philosophy; treating everything as a file. This means that we can essentially get all the information that we need about the executable from a file somewhere on the system, in this case the symlink /proc/{pid}/exe contains all of the information required for this POC to be viable.
3. Rust compiles all of the dependencies into the binary. Allowing us to build for what we need.

In theory, this only allows us to use it on Unix-like machines; however since I haven’t tested it on any other Unix-like operating systems, I can’t provide details into it’s effectiveness or reliability.

Defending its publicity.

You might ask yourself:

• “Why make this public? Couldn’t a bad actor get their hands on this and use it for their own malicious purpose?”

The answer is simply yes; but that can go for literally anything. The idea behind technology is that it is morally neutral and for general research purposes it is better that this is public and not hidden. Let’s face it, if a bad actor can already write malware; they can more than certainly implement other ways to obscure their tracks for researchers. My proof of concept keeps the code readable so that other researchers can look at how this works at a high level.

In addition; the live branch is planned to only contain minimal source code to execute a reverse shell, search for potential exploits on the system, and do nothing more and nothing less.

I am someone who fiercely believes in the freedom of information, and someone else’s unethical behavior is not my responsibility, nor my jurisdiction.

Credits

S/O to the people at Langley for their work. Not a huge fan of everything you do, but your work is always impressive.