Last one before the v1.1 release and ship!

Past few hours were spent on making sure that everything works as intended. This included fixing weird bugs (like broken GATHER and EXFIL modules in GHOST, wonky UI madness in CHARON, among others x3), perfecting the deploys (Docker ones included!) and keeping the documentation up to date :3 (with fresh UI screenshots UwU).

A big one! This update adds the Scenario Mode to AETHER! It lets you run simulations using predefined threat-actor (or generic threat) profiles. Setting this up took quite a bit, but adding specific scenarios was so much funnn x3

Currently implemented scenarios are as follows (per docs):

• RANSOMWARE - Very noisy. Exfiltrates data and encrypts files.
• ESPIONAGE - Low noise. Gathers host info (sensitive data included!) and exfiltrates it over the C2 channel. Good starting point for simulating infostealer malware or APT actors :3
• WIPER - Extreme noise. Destroys all files and self-terminates, leaving the system in an unusable state. Used to test EDR detection and reaction speed.
• INFOSTEALER - Steals the info >:3c
• APT - Stealhy and hands-on-keyboard’y… Also - very generic
• APT29 - Long-term espionage. Gathers SSH keys, stablishes RunControl persistence and deploys an undetectable 4-hour beacon interval.
• APT44 (SANDWORM) - Pure chaos. Establishes a CRON job to survive reboots and immediately wipes the system. Nothing will survive.
• APT38 (LAZARUS) - Two stage extortion. Silent harvesting of system data and SSH keys only to drop a screaming ransomware to mask the espionage.

On top of that I’ve implemented some structural and functional changes. CHARON can now set impact levels and generate payloads using specific scenarios!! I’ve fixed some exfiltration functionality and unified the naming. Lots of small changes that will make my life a lot easier x3 (and make the system more usable!)

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 🥀)

I can’t wait until this is finished, how do you frontend bros even do this 😭

Added the staff dashboard. It’s obviously not done yet, but it gives you a basic idea of the functionality it’ll provide. This took so much time, but hopefully it’s a solid enough foundation that the future backend integration is relatively easy…

I’ve also noticed that a basic design guide would be a great thing to have now. I do have an idea of how I want this to look (even some figma designs!!), but putting this into the code is a whole another story. I’ll think about how I want to go about this later… x3

The last tab I’ll do (for now) is socials. Then, if everything goes right (it won’t), I’ll start making it actually work like a website! Yippee!! Rust my beloved please save my sanity

Small, but insanely important log!!

1. Fixed Docker Compose build times (kind of, just moved tests out to a separate stage)! They should build a bit faster now :3 (thanks to the shipwright reviewing my ship for pointing this out!!)
2. Created a build script for new releases. No more manual labor!! yippiee :3
3. Currently catching up on some newest malware campaigns to know what to add to the scenario mode =w=

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…

Looking absolutely horrendous. The beginnings are usually rought, but man… Progress on this is also painfully slow, as I haven’t touched any frontend code in months. Vue is amazing, but still, ughh…

Hopefully next devlog has some actual designs in it x3

Preparations for the final release are coming to an end. Next devlog will be v1.0 (or ship, don’t really know how those work yet). Only final touches left, tagging v1 on GitHub, and… that’s it I think.

The biggest change this time was finally creating a complete, out of the box sandbox to let all of You try it out :3 It spawns as many GHOSTs as you want, and let’s you play with them like you would in a real red-team exercise!! I can’t wait to get more peeps to try this out and give their thoughts on it aaaaa

I’ve also tried to fix CHARON’s Docker terminal quirks. Basically, any time you quit CHARON after attaching yourself to the container, your native terminal won’t clear, and you’ll be stuck with CHARON’s last view (and possibly no cursor for the rest of the session - ask me how I know…), which is suboptimal. I’ve tried quite a few things to fix it, but to no avail. I’m giving up for now, maybe when someone else takes a look they’ll see a feasible fix.

Also also: I’ve massively improved GHOST generation. CHARON now sends instructions to SHADOW, which generates and serves GHOST binaries. It also has a caching mechanism, so if a binary with the config you want has been built before, you’ll (almost) instantly get it back! How cool is that :3

Unit tests! This one’s amazingly quick, but, as usual, had to be done. Would you believe that these actually found a bug that I haven’t stumbled into yet? Yeah, fixed it x3

Next up I’ll go through all of AETHER and prepare them individually for the release. Then, I’ll test integrations and ease of use, and, finally, there will be an official v1.0 release! I can’t wait jfkdasfhsdjhb

But yeah, getting closer and closer!

Finally parametrized GHOST builder to a point where I’m satisfied with it. Has everything you’d need, you can choose not only which modules should be active, but also which techniques!!

In other news, the documentation is fairly complete for now. It has a guide on how to use CHARON, describes the architecture and code guidelines well (I think so at least…), and finally structures the whole thing.

I’ve also added auto refresh! Before that command output sent back by GHOSTs (and SHADOW as a proxy) would not get loaded until you manually switched the view and back. That should’ve never happened. Oops…

CHARON got refactored. It looks the same. It feels the same. But that’s good! That’s exactly the point :3

The architecture behind CHARON got completely rethought and revamped. It’s now modular, designed with the MVC (kind of) model in mind. It is now 100x more maintainable and easier to work on. I didn’t really notice how big it got until I had to refactor. This one’s done.

