Decided it was time to upload a few Yara rules to my Github. Most of them are pretty old unfortunately but there's some stuff in there that might be useful. I'll add more if/when I can.

Here's some I had luck with:

Hunting for Github/Telegram integration in a PowerShell script (in conjunction with -Uri):

https://github.com/ozuriexv/Detection-Rules/blob/main/YARA/misc/service_usage_powershell.yar

Common file magic other than PE but contains XORed DOS stub:

https://github.com/ozuriexv/Detection-Rules/blob/main/YARA/obfuscation/misc_obfuscation.yar#L1-L14

Generic/common Windows paths targeted by stealers:

https://github.com/ozuriexv/Detection-Rules/blob/main/YARA/hunting/hunt_stealers.yar

While my following/reach is relatively small on here compared to Twitter, I want to start this discussion regardless.

Red Team vs.(?) Blue Team

Frequent releases of offensive tooling, specifically C2 frameworks are awfully detrimental to blue teams. As someone that works on network detections, observing newly published frameworks regularly is disheartening and frustrating. It's no secret that open source offensive tooling is adopted by APTs and cybercrime groups and that leaves me with one question, why do it?

From my perspective, I can see some value in open sourcing such tooling for the purpose of assisting other red teams with engagements but surely the fact that malicious actors adopt the same tooling heavily outweighs the pros here?

For the red teamers following me (if any), what is your opinion on this issue? Why does it feel like 'vs.' is legitimate here but for the wrong reasons? These practices are also (in my opinion) contradictory to what purple teams stand for and shouldn't be considered purple teaming by any stretch of the any imagination.

I'd like to keep snarky/passive aggressive remarks (I've been guilty in the past) to non-existent here please. If you want to call me an idiot, my DMs are open.

For those of you authoring Suricata signatures on version 4, be tremendously cautious with your use of the tls.fingerprint and tls.cert_fingerprint buffers. Suricata 4 cannot apply a fast_pattern to these buffers meaning that if you create a rule only containing those buffers, your signature performance will be soul crushing.

I recently pushed our (Emerging Threats) entire ruleset through QA across many pcaps and the 2nd worst performing signature out of all rules, across all support engines (suri5, snort2.9), was a Suricata 4 rule using tls.fingerprint.

If you're familiar with the ET rulesets, you will know that some of our rules contain absurdly lengthy PCRE and for this signature to perform significantly worse than those rules is very telling.

#infosec #ids #suricata

Seems you can push entire blog posts or even novels on this platform with the 11k character limit, wild. Since I have that many characters to use, here are a couple of resources for further understanding Surciata/Snort signatures and some of the common buffers you may come across.

Authored by myself, focused on SSL/TLS signatures - https://justjamesnow.github.io/Suricata-Round-1/

Authored by a co-worker, focused on understanding & using byte_jump effectively - https://community.emergingthreats.net/t/the-complexities-of-byte-jump/111

You can expect similar from this account in the future as well as various IOCs (when possible) and a bunch of free detection stuff.

#yara #suricata #snort