MalwareAnalysisReports/Fog Ransomaware/Fog Ransomware.md
at main · VenzoV/MalwareAnalysisReports
By VenzoV
Archived: 2026-04-05 22:48:53 UTC
Sample Information
Loader:
SHA256
8E209E4F7F10CA6DEF27EABF31ECC0DBB809643FEAECB8E52C2F194DAA0511AA
Analysis part 1- Loader
Overview
Junk code
First think to notice and be aware is that the malware employs a lot of junk code to bloat the main function. It is
hard to show how much, but below is part of a very large graph view of the file. Most of the junk code is made of
very large useless switch statements that are easy to recognize once you start scrolling through the main function.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 1 of 23

A quick way to deal with this was to search for all call functions inside the main. There are a lot of calls to the
function "rand" which is also part of the junk code, so these will be removed. Following the list and address of
calls to be analyzed. (Screenshot taken once analysis was complete)
Antisandbox
Five functions are implemented for anti-sandbox checking. The functions themselves are pretty basic.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 2 of 23

1. mw_AntiSandbox_NumberOfProcessors -> Checks the number of processors on the system and returns a
flag indicating whether the number is odd
2. mw_AntiSandbox_PhysicalMemSize -> Checks the system's total physical memory size and returns a flag
indicating whether the memory meets a certain threshold
3. mw_AntiSandbox_AdapterInfo ->Checks the system’s network adapters and verifies if the MAC address
matches known patterns associated with virtual machines (like VMware, VirtualBox
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 3 of 23

4. mw_AntiSandbox_Registry -> Checks registry key "SYSTEM\CurrentControlSet\Control\SystemInformation"
for the values "virtual" or Hyper-V
5. mw_AntiSandbox_Uptime -> Checks if the host has been up for certain amount of time (20 minutes)
Antidebug
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 4 of 23

Four antidebug checks are implemented.
1. mw_BeingDebugged -> Simple check on the "isBeingDebugged" field from the PEB.
2. mw_w_CheckForProcessDebugObjectHandle -> Checks the ProcessDebugObjectHandle. When
debugging begins, a kernel object called “debug object” is created. It is possible to query for the value of
this handle by using the undocumented ProcessDebugObjectHandle (0x1e) class.
3. mw_AntiDebug_ExcpetionManipulation -> if the process is running under a debugger,the exception will
be passed to the debugger regardless to if a custom exception handler is set. If the unhandled exception
filter is registered and the control is passed to it, then the process is not running with a debugger.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 5 of 23

The instruction at 0x44038d is not a nop, but infact and int 3 designed to trigger the exception. Below we can see
with simple hex editor that the opcode is CC
![[Images/int3.png]]
So if the custom exception handler is called it means no debugger is found. The instruction jmp data_4403ba is
skipped and the eax value will be 0 (0x4403ae). On the other hand eax will be 1 and jmp data_4403ba is taked.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 6 of 23

The eax value is then checked in the following function and based on the value the process will exit or continue.
4. mw_AntiDebug_CheckHardwareBP -> Checks for hardware breakpoints set in the current thread
API resolution
Some API are fetched by simply getting kernel32 pointer and calling GetProcAddress. The only issue is that once
again this code is "hidden" inside a big blob of junk code similar to what already mentioned.
1. CreateThread
2. VirtualAlloc
3. RtlMoveMemory
4. WaitForSingleObject
5. VirtualProtect
Checking for DLL hooks
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 7 of 23

The malware will attempt to remove any hooks core DLLs, by comparing the in-memory version of a loaded DLL
with its clean version mapped from disk.
Steps:
1. Obtain the DLL Path: Use GetModuleFileNameA to retrieve the binary's path
2. Open the DLL: Use CreateFileA to open the DLL file for reading.
3. Map the DLL into Memory: Use CreateFileMappingA and MapViewOfFile to load the DLL into memory
(clean, unmodified version).
4. Get the In-Memory DLL: Access the loaded DLL using GetModuleHandleA.
5. Find .text Section of the mapped version of the dll a replace the in-Memory DLL. This will remove any
EDR hooks if present in the DLL.
RansomNote #1
Following the loader will actually decrypt a ransom note, but later we will see another one also. The decryption
function used is the same for decrypting the second stage shellcode. The only difference is the key used.
I have attached the script used to perform the decryption, it needs the key and decrypted data.
I will no go through this note as it is already been analyzed by Trendmicro. ( See refrences)
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 8 of 23

Running second stage
Second stage payload is decrypted and ran through creation of a new thread. The decryption routine is the same as
above.
Once extracted the decrypted payload with the python script we can see it is indeed shellcode:
Analysis part 2 - Shellcode
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 9 of 23

Sample Information
Shellcode:
SHA256
B736491D5305F3C83D48576FD18A471D779750D67E754A8867424F60AAE99F8D
Overview
The shellcode doesn't have much functionality and can be summerized doing the following two things:
1. Resolve some API (API Hashing)
2. Reflectively load embedded DLL file and run it
The PE file can be found in the data section and is referenced by the first function of the shellcode.
Shellcode main
The entry point takes some arguments, most importantly the PE file for the next stage.
First it will resolve the API it needs, specifically it will make use of the following two API to resolve the other
ones:
1. LdrLoadDll
2. LdrGetProcedureAddress
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 10 of 23

Worth noting that these API make use of ANSI or UNICODE strings, so useful to markup based on these types.
The malware then just gets the PE from the data section and starts to parse and load it. With the goal to run the
Export DLLRegisterServer() which will start the third stage.
With correct markup it is possible to see that the malware accesses the export directory.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 11 of 23

!
Finally the export is called:
So essentially the following occurs:
1. Looks up its ordinal from AddressOfNameOrdinals
2. Using that ordinal to index into AddressOfFunctions
3. Getting the RVA of the function
4. Adding the base address to get the actual function pointer
5. Invoking that function with two arguments: a_globalDave and a_4
Analysis part 3 - DLL ransomware
Sample Information
DLL:
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 12 of 23

SHA256
BE338CA27B0C3A242A004829BFAF3CEF1AB70E8A3E2AADBA0C6B989B69A4E9D2
Overview
The third stage is the final one and contains the actual ransomware functionlity. The binary is quite large and has a
lot of functions. It is a DLL with one export: DLLRegisterServer()
The binary makes heavy use of local heap allocation to store variables so static analysis takes careful
consideration into building the right structures based on what is observed.
Also, many threads are created and so it uses TlsAlloc() to store variables and data between threads. As per MSFT
docs:
"Allocates a thread local storage (TLS) index. Any thread of the process can subsequently use this index to store
and retrieve values that are local to the thread, because each thread receives its own slot for the index"
The binary itself has been analyzed before and I will skip over anything covered already by others. (Check
references below)
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 13 of 23

DLLRegisterServer()
The initial function begins with fetching three API from the PEB:
1. GetProcAddress()
2. GetProcessHeap()
3. HeapAlloc()
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 14 of 23

All subsequent function addresses and variables are stored on the heap and saved withing the TLS to access data
from different threads. To keep track of the data in the heap a struct was built and filled out as I progresses the
sample.
One more function is called to fetch other API including some Nt ones:
InitializeCriticalSection() is used to enure mutual-exclusion synchronization betweent threads. The malware
accesses also some log files it generates.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 15 of 23

Mutex
To generate a Mutex the ransomaware uses a blob of data that is hardcoded. It fetches the 0x20 bytes of this blob
and performs some operations to decode the mutex.
Mutex: 6jSf6QFH0VGR5XL4RGYarc5YVpB4W1H3
Before creating the mutex it will check if the command line flags passed in case no mutex setting is imposed. The
mutex as with almost all data is saved inside the heap.
Json Config
The JSON config is decrypted in a similar fashion. The hardcoded blob is fetched and saved onto another heap.
Another function is then responsbile to read the JSON data back to appropriate heap to be used later.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 16 of 23

The JSON has the note and also other key fields such as the file extension to be used and process/service to be
shutdown. Also the note contents is included.
{
"RSAPubKey": "BgIAAACkAABSU0ExAAgAAAEAAQAlL7CDQokhDbQLTico8Mm0N4MjoNuLWFZu7Lqk67EUw5ZofFL3Jkkrvlec
"LockedExt": "flocked",
"NoteFileName": "readme.txt",
"PathStopList": ["tmp", "winnt", "Application Data", "AppData", "temp", "thumb", "$Recycle.Bin", "Sys
"FileMaskStopList": ["*.exe", "*.dll", "*.lnk", "*.sys", "*.CONTI"],
"ShutdownProcesses": ["notepad.exe", "calc.exe", "*sql*"],
"ShutdownServices": ["Dhcp", "Dnscache", "*sql*"]
}
If you are reading this, then you have been the victim of a cyber attack. We call ourselves Fog and we take resp
We are the ones who encrypted your data and also copied some of it to our internal resource. The sooner you cont
To contact us you need to have Tor browser installed:
1. Follow this link: xql562evsy7njcsngacphc2erzjfecwotdkobn3m4uxu2gtqh26newid.onion
2. Enter the code: 1KQOWFH2KYTLDJKX7ZTJDNMX
3. Now we can communicate safely.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 17 of 23

If you are decision-maker, you will get all the details when you get in touch. We are waiting for you.
Recon
Ransomware will also execute some shell commands to perform some basic recon: The function launches a
process with a command line passed as argument and sets up pipes to capture its stdout and stderr output. This
avoids output to the stdout of the console.
1. Creates two pipes: One to capture stdout from the child process. One to capture stderr from the child
process.
2. Sets up a STARTUPINFOA struct to redirect those outputs to the pipes.
3. Launches the process in a suspended state.
4. Resumes it if process creation was successful.
5. Returns read handles for capturing output and stores process/thread info.
Pipe creation and process setup:
Process resume and pipe redirection:
Next it needs to read the content from the PIPES, also uses GetTickCount() to check if the execution time is
longer that 6 seconds:
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 18 of 23

Finally output is logged to file:
List of Commands.
Start collect OS Info
cmd.exe /c net config Workstation
net config Workstation
cmd.exe /c systeminfo
systeminfo
cmd.exe /c hostname
hostname
cmd.exe /c net users
net users
cmd.exe /c ipconfig /all
ipconfig /all
cmd.exe /c route print
route print
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 19 of 23

cmd.exe /c arp -A
arp -A
cmd.exe /c netstat -ano
netstat -ano
cmd.exe /c netsh firewall show state
netsh firewall show state
cmd.exe /c netsh firewall show config
netsh firewall show config
cmd.exe /c schtasks /query /fo LIST /v
schtasks /query /fo LIST /v
cmd.exe /c tasklist /SVC
tasklist /SVC
cmd.exe /c net start
net start
cmd.exe /c DRIVERQUERY
DRIVERQUERY
Enumeration of Volumes
This section is nothing special and uses common API to enumerate volumes.
Stop Services/Process
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 20 of 23

The first function attempts to stop all active Windows services that match what is in the JSON.It uses Windows
Service Control Manager (SCM) APIs to enumerate and control services.
1. Opens a handle to the Service Control Manager (SCM).
2. Enumerates all active WIN32 services.
3. Iterates through each service and Compares service names against JSON values.
4. If there's a match, tries to stop the service using ControlService (SERVICE_CONTROL_STOP)
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 21 of 23

The second function basically works very much the same way but using CreateToolhelp32Snapshot &
Process32Next to find the target process.
Delete Shadow Copies
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 22 of 23

Of course the ShadowCopies are also deleted as is common with ransomware.
Encryption
The ransomware has many different paths to perform the final encryption of the files and uses CreateThread()
quite a lot as the application as mentioned is multi-threaded. Below I will showcase just some of the encryption
functions without too much detail.
Below screen shows on the left where the main function for encryption is used:
Encryption function:
References
https://www.trendmicro.com/en_be/research/25/d/fog-ransomware-concealed-within-binary-loaders-linking-themselve.html
https://anti-debug.checkpoint.com/techniques/exceptions.html#unhandledexceptionfilter
https://areteir.com/article/malware-spotlight-fog-ransomware-technical-analysis/
Source: https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md
Page 23 of 23

![[Images/int3.png]] So if the custom exception handler is called it means no debugger is found. The instruction jmp data_4403ba is
skipped and the eax value will be 0 (0x4403ae). On the other hand eax will be 1 and jmp data_4403ba is taked.
   Page 6 of 23