The Presentation file is here. The content will be helpful if you use openioc_scan and onigiri.
I published the script automating remote malware triage with F-Response and openioc_scan.
“Parameters” introduced in OpenIOC 1.1 allows embedding additional metadata about Indicators into the IOC (in more detail, see Blackhat 2013 presentation by William Gibb). I implemented functions displaying matched content details and scoring results of indicator matching.
Last year, I proposed “volatile Indicators of Compromise (IOCs)” based on RAM evidence only at SANS DFIR Summit. We can detect malware using them faster than using disk-evidence-based IOCs. Besides, we can define indicators based on not only metadata (e.g., file path) but also malware function (e.g., code injection sign, imported functions and unpacked codes). The IOCs are described according to OpenIOC specification. IOC Editor is used for defining IOCs and Redline is used for scannning IOCs.
Since then, I continued to make volatile IOCs and detect malware through the tools, but I’ve got some frustrating problems about them. First, We can’t automate IOC scanning for daily task because Redline is a GUI tool. Second, Redline is compliant with OpenIOC 1.0 but the spec doesn’t support regular expression, case sensitiveness. In addition, “AND” combination of different items (e.g., ProcessItem and RegistryItem) does not work. Furthermore, Redline cannot scan unallocated objects (e.g., dead process, unloaded kernel drivers). So I decied to make a new tool for volatile IOCs.
2 years ago, I talked about the anti memory forensic method by modifying Windows kernel data structure on victim systems at BlackHat Europe 2012. The situation is still the same.
I release Immunity Debugger and IDAPython scirpts dumping PlugX configs (and original PEs) then parsing them.
Recently, I acquired a PlugX builder/controller. This seems to be the same as the one referred in AhnLab’s APT attacks analysis report, judging from the GUI window. I tried to use it.
One day, I acquired a 16GB raw memory image on Windows7 x64 machine using MoonSols DumpIt for malware investigation. Then I tried to analyze it using Volatility Framework and Redline, but they returned no output like this:
I guessed the acquired image was corrupted, so I took an image again, but the result was the same. I googled about the problem and found a similar issue. According to the report, I tested several memory acquisition tools such as FTK Imager and Windows Memory Reader, but they didn’t work.
I changed an image format from raw to crashdump. Then Volatility Framework could parse it and display the result. Strangely, Volatility also could analyze the raw image converted from the crashdump. Where does this difference come from?
IOCs for memory forensics
Never forget to configure “advanced parameters” (check String and the length is 4)
- ZeroAccess for kernel/user-mode variants
- Poison Ivy
- Zeus 2.x variants including Citadel
- SpyEye 1.3.x
- Deobfuscating_SpyEye deobfuscate 4-byte hash values and strings
- zeus_string_decoder decode strings in ZeuS binary
- fix_junk_pony modify PONY’s junk code
Immunity Debugger script
- immbone_nx break on execute script on DEP environment (enable DEP and uncheck the option ignoring Memory access violation in the debugger settings)
- immbone break on execute script on non-DEP environment (disable DEP and uncheck the option ignoring single-step break in the debugger settings)
- blackmanta slightly-changed version for Immunity Debugger v1.8
- CrashDumpAnalyzer memory forensic EnScripts for MS crash dump
- RawImageAnalyzer memory forensic EnScripts for raw memory dump
- Timeline_Report_v1.8.1_CCI NTFS SI/FN timeline EnScript based on Geoff Black’s timeline EnScript
- PFDCforPE parse/filter/detect/carve PE files