The differences in outputs are clearly demonstrated in Figure 8 and Figure 9 with the same code being attempted to be decompiled in both figures. With a rebuilt binary, decompilation tools were then able to successfully analyse the malicious binary. We chose to leave the stack comparison instructions in the deobfuscated binary while removing the fake branches for two reasons firstly they do not affect execution of the sample as the obfuscation technique ensures they are never placed between a valid comparison instruction and its resulting conditional jump and secondly each numerical value used in the obfuscated comparison instruction occurs exactly once in the original obfuscated sample this means that when analysing the deobfuscated sample an analyst can verify that the output of the deobfuscation tool is accurate by searching for the constant value used in the original binary and checking the expected instructions in both binaries match up. 5 This demonstrates the benefit of this approach as in Figure 6 only the first three meaningful instructions were able to be displayed in an analysis tool, whereas in the deobfuscated binary a plain disassembly listing is evident, showing many more instructions while taking up less space. The results of this deobfuscation can be seen in Figure 7. In doing this, the resulting binary will be very close to what would be produced from compiling the original source code with a standard compiler. There are several approaches that could aid in statically analysing code obfuscated in this way, however we have taken the route of rebuilding the malicious binary with the jump and stack obfuscations removed. DoppelPaymer ransomware binaries) who go to extreme lengths to avoid their malware being analysed. Similar techniques have been seen used by financially motivated threat actors (e.g. It is uncommon for China-based actors to employ such extensive custom obfuscation techniques and indicates either a greater level of capability or a greater need to avoid detailed analysis once discovered than other China-based threat actors. Further, the targets of the conditional jumps are often into the middle of existing instructions, or to code halfway through functions which prevents disassemblers and decompilers from correctly analysing the flow of execution.īoth of these techniques are likely applied as part of a custom compiler pass 4 as they significantly modify the control flow of the binary, which is easiest to do before the final assembly instructions have been generated. In practice, it is impossible for the stack register to be a small value, as on x86 and 圆4 systems the stack is placed in high memory ranges. This fools disassemblers into thinking the code could take the jump if the current stack register is a small value. Throughout the malicious code, the stack is compared to various low values and then a conditional jump is placed after the check. This is the second technique that ScatterBee employs to obfuscate control flow. The resulting code has similar instructions to a standard function epilogue (push ebp mov ebp, esp) but then has a strange comparison instruction comparing the stack register – esp – to 0xe1cf. Most of the malicious ScatterBee files can be directly linked back to a China-based threat actor that we are currently tracking as Red Dev 10. This content has previously been made available privately to clients via PwC’s intelligence subscription service.ĭuring our analysis, further malicious samples were uncovered which indicate that one or more users of ShadowPad have access to ScatterBee, and have highly likely delivered some of these malicious payloads via watering hole attacks on sites that are used to deliver Adobe Flash update files. The obfuscation mechanism has been briefly touched on in open source 1 however in this blog we detail how the technique works, ways to analyse binaries obfuscated in this manner, and how to find further samples obfuscated with this bespoke method. While monitoring for the backdoor known as ShadowPad, our threat intel practice discovered a bespoke packing mechanism – which we named ScatterBee – being used to obfuscate malicious 32-bit and 64-bit payloads for ShadowPad binaries.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |