In May 2025, a number of RAR and EXE files associated with the domestic IP 158.247.250[.]251 were discovered. This IP was identified in past DNS records as being related to a phishing infrastructure associated with Naver, and there are query records related to Naver login URLs in VirusTotal.caption - URL query records of 158.247.250[.]251Among them, the relevant email files and the attached RAR and EXE files were reported from South Korea, and the email account that received the emails also belongs to a domain of an energy company in South Korea. Malware associated with this IP has been distributed under different file names in various countries besides South Korea. Analysis revealed that the distributed files were packed Formbook malware identified as being packed with PureCrypter.

Challenge OverviewThe goal of the challenge is to find vulnerabilities in the renderer process and develop an exploit code by analyzing the provided rce-sbx-138-0-7204-97.patch file.The patch file creates a new Blink module called minishell in the renderer. It provides various shell functions and file writing and saving, and the file data is managed through Codegate File System (CFS), which is a browser API.The available commands are:They are similar to the basic shell commands. Commands such as exec are not implemented, but there are several file operations.When a file is opened, it is managed through file_descriptor_ in the form of a FileBuffer class until Save.A user can invoke the minishell as follows:Callable methods can be bound in the *idl file.In short, one user can have multiple shells and execute each command in one shell.VulnerabilityWe can see the main functionality in mini_shell.cc.However, the vulnerability is pretty simple compared to the file size. The following shows the FileBuffer structure.In here, we can see the fixed-size buffer. Let’s check the part which uses it.There is a size check for the input data vector, but there is no any bound check for idx_ so an out-of-bounds (OOB) read/write occurs.Although the vulnerability is simple, we need to obtain arbitrary address read / write primitives with this relative address read / write, and finally achieve Arbitrary Code Execution.Exploit - AAR/WNow, we have relative read / write primitive of uint64_t size. In fact, there is no difference in the method to achieve arbitrary address read / write.However, in order to access an arbitrary address, we must know the address of the current object. This is because we need to measure the distance to move to the target.There are various ways to leak the address of a controllable object.In this challenge, it is difficult to achieve address leakage with just a simple OOB read because there is no valid address area written anywhere in the heap area. Among them, we tried using brand new technique that can stably leak objects by utilizing the characteristics of Oilpan GC.Oilpan GCThe Heap object of Oilpan GC has the following structure [link].Oilpan GC uses a different allocation method than PartitionAlloc (PA), which is mark-and-sweep and space. Unlike PA, which uses slot-bucket, Oilpan allocates space for the heap and divides (i.e., allocates) the heap object as much as requested size from the space when a request comes in.In other words, without a fixed slot, it dynamically allocates multiple sizes in each space.When they lose their reference and are GC reclaims them, they take the form of FreeList::Entry.When an object in the space is freed, the HeapObject changes to a FreeList::Entry, and additional next_ fields are created to point to the next freed object.Leak IdeaThe idea is as follows:Loop the action below enough times to allocate new spaceSpray shell objectSpray File in each shellTrigger gc()Read the next_ of the header of the next adjacent chunk of FileBuffer in the N-th Sprayed ObjectLeak (N-1)th Sprayed_objectSince each shell has only one File Buffer, N shells are needed to spray N File Buffers.Considering the characteristics of the Oilpan GC described above, consider the following chunk situation.Currently, there is only my object in space. When an object is dynamically divided(i.e., allocated) from space, gc() is executed and the small areas between each object will be treated as Free Entry, forming a FreeList as shown above.We can now read the chained Free Entry by reading temp = sizeof(FileBuffer) + 0x8 from the Sprayed2 object, and leak the Sprayed 1 address through heap_leak = temp - sizeof(FileBuffer)This allows us to leak the address of the object with only spray and out-of-bounds, regardless of how big the distance is between Sprayed 1 and Sprayed 2 whether there is a stable address.Since we have the address of the Sprayed 1 object and the relative address read / write, we can perform arbitrary address read / write.In the exploit, after sufficient spray, it triggers gc() and then leaks objects 90th to 89th.Exploit - Arbitrary Code ExecutionNow, we obtain the arbitrary address read / write primitives.In a typical V8 engine, addrof is used to obtain address of a Wasm RWX Page. However, we only have OOB, and it seems difficult to create an addrof primitive.So what should we do?Overwrite the vtable of HeapMojoRemote to call 0x4141414141414141?The challenge says that it should be exploited on chrome.exe running on Windows 11 24H2. That is, in order to achieve arbitrary function calls in the challenge, CFG Bypass must be accompanied. Of course, considering the huge size of the code base, there may be many gadgets that can bypass CFG.Also, Function::Invoker Chaining, a well-known technique, can bypass CFG.We wanted to find a more stable method, and after auditing the code, we found that there is a LazyInstance Getter for WasmCodePointerObject. We can leak Wasm RWX Page by reading WasmCodePointerTable → entrypoint_.Let's overwrite RWX Page with arbitrary shellcode and execute wasm exports function.In the end, we can stably execute arbitrary shellcode while maintaining persistence. An interesting fact is that the bug of the SBX challenge can be triggered even in the Renderer. However, triggering the vulnerability requires a slight race condition in the SBX Challenge, we are unsure whether UAF Object can be reliably occupied in Blink.

While analyzing JavaScript files collected using VirusTotal's hunting feature, we noticed that a specific smart contract address appeared in multiple files. Further analysis revealed that this smart contract address is associated with the EtherHiding technique used in the ClearFake campaign.The ClearFake campaign is a sophisticated attack that utilizes both the EtherHiding and ClickFix techniques to conceal and distribute malware to a wide range of users. EtherHiding involves hiding malicious content within Ethereum smart contracts to evade detection. ClickFix is a technique designed to lure users into clicking, thereby triggering the execution of malicious code.This report details an analysis of the ClearFake campaign, which leverages both the EtherHiding and ClickFix techniques to distribute malware to a large number of users.