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?
Mal devs themselves introduce some of the funniest & hi-fi (although short lived) detection opportunities. Amongst several applicable HTTP methodologies, we see "Content-Type:application/octect-stream." Don't manually type out your HPTP headers for your C2 protocolols. #dailypcap
This network traffic comes from newish backdoor ExileRAT (compiled 2019-01-30T07:05:47Z) 606e943b93a2a450c971291e394745a6 that was hanging (with a multitude of other evil) on recently #opendir "http://27.126.188[.]212" There are ties to a humongous cluster of probs CN espionage.
The attackers from IP 27.126.188[.]212 are rollin' deep with kit. get_robin.py (1) looks to be some derivative of github.com/bhdresh python toolkit and also does some logging of connections. Sc.dat (2) is HTML that does JS get and creates a scheduled task for the exe.
Another quick .NET triage/analysis of a related #PUBNUBRAT dropper/launcher (?) 1d155032232cd40c1788271546af36ec (U4.conf). This one we start immediately with extracting the 'app' resource using dnSpy to get 5bbe762b83e051776f1b5ea30ffc0050 (application/x-lzip).
5bbe762b83e051776f1b5ea30ffc0050 decompressed to the goliath ~8MB ca19c3c3c2ef656b33d7173a49186f5a (application/x-dosexec) which is also a .NET binary. Back in dnSpy, which nearly chokes on the size, we finally get to a main decryption routine.
We could take the next steps of this in a million ways, but this is easy to do in @GCHQ's #CyberChef. First From Base64 & To Hex the Key and IV for the crypto routine and save these in hex.