Just recently a user of our new malware analysis service at www.hybrid-analysis.com sent us an E-Mail regarding a report. In this case, it was an analysis of a "memory malware" (so called fileless malware) that tries to reside only in memory. The sample analyzed is quite extensively described in the following blogpost by Corey Harrell, which is a good read by the way.
Before diving into this blogpost, this is the sample and report we will be refering to (you can download the sample from the VxStream Sandbox Report at the top):
Sample SHA256: 4727b7ea70d0fc00f96a28de7fa3d97fa9d0b253bd63ae54fbbf0bd0c8b766bb
VxStream Sandbox report: https://www.hybrid-analysis.com/sample/4727b7ea70d0fc00f96a28de7fa3d97fa9d0b253bd63ae54fbbf0bd0c8b766bb/
Anyway, if we come accross some interesting samples or blogposts, we always try to see if we can replicate similar results with our system. If we do find a good example, then we like to share it now and then, because although automated malware analysis systems are not "perfect" or a "silver bullet", they can aid a professional in their daily work process, be it on a manual level or on a larger scale system that processes thousands of samples per day. Actually, the user mailing creates yara rules that are applied to a process memory scanning application so that unique artifacts are valuable information.
The most important artifacts that were deducted from the blogpost Corey wrote about is the C2 IP address 178.89.159.35 and a rundll32.exe call with a javascript shellcode:
(Source: Corey Harrell)
So, let's take a look at our own report now...
Finding artifacts using the VxStream Sandbox Report
After scrolling past the variety of signatures at the top of the report (which do contain quite some interesting matches, such as the PE timestamp that claims the program is from 1979 or the native function call to NtSetValueKey), we quickly arrive at the Hybrid Analysis section (take note of the new tooltip that indicates to users that they can click on an analyzed process to extract more detailed information) and see the Network Traffic as well:
So the C2 server 178.89.159.35 (as well as .34) was actually contacted. Good enough you say, but let us take a look at more details and click on the child process (PID 1784). Although we are not overwhelmed by details, the "Streams" section is especially interesting this time around. As the detected streams are sorted by an internally computed "Relevance" (based on the number of Strings/APIs, number of instructions, etc.), we find an interesting disassembly stream right at the beginning.
Stream 08093078-00001784-51075-88-00401BF5 (Executed: false, Relevance: 136.4)
Extracted from 08093078-00001784.00000001.8120281.400000.00000040.mdmp
Scrolling down a bit we actually find the shellcode mentioned in the blogpost quite easily:
Taking a look at another function we find the hardcoded C2 IP addresses and the query format:
The "Executed: true" note matches our expectation after having seen the network traffic earlier. Also, it is nice to see a reference to the memory dump file where the disassembly was extracted from, in case we want to analyze the correct dump file(s) in e.g. IDA or another professional disassembler.
If we would use the full XML report that contains all data in a structured format and parse the entire context, then it suddenly becomes possible to create even stronger, more context sensitive rules to detect and classify malware. For example, if one would consider not only a single keyword of the shellcode (like RunHTMLApplication), but the presence of NtSetValueKey API call or a certain order of API calls, then the overall detection ratio and false positive ratio could improve considerably. That is one of the advantages of combining memory dumps with static analysis and dynamic information.
Conclusion
This small blogpost outlined the advantages of Hybrid Analysis. In this blogpost we took a look at a memory malware sample and made an example of how quickly it is possible to determine and extract artifacts for rule generation. Not in the same fashion as would be done by a professional incident response team member, but with similar and evenly worthy results.