ESET Wiper - Hey ESET, wait for the leak..

I've reversed engineered the ESET Wiper targeting ESET's exclusive partner in Israel to send phishing emails to Israeli businesses. See this article on bleepingcomputer.com.

Analysis

The malware seems to be written in plain C Let's jump directly to the entrypoint.

The start routine only calls a single subroutine...

Which seems to be the C runtime initialization by gcc. The only interesting subroutine call in this one is the call to the real main routine (see image above). Taking a look at this one, one can see, that the malware uses the process environment block for (PEB) for resolving windows library functions to circumvent calls to hooked windows API functions. This is done to evade EDR detection, which usually hooks common Windows API functions used by malware. See the image below.

After resolving base addresses to some windows libraries like kernel32.dll by iterating over the InMemoryOrderModuleList of the PEB, the malware resolves WinAPI functions by their names. See the image below.

It first decrypts a base64-encoded and xor-encrypted string using a subroutine which I'm calling base64_decrypt. See the Image below.

This routine firstly base64-decodes the string and then xors it with the string "Saturday, October 07, 2023, 6:29:00 AM". I've used BinaryNinjas API and wrotea script to decode all strings in the binary by iteraing over all calls of this routine. After decryption of the WinAPI function name, the malware calls another routine, named get_subroutine_from_export_table which walks over the import address table (IAT) of the particular loaded windows library to find the address of the function. See the image below.

Then, it fetches its own location on the disk by a call to GetModuleFileNameA and checks if it lays inside of C:\Users\Public. If so, it tries to open a configuration file at C:\Users\Public\conf.conf and then calls two other subroutines. See the image below.

If it is not located in C:\Users\Public it fetches the configuration file by calling a subroutine of which I named fetch_json_config. See the images below.

This routine uses the Windows INET API to fetch the configuration from www.oref.org.il/alerts/RemainderConfig_eng.json.

This config is then written to C:\Users\Public\conf.conf by calling a function I named dump_memory_to_file. Then, the malware copies itself to a file named SecurityHealthsSystray.exe. See the image above.

Finally, it calls a subroutine named sub_4016c0 with the content of the configration which was fetched before. Turns out the content is used as the key for decrypting the embedded stage 2 payload. sub_4016c0 is called every time at the end of the main of the malware, despite of whether the malware is located in C:\Users\Public or not.

Inside of sub_4016c0, the subroutine firstly decryptes many static strings and stores them on the stack.

Then, it dumps a few files into C:\Users\Public:

1. a video named video.mp4 which is a propaganda video showing dead soldiers
2. an image named image.jpg which show the logo of the threat actor
3. another PE which is stored in a file called MicrosoftEdge.exe
4. another PE which is stored in a file called csrs.exe

See the screenshot below.

Then it checks whether the processes MicrosoftEdge.exe and csrs.exe with the payload are already running or by iterating over the process list returned by CreateToolhelp32Snapshot. If not, it spawns them using CreateProcessA. See the two images below.

Since the url points to the configration file with the key for decryption of the payload is not reachable anymore, I cannot decrypt the payload. But my guess is that it contains the code which wipes the system.

After spawning the malicious processes with the payload. The malware waits for 120 seconds by calling Sleep (see image above). Then it continues and plays the dumped propaganda video by opening it using ShellExecuteA and open. See the image below.

After that, it finally shows the text "Hey ESET, wait for the leak.. Doing business with the occupiers puts you in scope!" using MessageBoxA. Then the main process ends but my guess is that the spawned malicous processes MicrosoftEdge.exe and csrs.exe continue to wipe the system.

Conclusion

In my opinion, the malware is not really sophisticated. The obfuscation and evasion techniques are quite basic. The threat actor even did not made the effort to use API hashing or check for sandboxes nor debuggers.

I think that this wiper was written just with the intention to announce the message "Hey ESET, wait for the leak.. Doing business with the occupiers puts you in scope!".

Indicating that a major leak will happen in the next few days.

THANK YOU FOR READING!

IOC