Back 
概要
The Play ransomware, also known as PlayCrypt, is a ransomware that first emerged in June 2022. The ransomware has been targeting industries such as healthcare and telecommunication as well as a wide range of regions such as Latin America, Europe, and North America. The Play ransomware is known for gaining access to networks through compromised valid accounts or by exploiting specific vulnerabilities. Once inside the network, it uses a big pool of known post-exploitation tools to continue its attack. Tools like Bloodhound, PsExec, Mimikatz, and AdFind are some examples of tools previously used in attacks involving this ransomware.
Another aspect of the malware that makes it famous is the amount of anti-analysis techniques it uses in its payloads such as abusing SEH and using ROP to redirect the execution flow. By employing techniques to slow down the reverse engineering process, threat actors make detection and prevention of the malware more difficult.
Back in 2022, other researchers published an excellent blog post analyzing the malware itself and some of the anti-analysis techniques it used. In this blog post, we’ll revisit the anti-analysis techniques employed by recent variants of Play ransomware, explaining how they work and also how we can defeat some of them using automation scripts.
Return-oriented programming (ROP)
When reverse engineering malware, making sure that the control flow is not obfuscated is one of the first things we need to do in order to properly understand the malware.
As an attempt to obfuscate its control flow, the Play ransomware often uses an ROP technique in its payload. It does so by calling over a hundred functions that patch the value on the top of the stack and then redirects the execution flow to it. Before we talk about how the malware does this exactly, let’s take a look at how the CALL and RET assembly instructions work in general.
When a CALL happens (a near call in this case to be more specific), the processor pushes the value of the instruction pointer register (EIP in this case) on the stack and then branches to the address specified by the call target operand, which in this case is an offset relative to the instruction pointer. The address in the instruction pointer, plus this offset, will result in the address of the function to be called.
The RET instruction on the other hand indicates the end of a function call. This instruction is responsible for transferring the program control flow to the address on the top of the stack. And yes, this is exactly the address initially pushed by the call instruction!
Considering what was mentioned, in an ideal scenario the highlighted address in the image below would be the next instruction to be executed after a call to the target function (sub_42a4b9):
What the malware does to abuse how the CALL and RET instructions work can be observed in the following image:
Once the function is called, the address 0x42a4b4 is pushed to the stack, so ESP will point to it. The called function then adds the value 0xA to the address pointed by ESP and then returns using the RET instruction. These operations result in the control flow being redirected to 0x42a4be (0x42a4b4 + 0xa) instead of 0x42a4b4.
By applying this technique the malware makes not only static analysis more complex, since the program flow will not be trivial, but it can also make debugging harder because if you step over this type of function a lot of things can happen before the regular “next instruction” is executed.
Another way the malware implements this ROP technique is by using the approach shown in the code below, which is very common in shellcodes. The offset specified by the target operand of the call instruction is zero, resulting in the address of the function to be called exactly the address of the next instruction. This address is then pushed onto the top of the stack and the rest of the operations are exactly the same as the previous example:
In order to help in the analysis of the Play ransomware, Netskope Threat Labs developed a script, based on previous work of other researchers, to fix the ROP obfuscation employed.
The script searches for possible ROP candidates, collects the offset to be added to the top of the stack and patches the addresses performing the ROP calls with an absolute jump, where the target is the modified transfer address calculated at runtime.
The following is an example of how the malware payload would look before and after the script execution:
Before:
After:
Anti-disassembling
An anti-disassembly technique used to trick analysts and disassemblers is to transfer the execution flow to targets located in the middle of other valid instructions.
Let’s take the function call at 0x42a4af used in the ROP section above as an example. The opcodes for that CALL instruction are “E8 05 00 00 00”. The byte 0xE8 is the opcode of the CALL instruction itself and the other 4 bytes represent the target operand (the offset relative to EIP).
As we discussed previously, the address of the function to be called would be the value of EIP (0x42a4b4) + the offset (0x5) and that results in the address 0x42a4b9. However, this value falls into the last byte of another valid instruction at 0x42a4b5:
In terms of execution, this type of behavior changes nothing because the processor will understand the instructions correctly. However, a disassembler might not present the instructions correctly depending on the approach it uses (e.g. linear sweep), making static analysis a bit tricky.
The script we provided to fix the ROP calls also handles this scenario for the ROP targets. Considering we use a JMP instruction to patch the calls we end up also forcing the disassembler to understand the correct flow to follow.
Junk code
Although this is a very simple technique it’s still worth mentioning because it can definitely slow down the analysis of the malware. The junk/garbage code insertion technique is exactly what the name suggests: the insertion of unnecessary instructions in the binary.
Unlike the tec