ConventionEngine is *mostly* about PDBs, directory paths that reflect something about the original code project and development environment. The paths are the signal. Where else will they show up? Why, in OLE objects! Let's explore...
We had a revelation that seeing an RTF with an OLE is not that crazy, but when that inside OLE has, for whatever reason, a full directory path, the whole object becomes so much more interesting. For example, RTF with OLE with C:\Users\ in it. Let's use Yara to take a measurement.
Here's a quick #dailyyara rule looking for RTFs with OLE objects with a path of C:\Users\ in it...somewhere...for some reason. This is odd, and unsurprisingly super threat dense.
What other ConventionEngine rules might be good? I imagine anything with *a* directory path in an OLE would be good, and beyond RTFs maybe we apply this to OOXML as well. I will continue to survey and experiment. Join the fun!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
How do @Mandiant UNC clusters get formed, merged, and graduate to APT groups or even personas? Look at serial crimes and sprees in meatspace. Multiple crimes on multiple victim systems, multiple places. It takes forensic evidence to tie the cases together. It's the same process.
Foot impression from the crime scene. Is it unique? What shoe is it, where was it sold? How many made in that size? You have to know if the evidence is unique. All the casings, latents, entry toolmarks. Technical evidence is how we group crimes together and move towards an actor.
TTPs and MOs and methodologies and victimologies are important too, but these don't help you get attribution alone. Technical links, grounded in substantiated evidence is the only way.
Students of #infosec: @Mandiant and @FireEye folks have put out tons of blogs over the years. Careful reading of these can help you build familiarity with threat actors, intrusion TTPs, and threat data. And sometimes they're just fun. Here's a thread with some of my favorites:
PE files w/ exported functions often contain an image directory entry that we usually call something like "PE DLL name" or "export DLL name"
This string is "analytically rich" and is surfaced in many tools
Here in a sample of EVILTOSS (APT29) we see lots of valuable metadata in the IMAGE_EXPORT_DIRECTORY but it also contains the plain-as-day export DLL name "install_com_x32_as_dll.exe"
The export DLL name strings contains enough predictable developer conventions that you can use simple Yara rules to surface, cluster, detect/hunt for malicious activity that might otherwise be missed (similar to my prior research on ConventionEngine and PDB paths). Let's look...
You may not think attribution matters, but I think attribution is also on the detection spectrum, or #DETECTRUM. I'm trying to think about it as layers of additive traps that enable us to hedge our bets for visibility, resilience in detection, sometimes to figure out who dun it.
I think the #DETECTRUM can be used to model both inputs and outputs of the detection engineering process - whether you're plotting "logic designed to find evil," alerts, the tech, or the or the data itself. The graphs might look a bit different, but same ideology might be useful
The basis for #SwearEngine is that malware developers are developers too. The catharses in their malware code manifest in a multitude of coarse expressions. Thus we can use the presence of swear words as a "weak signal" to surface interesting files. #threathunting
You may balk at #SwearEngine for being #basic but consider that this rule, looking for PEs with one single "fuck", detects malware samples used by APT5, APT10, APT18, APT22, APT26, Turla, FIN groups, dozens of UNC espionage clusters. Too many to list.
At least one single "fuck" is present in some samples of the following malware families: AGENTBTZ, ASCENTOR, ZXSHELL, SOGU, TRICKBOT, GHOST, VIPER, WANNACRY, WARP, NETWIRE, COREBOT, REMCOS, VIPER, ORCUSRAT, PONY, etc. I can't even name the coolest ones. There are hundreds.
Hopefully the 2019 @CrowdStrike “heat map” and global prevalence of @MITREattack will set a precedent for how vendors publicly discuss TTPs, allowing defenders to prioritize detection efforts based on evidence rather than cool factor: crowdstrike.lookbookhq.com/web-global-thr…
The @CrowdStrike report does not discuss the biases nor provide real hard numbers on the TTPs, which I know from experience are hard to deduplicate on intrusions (some are over represented and some are under represented). Maybe @_devonkerr_ or someone can shed some light here.
I’d like for someone to explain how data was collected, where the gaps are, and how the global prevalence (GP) measurements vary w/r/t malware families, actor groups, fluctuating GP for TTPs over the last couple of years. What is rising and falling? What can’t @CrowdStrike see?