Raphael Mudge

OK, so mTLS as a means to accomplish C2 comm security goals, abstracted above proto/data transport? Again, just spitballing. My thinking: I'd want something statically linked (e.g., no dependence on Win32 API for this) and then it would be size/complexity vs. getting acceptable outcomes another way.

The Harder Right I spent 25 years in uniform, including four as a cadet at the United States Military Academy at West Point and two and a half more teaching economics and national security at West Point’s Department o...

Jen Easterly writes a post on LinkedIn addressing her position at West Point being rescinded: "A casualty of casually manufactured outrage that drowned out the quiet labor of truth and the steady pulse of integrity."
www.linkedin.com/pulse/harder...

I didn't look at it during my run. The mTLS security would be moot to me, C2 crypto needs to provide confidentiality/server auth, not the channel. It didn't look like a new egress hole one needs to demo explicitly (e.g., like DNS, ICMP, HTTPS via proxy, etc.). Do benefits justify dev/maint efforts?

Libera Chat (FreeNode successor) hosts several (defunct? :)) channels for OSS projects. There's still a few folks idling in #armitage and #metasploit over there.

libera.chat

jIRCii - Java IRC Client jIRCii is a fully scriptable internet relay chat client for Windows, MacOS X, and Linux. It's free too

I just updated my 25+ year old IRC client, jIRCii.

Curious about Aggressor Script's ancestor? It's here.

Update improves IRC over SSL/TLS UX, fixes some bugs, tightens some screws, and fixes build to compile on OpenJDK 10+.

jircii.dashnine.org/download/

CC @hagiagraphe.bsky.social

The problem is... I'm an incessant tinkerer and can't stop. I have this fantasy that I'll make a few updates and not touch the silly thing for another 15 years. I'll ping you when I've posted the latest source/bins. Thanks for your interest in this very old labor of love of mine.

Try again. I just pushed a few bug fixes and some other accumulated odd and end changes I've meant to act on eventually.

GitHub - rasta-mouse/Crystal-Loaders: A small collection of Crystal Palace PIC loaders designed for use with Cobalt Strike A small collection of Crystal Palace PIC loaders designed for use with Cobalt Strike - rasta-mouse/Crystal-Loaders

Published a small collection of PIC loaders for Cobalt Strike, based on my experiments with Crystal Palace.
github.com/rasta-mouse/...

[BLOG]
Here's the post - I demonstrate my QoL improvements for working with the TCG codebase. This includes vscode with intellisense support, and producing debug builds for use in WinDbg.
rastamouse.me/debugging-th...

It's really a question of how much design contract to create (and where) vs. separation and obliviousness of components. But, a lot of possibilities, and a really fun problem set to consider.

Last last thought: @rastamouse.me 's blog post shows that API cross-linking stuff (CP import command to patch func symbols). Nothing says a .spec contract loading a capability can't have a specific tradecraft opt-in API passed onto agent .o's that the loader/tradecraft layer must implement.

Last thought: while I'm on a tradecraft+capability separation kick, I intend Crystal Palace as an open-ended object/PIC stitching sandbox. Keep playing with it. Try different ideas. It's really cool. This is what organic cross-inspiration and conversation looks like. I pivot when inspired too.

Other value of a PIC-specific linker (ala Crystal Palace) is error checking for this use case (aka, calling out unresolved relocations, spotting jump tables, etc.). A headache saving guardrail for more involved PIC projects.

Further, part of my interest in a bespoke linker as a research foundation: I reckoned bin2bin transformations might be easier with symbol info/relocs present... and I built these things into Crystal Palace (+mutate +optimize +disco) too. Bolsters potential value-offered at assemble time.

I'll re-iterate this though:

I believe a linker is the missing link in this type of problem set. It's the natural tool-fit to assemble things together in a desired way. Different models for doing that (e.g., merging vs. appending with some symbols shared). Each makes sense for different needs.

That's what I think about the modular agent problem set (through a Crystal Palace lens).

1. Merge COFFs, before CP, and apply loader to capability, OR...

2. Create modular loader+kernel+C2 agent contract with assembly dictated by .spec, OR...

3. Stage .specs to assemble agent, apply loader, etc.

Capability building with one .spec and apply a loader to that built thing via another .spec could be an option too.

Now? Use make object -> export to spit out a PICO as a .bin. Consume that (don't use make object again) in another loader-oriented .spec file.

Would work now. Could be cleaner though

IF I wanted to stitch together an agent dynamically with a .spec file and was using the API to do it. I might have a loader contract (e.g., $KERNEL = .o for base agent services, $C2 = .o for comms) and expect the .spec file+loader to act on these $VARs. This would be similar to Daniel's post.

That merging is something I would do before Crystal Palace.

(This doesn't mean no runtime extensions in arch.)

This isn't the only model:

Remember Crystal Palace has a CLI, but it has a Java API too. That's less awkward/constrained vs. the CLI. Can pass several $VARs--whatever one wants really

If I were building a modular agent as COFF paired with a loader, my current instinct is that I'd prefer to merge objects and have an internal API each module might implement to stub or bring functionality (e.g., C2, socks). This is the cleanest, works with my separated loader+capability model way.

(The point of the above is I'm acknowledging the blog post for its intended purpose, which is: stimulating conversation, getting folks to think (myself included), and consider possibilities.)

So, here's where I came to with this...

And, this is where Daniel nerd-sniped me. Because in his blog post, he's exploring Crystal Palace .spec files as a tool to decompose an agent into parts and assemble it based on your wishes (and he showed cross-linking functionality too).

I'm not in the C2 game and didn't reflect on this enough...

BUT, I also recognized as I popped my gopher head up... a sea change too. Folks exploring PIC as alt. to DLLs. I'm here for it! So, I pivoted the project to demonstrate the same architecture/ideas applying to PICOs (Crystal Palace COFF). I proposed loaders+COFFs as a alt. to PIC or loaders+DLLs.

And, with Crystal Palace+TCG: My initial foray into this journey was treating DLLs as the ready-to-instrument capability container. Fits well with CS's UDRL/post-ex UDRL model. Boosts it too.

rastamouse.me/harvesting-t...
rastamouse.me/harvesting-t...

I imagine custom/other tools benefit here too

Remember my ultimate Crystal Palace and TCG tech goal: I'm containerizing load/runtime tradecraft and separating it from C2 capability. This is to buy social cover for public research, make it more sellable/consumable for extra-C2 uses, and some x-tool use/benefits is nice. More maintainable too.

@rastamouse.me digging more into Crystal Palace and demonstrates some of the cross-linking possibilities.

I'll admit, I got a little nerd-sniped here, because I'm *not* thinking greatly about "the" way to decompose a complex/modular capability (e.g., a C2 agent).

Thread below has my thoughts...

Aww thanks. Next release should take Crystal Palace closer to "feature complete" for now. Nothing as tedious as the BTF work (which I'd just stub out, if doing a like-implementation). But, I hope to make clear(er) the vision for accommodating different capability with the same tradecraft-Fun project

I loved this keynote. But, also felt sadness. Where there is tribe and purpose in our uniqueness in the "hacker community"--there's also a capacity & indifference for cruelty to each other too. I liken it to a smiling group with cannibals present. Room goes dark. Someone disappears. No one cares why

I fixed the login required on my PIC fundamentals Vimeo video.

In this go around, I'm experimenting with keeping control of my online content (e.g., no GitHub/YouTube, I pay to host it, etc.)

Less algorithm spread, but ideally easier to access w/o ads.

Back fired this time. I'm learning as I go.