grm

Slowly and painfully, but we’re getting somewhere! I’ve started implementing the backend. Couldn’t hold myself back anymore, the UI can wait x3 I chose the Actix + SeaORM + JWT middleware way of doing this, because I’ve never used Actix or SeaORM before, and have heard good things about them from my friends! I have to agree that it’s an amazing stack: everything’s structured, modularized, but still monolithic in nature (microservices are eww). I am also having a blast learning all the cool Rust-native mechanisms that these offer.

The unusual concept of this app (it’s ephemeral nature, no passwords, etc.) is starting to pose a real challenge, and so many problems are beginning to arise QwQ But I know I will get through no matter what!! Even if I don’t do them the best way, it’ll be an invaluable learning experience!!! hopefully x3

Currently implemented a basic user module and authentication scaffolding. At the moment I’m in the process of laying out documentation that will (hopefully…) help me conceptualize roles and permissions, because they’ve become quite a mess… (there’s still a placeholder Clown role 😭). So yeah, goals for the near future: brainstorm the correct auth roles, add a way to add “label roles” (the ones you see, but which don’t really do anything else x3), figure out a way to auth without spoofing other users (I’ve been thinking about a challenge-response kind of thing, like the YubiKey, but I’ll cross that bridge when I get there x3). That’s a lot, but hopefully these will be done soon-ish™

Also there are some tests!!! (they’re already outdated and failing because of the jwt auth and role thingy 🥀)

Added new gathering module!! In MITRE it’s mapped as credential gathering, but here I wanted it to be a bit broader. Gathering system information is more of a reconnaissance thing, but I wanted it all in one place, so there’s that…

I’ve also began (more of a PoC than anything else right now, but I hope it’ll be fully functional by the next release!) implementing the scenario mode. It will let you simulate threat actors (or just generic killchains, like the ransomware and espionage ones implemented currently), which in turn will help you improve the security of your systems!! I want it to be as easy to use as possible, which is challenging, because I also want it to be parametrizable… It’s still work in progress, okay? x3 (that also means they’re not tested, so, uhhh, they may not work fully as intended yet…)

Another news is that the code now compiles with all combinations of flags (don’t ask if it didn’t before, won’t say…). The CMake tests are now adjusted to the new SCENARIO_MODE flags, and I fixed all the silly little accidents so that everything builds and compiles correctly. Yippee! They take so long to compile and run tho @w@

Long time no see, huh? x3 Waiting for the ship to get approved was a true test of patience, but the lovely shipwrights got to it and left some nice feedback :3 I had to create and roll out an unexpected full binary release (I kind of hoped it could be docker-only, but turns out it couldn’t…), and that took way longer than expected. Did you know how difficult statically linking basic binaries is in C++? That, or I am just special…

Near future will be spent on improving GHOST. Both SHADOW and CHARON now support the core functionality needed to make GHOSTs useful, so now I’ll make the GHOSTs useful! I plan on adding an impact severity level configuration (probably through CMake flags again, will see x3) and basic XOR string obfuscation to see if the file gets flagged by Defender again. If not, we may see a Windows implant in v2!! I wouldn’t be too hopeful about that tho…

Refactoring is going better than anticipated, but with the pains expected. File and project structure has been refactored in a way that makes this extendable and parametrizable, which is exactly what I want. There are still places that can be improved (for example creating an interface for encryption methods to be passed as reference to the impact function and potentially chosen compile-time), but I’m happy with how this is turning out overall.

Some adjustments here are also core design improvements, which means breaking changes for SHADOW (and potentially CHARON). I’ll fix and test those after I’m done with the GHOST’s refactoring, which will be when all functionality is moved from the old version. Then it’ll get merged into main and be a base for all future features.

Main focus of this stint was getting GHOST to an operational state. I’ve succeeded (mostly). It now communicates with SHADOW (but CHARON doesn’t get the output of commands - something to debug in the near future). Other than that I’ve started setting up some basic persistence functionality in a way that will be extendable and easily maintainable. I’ve also cleaned up console output so that it:

1. Is uniform throughout the whole GHOST module (more of a pet-peeve than anything else, but it’ll certainly look a lot more polished :3)
2. Easy to disable for production app. This is fully done in a way that keeps output for DEBUG build and disables it for other modes (production build is the only other one for now)

This overall required a lot of careful planning and made me reconsider some basic assumptions for the project, but it seeing the end result of this tedious refactoring made it all worth it.

I knew this day would come, and that this would be inevitable, but seeing it happen is frustrating nonetheless…

I’ve always anticipated that GHOST would eventually cause issues on Windows. Its whole job is basically simulating an infection, and with how sensitive modern AV/EDR solutions are, it was a matter of time until behavioral protections got in the way. Even though nothing here is actually malicious, Windows very much disagrees!!

From what I can tell, the main culprit is GHOST’s use of low-level networking (the winsock2.h and ws2tcpip.h sockets). This paired with some very upfront variable naming can be enough to trip hooks and land the implant in AV jail. Fixing this properly would require heavy code obfuscation, aggressive packing and bypassing user-mode EDR hooks (it’s an insanely interesting topic btw, but very very difficult at the same time). It’s not hard to notice that this is WAY out of the initial scope. I needed GHOSTs to help me reliably test AETHER, not to be state-of-the-art malware simulators.

So… pivot time!! From now on, GHOST will be linux-only. Dropping multi-platform means more advanced functionality!! New goals are outlined in README, but tl;dr: persistence, beaconing, command execution and exfiltration will now be present by-default. I also want CHARON to be able to generate configured and parametrized GHOSTs. Example use case would be generating a GHOST that doesn’t establish persistence and only dumps data to SHADOW, without all other fancy things it could do. I think this will be invaluable to red teams, since it’ll help them focus on test scope more clearly.

This also means: A LOT of refactoring. Like, a lot a lot… I’m looking very much forward to it tho, we’ll see how it pans out x3

Another big milestone has been achieved! I’ve successfully implemented an MVP version of CHARON. There arose a problem tho…. I can’t fully test it without having some implants handy. And the current ones don’t run on Windows without triggering AV. It shouldn’t happen, because they’re not malicious, but it’s still something I have to combat. Until I figure out how to get GHOSTs to a stable, test-ready state, I’m considering CHARON done for the moment.

A huge milestone has been accomplished. A basic version of the GHOST implant has been created and successfully connected to the SHADOW server!!! It’s a very work-in-progress type of achievement, but it’s huge progress already. I hope to lay out the GHOST <-> SHADOW interface next to help me structure the API correctly. Another milestone will be the ability to execute commands remotely on the system where SHADOW resides.

Most of current work was focused on creating a very basic baseline for the CHARON component. My main project got a “definition of done” section in the README, which clarifies what exactly needs to be done in order to ship this project. It will probably morph one way or another, but having anything there helps me focus on what matters in this project.

The main goals of this first stint were simple:

• Create a broad vision of what I want to achieve with this project
• Lay out the architectural components necessary to embody that vision
• Go through each component and make the responsibilities of each component more specific
• Setup the main git repository alongside component repositories (still requires some work to have a CI/CD process to update the main repo when any of subcomponents gets an update)
• Write some simple boilerplate code, currently for the SHADOW component (I think the server will be the most important part for now, GHOST will require a lot of tinkering, and CHARON is a bit useless without the functional part, as it’s only a TUI)