@Iaintshootinmis I feel that most of what I say here (https://infosec.exchange/@ozurie/109355833508031830) applies to what you've just said. I do see value in open source offensive tooling but why is there seemingly no line drawn? When I've thought about this in the past, I've thought to myself "why not at least include signatures when publishing the framework" but, maybe that's contradictory to what the red team wants to achieve. That confuses me further because I often see statements implying that red and blue must work together, this is the opposite, no?

I'm unsure about CobaltStrike in this scenario due to it being a paid-for product but of course, there are plenty of cracked/leaked versions floating around.

James (@[email protected])

@GoblinLucy again, do the cons not outweigh the pros in this scenario? I definitely understand and appreciate additional material but when it's at the cost of assisting malicious actors, surely we draw a line? Adversaries will indeed build their own frameworks regardless but why assist them and hand them something on a silver platter that not only speeds up the rate of their operations, but can also cloud attribution efforts too? It's the same concept as strategic detection building. Ideally you'd want to base detections on elements that are costly to the adversary. For example if your Yara rule consists of a few strings, sure you may catch samples but those strings are easily changed. If you instead base your signatures on opcodes for some custom encryption routine, that will be significantly more damaging and as a result, will (usually) slow operations. Handing adversaries free C2 frameworks contradicts the end goal of slowing down their operations.

Infosec Exchange