{
	"id": "5529f486-86af-46f2-a621-b3126f28447c",
	"created_at": "2026-04-06T00:12:44.619955Z",
	"updated_at": "2026-04-10T03:21:21.298819Z",
	"deleted_at": null,
	"sha1_hash": "6dc07c5b992c82cd8ca2a0d657d0c9b57136d03e",
	"title": "MalwareAnalysisReports/Fog Ransomaware/Fog Ransomware.md at main · VenzoV/MalwareAnalysisReports",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1200205,
	"plain_text": "MalwareAnalysisReports/Fog Ransomaware/Fog Ransomware.md\r\nat main · VenzoV/MalwareAnalysisReports\r\nBy VenzoV\r\nArchived: 2026-04-05 22:48:53 UTC\r\nSample Information\r\nLoader:\r\nSHA256\r\n8E209E4F7F10CA6DEF27EABF31ECC0DBB809643FEAECB8E52C2F194DAA0511AA\r\nAnalysis part 1- Loader\r\nOverview\r\nJunk code\r\nFirst think to notice and be aware is that the malware employs a lot of junk code to bloat the main function. It is\r\nhard 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\r\nvery large useless switch statements that are easy to recognize once you start scrolling through the main function.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 1 of 23\n\nA quick way to deal with this was to search for all call functions inside the main. There are a lot of calls to the\r\nfunction \"rand\" which is also part of the junk code, so these will be removed. Following the list and address of\r\ncalls to be analyzed. (Screenshot taken once analysis was complete)\r\nAntisandbox\r\nFive functions are implemented for anti-sandbox checking. The functions themselves are pretty basic.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 2 of 23\n\n1. mw_AntiSandbox_NumberOfProcessors -\u003e Checks the number of processors on the system and returns a\r\nflag indicating whether the number is odd\r\n2. mw_AntiSandbox_PhysicalMemSize -\u003e Checks the system's total physical memory size and returns a flag\r\nindicating whether the memory meets a certain threshold\r\n3. mw_AntiSandbox_AdapterInfo -\u003eChecks the system’s network adapters and verifies if the MAC address\r\nmatches known patterns associated with virtual machines (like VMware, VirtualBox\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 3 of 23\n\n4. mw_AntiSandbox_Registry -\u003e Checks registry key \"SYSTEM\\CurrentControlSet\\Control\\SystemInformation\"\r\nfor the values \"virtual\" or Hyper-V\r\n5. mw_AntiSandbox_Uptime -\u003e Checks if the host has been up for certain amount of time (20 minutes)\r\nAntidebug\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 4 of 23\n\nFour antidebug checks are implemented.\r\n1. mw_BeingDebugged -\u003e Simple check on the \"isBeingDebugged\" field from the PEB.\r\n2. mw_w_CheckForProcessDebugObjectHandle -\u003e Checks the ProcessDebugObjectHandle. When\r\ndebugging begins, a kernel object called “debug object” is created. It is possible to query for the value of\r\nthis handle by using the undocumented ProcessDebugObjectHandle (0x1e) class.\r\n3. mw_AntiDebug_ExcpetionManipulation -\u003e if the process is running under a debugger,the exception will\r\nbe passed to the debugger regardless to if a custom exception handler is set. If the unhandled exception\r\nfilter is registered and the control is passed to it, then the process is not running with a debugger.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 5 of 23\n\nThe instruction at 0x44038d is not a nop, but infact and int 3 designed to trigger the exception. Below we can see\r\nwith simple hex editor that the opcode is CC\r\n![[Images/int3.png]]\r\nSo if the custom exception handler is called it means no debugger is found. The instruction jmp data_4403ba is\r\nskipped and the eax value will be 0 (0x4403ae). On the other hand eax will be 1 and jmp data_4403ba is taked.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 6 of 23\n\nThe eax value is then checked in the following function and based on the value the process will exit or continue.\r\n4. mw_AntiDebug_CheckHardwareBP -\u003e Checks for hardware breakpoints set in the current thread\r\nAPI resolution\r\nSome API are fetched by simply getting kernel32 pointer and calling GetProcAddress. The only issue is that once\r\nagain this code is \"hidden\" inside a big blob of junk code similar to what already mentioned.\r\n1. CreateThread\r\n2. VirtualAlloc\r\n3. RtlMoveMemory\r\n4. WaitForSingleObject\r\n5. VirtualProtect\r\nChecking for DLL hooks\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 7 of 23\n\nThe malware will attempt to remove any hooks core DLLs, by comparing the in-memory version of a loaded DLL\r\nwith its clean version mapped from disk.\r\nSteps:\r\n1. Obtain the DLL Path: Use GetModuleFileNameA to retrieve the binary's path\r\n2. Open the DLL: Use CreateFileA to open the DLL file for reading.\r\n3. Map the DLL into Memory: Use CreateFileMappingA and MapViewOfFile to load the DLL into memory\r\n(clean, unmodified version).\r\n4. Get the In-Memory DLL: Access the loaded DLL using GetModuleHandleA.\r\n5. Find .text Section of the mapped version of the dll a replace the in-Memory DLL. This will remove any\r\nEDR hooks if present in the DLL.\r\nRansomNote #1\r\nFollowing the loader will actually decrypt a ransom note, but later we will see another one also. The decryption\r\nfunction used is the same for decrypting the second stage shellcode. The only difference is the key used.\r\nI have attached the script used to perform the decryption, it needs the key and decrypted data.\r\nI will no go through this note as it is already been analyzed by Trendmicro. ( See refrences)\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 8 of 23\n\nRunning second stage\r\nSecond stage payload is decrypted and ran through creation of a new thread. The decryption routine is the same as\r\nabove.\r\nOnce extracted the decrypted payload with the python script we can see it is indeed shellcode:\r\nAnalysis part 2 - Shellcode\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 9 of 23\n\nSample Information\r\nShellcode:\r\nSHA256\r\nB736491D5305F3C83D48576FD18A471D779750D67E754A8867424F60AAE99F8D\r\nOverview\r\nThe shellcode doesn't have much functionality and can be summerized doing the following two things:\r\n1. Resolve some API (API Hashing)\r\n2. Reflectively load embedded DLL file and run it\r\nThe PE file can be found in the data section and is referenced by the first function of the shellcode.\r\nShellcode main\r\nThe entry point takes some arguments, most importantly the PE file for the next stage.\r\nFirst it will resolve the API it needs, specifically it will make use of the following two API to resolve the other\r\nones:\r\n1. LdrLoadDll\r\n2. LdrGetProcedureAddress\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 10 of 23\n\nWorth noting that these API make use of ANSI or UNICODE strings, so useful to markup based on these types.\r\nThe malware then just gets the PE from the data section and starts to parse and load it. With the goal to run the\r\nExport DLLRegisterServer() which will start the third stage.\r\nWith correct markup it is possible to see that the malware accesses the export directory.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 11 of 23\n\n!\r\nFinally the export is called:\r\nSo essentially the following occurs:\r\n1. Looks up its ordinal from AddressOfNameOrdinals\r\n2. Using that ordinal to index into AddressOfFunctions\r\n3. Getting the RVA of the function\r\n4. Adding the base address to get the actual function pointer\r\n5. Invoking that function with two arguments: a_globalDave and a_4\r\nAnalysis part 3 - DLL ransomware\r\nSample Information\r\nDLL:\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 12 of 23\n\nSHA256\r\nBE338CA27B0C3A242A004829BFAF3CEF1AB70E8A3E2AADBA0C6B989B69A4E9D2\r\nOverview\r\nThe third stage is the final one and contains the actual ransomware functionlity. The binary is quite large and has a\r\nlot of functions. It is a DLL with one export: DLLRegisterServer()\r\nThe binary makes heavy use of local heap allocation to store variables so static analysis takes careful\r\nconsideration into building the right structures based on what is observed.\r\nAlso, many threads are created and so it uses TlsAlloc() to store variables and data between threads. As per MSFT\r\ndocs:\r\n\"Allocates a thread local storage (TLS) index. Any thread of the process can subsequently use this index to store\r\nand retrieve values that are local to the thread, because each thread receives its own slot for the index\"\r\nThe binary itself has been analyzed before and I will skip over anything covered already by others. (Check\r\nreferences below)\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 13 of 23\n\nDLLRegisterServer()\r\nThe initial function begins with fetching three API from the PEB:\r\n1. GetProcAddress()\r\n2. GetProcessHeap()\r\n3. HeapAlloc()\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 14 of 23\n\nAll subsequent function addresses and variables are stored on the heap and saved withing the TLS to access data\r\nfrom different threads. To keep track of the data in the heap a struct was built and filled out as I progresses the\r\nsample.\r\nOne more function is called to fetch other API including some Nt ones:\r\nInitializeCriticalSection() is used to enure mutual-exclusion synchronization betweent threads. The malware\r\naccesses also some log files it generates.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 15 of 23\n\nMutex\r\nTo generate a Mutex the ransomaware uses a blob of data that is hardcoded. It fetches the 0x20 bytes of this blob\r\nand performs some operations to decode the mutex.\r\nMutex: 6jSf6QFH0VGR5XL4RGYarc5YVpB4W1H3\r\nBefore creating the mutex it will check if the command line flags passed in case no mutex setting is imposed. The\r\nmutex as with almost all data is saved inside the heap.\r\nJson Config\r\nThe JSON config is decrypted in a similar fashion. The hardcoded blob is fetched and saved onto another heap.\r\nAnother function is then responsbile to read the JSON data back to appropriate heap to be used later.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 16 of 23\n\nThe JSON has the note and also other key fields such as the file extension to be used and process/service to be\r\nshutdown. Also the note contents is included.\r\n{\r\n\"RSAPubKey\": \"BgIAAACkAABSU0ExAAgAAAEAAQAlL7CDQokhDbQLTico8Mm0N4MjoNuLWFZu7Lqk67EUw5ZofFL3Jkkrvlec\r\n\"LockedExt\": \"flocked\",\r\n\"NoteFileName\": \"readme.txt\",\r\n\"PathStopList\": [\"tmp\", \"winnt\", \"Application Data\", \"AppData\", \"temp\", \"thumb\", \"$Recycle.Bin\", \"Sys\r\n\"FileMaskStopList\": [\"*.exe\", \"*.dll\", \"*.lnk\", \"*.sys\", \"*.CONTI\"],\r\n\"ShutdownProcesses\": [\"notepad.exe\", \"calc.exe\", \"*sql*\"],\r\n\"ShutdownServices\": [\"Dhcp\", \"Dnscache\", \"*sql*\"]\r\n}\r\nIf you are reading this, then you have been the victim of a cyber attack. We call ourselves Fog and we take resp\r\nWe are the ones who encrypted your data and also copied some of it to our internal resource. The sooner you cont\r\nTo contact us you need to have Tor browser installed:\r\n1. Follow this link: xql562evsy7njcsngacphc2erzjfecwotdkobn3m4uxu2gtqh26newid.onion\r\n2. Enter the code: 1KQOWFH2KYTLDJKX7ZTJDNMX\r\n3. Now we can communicate safely.\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 17 of 23\n\nIf you are decision-maker, you will get all the details when you get in touch. We are waiting for you.\r\nRecon\r\nRansomware will also execute some shell commands to perform some basic recon: The function launches a\r\nprocess with a command line passed as argument and sets up pipes to capture its stdout and stderr output. This\r\navoids output to the stdout of the console.\r\n1. Creates two pipes: One to capture stdout from the child process. One to capture stderr from the child\r\nprocess.\r\n2. Sets up a STARTUPINFOA struct to redirect those outputs to the pipes.\r\n3. Launches the process in a suspended state.\r\n4. Resumes it if process creation was successful.\r\n5. Returns read handles for capturing output and stores process/thread info.\r\nPipe creation and process setup:\r\nProcess resume and pipe redirection:\r\nNext it needs to read the content from the PIPES, also uses GetTickCount() to check if the execution time is\r\nlonger that 6 seconds:\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 18 of 23\n\nFinally output is logged to file:\r\nList of Commands.\r\nStart collect OS Info\r\ncmd.exe /c net config Workstation\r\nnet config Workstation\r\ncmd.exe /c systeminfo\r\nsysteminfo\r\ncmd.exe /c hostname\r\nhostname\r\ncmd.exe /c net users\r\nnet users\r\ncmd.exe /c ipconfig /all\r\nipconfig /all\r\ncmd.exe /c route print\r\nroute print\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 19 of 23\n\ncmd.exe /c arp -A\r\narp -A\r\ncmd.exe /c netstat -ano\r\nnetstat -ano\r\ncmd.exe /c netsh firewall show state\r\nnetsh firewall show state\r\ncmd.exe /c netsh firewall show config\r\nnetsh firewall show config\r\ncmd.exe /c schtasks /query /fo LIST /v\r\nschtasks /query /fo LIST /v\r\ncmd.exe /c tasklist /SVC\r\ntasklist /SVC\r\ncmd.exe /c net start\r\nnet start\r\ncmd.exe /c DRIVERQUERY\r\nDRIVERQUERY\r\nEnumeration of Volumes\r\nThis section is nothing special and uses common API to enumerate volumes.\r\nStop Services/Process\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 20 of 23\n\nThe first function attempts to stop all active Windows services that match what is in the JSON.It uses Windows\r\nService Control Manager (SCM) APIs to enumerate and control services.\r\n1. Opens a handle to the Service Control Manager (SCM).\r\n2. Enumerates all active WIN32 services.\r\n3. Iterates through each service and Compares service names against JSON values.\r\n4. If there's a match, tries to stop the service using ControlService (SERVICE_CONTROL_STOP)\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 21 of 23\n\nThe second function basically works very much the same way but using CreateToolhelp32Snapshot \u0026\r\nProcess32Next to find the target process.\r\nDelete Shadow Copies\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 22 of 23\n\nOf course the ShadowCopies are also deleted as is common with ransomware.\r\nEncryption\r\nThe ransomware has many different paths to perform the final encryption of the files and uses CreateThread()\r\nquite a lot as the application as mentioned is multi-threaded. Below I will showcase just some of the encryption\r\nfunctions without too much detail.\r\nBelow screen shows on the left where the main function for encryption is used:\r\nEncryption function:\r\nReferences\r\nhttps://www.trendmicro.com/en_be/research/25/d/fog-ransomware-concealed-within-binary-loaders-linking-themselve.html\r\nhttps://anti-debug.checkpoint.com/techniques/exceptions.html#unhandledexceptionfilter\r\nhttps://areteir.com/article/malware-spotlight-fog-ransomware-technical-analysis/\r\nSource: https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nhttps://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md\r\nPage 23 of 23\n\n![[Images/int3.png]] So if the custom exception handler is called it means no debugger is found. The instruction jmp data_4403ba is\nskipped and the eax value will be 0 (0x4403ae). On the other hand eax will be 1 and jmp data_4403ba is taked.\n   Page 6 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://github.com/VenzoV/MalwareAnalysisReports/blob/main/Fog%20Ransomaware/Fog%20Ransomware.md"
	],
	"report_names": [
		"Fog%20Ransomware.md"
	],
	"threat_actors": [],
	"ts_created_at": 1775434364,
	"ts_updated_at": 1775791281,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6dc07c5b992c82cd8ca2a0d657d0c9b57136d03e.pdf",
		"text": "https://archive.orkl.eu/6dc07c5b992c82cd8ca2a0d657d0c9b57136d03e.txt",
		"img": "https://archive.orkl.eu/6dc07c5b992c82cd8ca2a0d657d0c9b57136d03e.jpg"
	}
}