Now I need to create some extensive documentation. Why extensive? Well, it sounds cool, and it saved my butt in GHOST a couple of times already, so I know this one’s gonna pay dividends as well. Then, only SHADOW will be left… But I don’t think it needs much (if any) refactoring. Will look into it when I get there!! For now, enjoy the beauty of CHARON’s new heart :3

All good things in life take time, huh? Well, this documentation must be one of the joys of life, cause it’s taking forever to design and write. On the flip side, I’ve also finally implemented the GHOST builder in CHARON. It’s still not fully tested and not production ready, and I still need to figure out how to get it to work with the dockerized versions of CHARON and SHADOW, but I’m one step closer now!!!

Also, the documentation I made last time saved my butt this time around… Current (future) me is very thankful for that. Hopefully the docs I made now will be of at least this much use in the future x3

Also, also, guess what! Another refactor, probably… It’ll be CHARON this time, because with the new functionality the files are getting really messy. Not looking forward to that, but… it has to be done I think. So it will get done! …eventually

This “sprint” was almost entirely focused on finishing the GHOST refactoring and creating fresh, new, polished READMEs for all modules (my favorite, and also the most complete, is the GHOST README). What this means, by extension, is that the project is progressively getting more mature. It’s to the point, that I had to write down the coding guidelines for GHOST to not check other modules for style reference every time I need to add something. They took quite a while, but I think this time will pay dividends.

The progressing maturity of all modules marks a fast approaching release version. The TODO lists are shortening, which means we’re getting closer to the v1.0!! SHADOW and CHARON are already dockerized, and AETHER has a docker-compose file for both of them! They are already a one-click deploy, so I only need to figure how to make GHOST easy to use (I’ll figure it out soon enough…), and then think if/how I want to approach the GHOST builder for CHARON. It’s currently a problem for the future me, so I’ll leave that to him :3

Overall, I don’t think I could be more satisfied with how AETHER is turning out. It’s got more love and passion poured into it than any other project I’ve worked on before. I’m almost proud of it…

GHOST refactor is complete. It was surprisingly less painful than anticipated, but it obviously wasn’t a walk in the park either. While I was getting GHOST ready, I also started thinking about the v1.0, and more particularly an easy deploy option that would make even not very tech-savvy people able to try and play with these tools :3

What I’ve done in that regard is:

• I’ve created or adjusted Dockerfiles for SHADOW and CHARON
• I’ve created basic instructions for running them on their own
• I’ve created a docker-compose file that deploys both of them (and assures communication between them!!), which makes this a one-command deploy

I would also like to add a GHOST builder in the near future, but I’m a bit afraid it’ll cause another GHOST refactor… On the other hand, GHOST is really modular rn, so it shouldn’t be anything major… I’ll think about it more when I get to it :3

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.

This one’s short. Added a blueprint for the exfiltration module. While doing that I’ve noticed how tangled up this codebase has become. The Rust ones are a bit better, they don’t need many changes, but GHOST has completely derailed. This is why I’ll be refactoring it for now. It needs to be easier to add things, it needs to be parametrizable and just overall better designed. I now have the overall idea of what it should and shouldn’t be, so I’ll proceed with this knowledge and refactor the codebase to suit this need.

I hope it’ll be easier than I think…

More of a list this time:

• Add killswitch to GHOST
• CHARON can now trigger killswitch in GHOSTs
• The killswitch removes any persistence and the binary itself
• CHARON can now update GHOST sleep interval and jitter
• GHOSTs now send command output immediately. CHARON shows that output and scrolls if needed
• Revisit the initial idea and statuses of all modules

For full v1:

• Add Dockerfile to SHADOW and CHARON
• Improve READMEs of all modules
• Add GHOST build functionality to CHARON
• Add basic impact and exfiltration modules to GHOST

CHARON now let’s you communicate with GHOSTs and execute commands on them! This required an adjustment to the SHADOW (adding 2 new endpoints to be precise), which in turn cause a somewhat major refactoring to how tasks are stored and managed. This, of course, in turn entailed a test-suite adjustment (to not call it a rewrite…) and adding tests for new endpoints to keep the high coverage. It was tedious, exhausting and required a lot of precision, but CHARON is considered done for the time being.

Next thing to do for me is enabling GHOSTs to reregister to SHADOW with their old id (somewhat possible by design, but they need to store and read the id from somewhere, so that’s the focus now).

After that I’ll very slowly start getting ready for the first major release. This means rewriting READMEs, structuring them more uniformly, backlinking them, adding easy deploy options (Docker; possibly docker-compose for AETHER) and manually testing that everything works as expected. More functionality will probably get pushed in the meanwhile! Sorry not sorry…

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.

The most tedious task so far has been finished. Well… part of it. To keep the code maintainable it’s important to create tests to ensure your quick and dirty “hotfixes” don’t end up breaking half the functionality. Tests are here to let you know when something stops working… not to assure you that something is working.

Creating them required a small refactor: API handlers and Router that previously resided in main.rs had to be moved to lib.rs. At least that’s what I’ve read is necessary, and these people probably know more than I do, so I’ll learn from them :3

I hate writing tests, but I know that future me will be forever grateful that I did. So I’ll take one for the team, at least this time ^^.

The caveat is that CHARON and GHOST should also have a reasonable test coverage, so it’s something to think about when they’re closer to the finish line…

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)