{ "id": "42ce812e-4e55-4fa0-8b99-f8910eb92e4d", "created_at": "2026-04-06T00:07:10.833881Z", "updated_at": "2026-04-10T03:20:52.312414Z", "deleted_at": null, "sha1_hash": "32e71f489c35f56c047a24fe2f05440eefee256a", "title": "Deep Malware and Phishing Analysis - Nymaim", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 174303, "plain_text": "Deep Malware and Phishing Analysis - Nymaim\r\nBy Joe Security LLC\r\nArchived: 2026-04-05 18:18:08 UTC\r\nRecently we were investigating interesting piece of malware that was generating quite huge workload in the\r\nsandboxed environment. To introduce proper countermeasures we had to fully reverse it. It turned out that the file\r\nbelongs to the Nymaim family, which is active at least since 2013 [1]. This particular file consists of few layers,\r\nfirst one is meant to slowdown / timeout various sandboxes / replicators / emulators, the last layer hinders static\r\nanalysis and debugging, layers in the middle are just responsible for decompression and decryption.\r\nThere are many different methods of introducing slowdowns in sandboxed environments, some of them are more\r\neffective some of them are not effective at all. Nymaim uses Win32 API hammering, which means that it\r\nconstantly calls benign Win32 API functions in the loop. It's clearly visible on the WinMain function graph (glued\r\nside by side, since the function is way too big):\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 1 of 6\n\nReaders familiar with IDA function graphs should notice unusual length of the code.There is a lot of loops and a\r\nlot of various API calls:\r\nAPI Name Number of calls\r\nKERNEL32.dll.GetLastError 49739\r\nUSER32.dll.GetDlgItem 34446\r\nKERNEL32.dll.TlsGetValue 34434\r\nKERNEL32.dll.SetLastError 34434\r\ndbghelp.dll.SymCleanup 30608\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 2 of 6\n\nAPI Name Number of calls\r\nUSER32.dll.ShowWindow 30608\r\nKERNEL32.dll.GetCurrentProcess 30608\r\nKERNEL32.dll.LeaveCriticalSection 15306\r\nKERNEL32.dll.EnterCriticalSection 15306\r\nKERNEL32.dll.CloseHandle 15305\r\nUSER32.dll.FindWindowExA 15304\r\nGDI32.dll.MoveToEx 15304\r\nUSER32.dll.GetClassNameA 15304\r\nPSAPI.DLL.GetPerformanceInfo 15304\r\nUSER32.dll.SetWindowPlacement 15304\r\nKERNEL32.dll.GlobalMemoryStatusEx 15304\r\nUSER32.dll.PostMessageA 15304\r\nPSAPI.DLL.EnumProcesses 15304\r\nKERNEL32.dll.GetVersionExA 15304\r\ndbghelp.dll.SymInitialize 15304\r\nACTIVEDS.dll.ord_9 15304\r\ndbghelp.dll.SymEnumSymbols 15304\r\nGDI32.dll.Rectangle 15304\r\nUSER32.dll.GetWindowPlacement 15304\r\ndbghelp.dll.SymLoadModuleEx 15304\r\nADVAPI32.dll.OpenProcessToken 15304\r\nUSER32.dll.EnumDisplaySettingsA 7652\r\nUSER32.dll.SendDlgItemMessageA 7652\r\nOLEAUT32.dll.ord_4 7652\r\nUSER32.dll.GetDC 3839\r\nKERNEL32.dll.GetProcAddress 3828\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 3 of 6\n\nAPI Name Number of calls\r\nKERNEL32.dll.lstrlenA 3828\r\nKERNEL32.dll.GetModuleHandleA 3827\r\nKERNEL32.dll.WideCharToMultiByte 3826\r\nGDI32.dll.ChoosePixelFormat 3826\r\nOLEAUT32.dll.ord_8 3826\r\nKERNEL32.dll.MultiByteToWideChar 3826\r\nGDI32.dll.SetPixelFormat 3826\r\nOPENGL32.dll.wglCreateContext 3826\r\nWithout any monitoring tools, execution of WinMain takes around 46 seconds. Now if any of the above APIs\r\ntriggers some event that is (or should be) monitored in the sandboxed environment you can imagine what would\r\nhappen to those 46 seconds. So far we have not seen any sandbox able to analyze the malware successfully.\r\nDuring the analysis we were able to identify one unwelcome side effect of the\r\nUSER32.dll.EnumDisplaySettingsA function call, namely it loads and unloads the vga.dll kernel library during\r\nthe call:\r\nChildEBP RetAddr\r\n890136f8 828563ef nt!DbgLoadImageSymbols+0x47\r\n89013714 82a05b21 nt!DbgLoadImageSymbolsUnicode+0x23\r\n89013750 82a02531 nt!MiDriverLoadSucceeded+0x183\r\n890137d0 82a8ccf8 nt!MmLoadSystemImage+0x720\r\n8901391c 8287a8c6 nt!NtSetSystemInformation+0x967\r\n8901391c 82879969 nt!KiSystemServicePostCall\r\n890139a0 907a895a nt!ZwSetSystemInformation+0x11\r\n89013b1c 907a858b win32k!ldevLoadImage+0x215\r\n89013b54 907a2b9a win32k!ldevLoadDriver+0x78\r\n89013b70 907aaec4 win32k!ldevGetDriverModes+0x1c\r\n89013b9c 90806eb6 win32k!DrvBuildDevmodeList+0x134\r\n89013bfc 90806aea win32k!DrvEnumDisplaySettings+0x3b9\r\n89013c1c 8287a8c6 win32k!NtUserEnumDisplaySettings+0x27\r\n89013c1c 772270f4 nt!KiSystemServicePostCall\r\n001241d0 762f13c4 ntdll!KiFastSystemCallRet\r\n001241d4 763065c1 USER32!NtUserEnumDisplaySettings+0xc\r\n00124214 76306502 USER32!EnumDisplaySettingsExA+0xbc\r\n0012422c 004023d4 USER32!EnumDisplaySettingsA+0x23\r\n0012fef8 0040698f 885+0x23d4\r\n0012ff88 760eee1c 885+0x698f\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 4 of 6\n\n0012ff94 772437eb kernel32!BaseThreadInitThunk+0xe\r\n0012ffd4 772437be ntdll!__RtlUserThreadStart+0x70\r\n0012ffec 00000000 ntdll!_RtlUserThreadStart+0x1b\r\nThis of course triggers driver analysis (in case the sandbox offers it)... 7652 times and the only thing that separates\r\ngood analysis and total failure is a proper filtering of collected data.\r\nSecond stage of the malware is executed through the callback from EnumResourceTypesA, it decompress and\r\ndecrypts the final stage, which is heavily obfuscated. Entry point of the final stage suggests that it can be run from\r\nwithin both x86 and x64 processes. It uses simple trick to detect bitness of the process [2] and it contains both x86\r\nand x64 payloads.\r\nAfter deobfuscation we were able to identify another simple check to evade analysis, mentioned sample uses\r\nGetSystemTime API to verify expiration date, and does not execute after 8th of April 2016. We can easily handle\r\nsuch cases in Joe Sandbox through our Cookbooks system [3], whole operation boils down to adding below line to\r\nthe Cookbook:\r\n_SetDate(06, 04, 2016)\r\nIt's always good to re-run the analysis with the different dates to verify if the sample doesn't expire or if it isn't\r\nactivating in the near future. Usually it's safe to assume the day when the sample was received as the initial date,\r\ntimestamp from the PE header should work as well (in this case it is GMT Tue Apr 05 22:31:47 2016).\r\nLast but not least, link to the full Joe Sandbox report (click the picture to open):\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 5 of 6\n\nNymaim proves that it is very important to have a flexible malware analysis system which enables analysts to\r\neasily change settings on the analysis machine. Joe Sandbox features an extensive technology called cookbooks.\r\nCookbooks enable to completely define the analysis and allow to change OS settings, simulate user behavior and\r\nmore. Further Joe Sandbox analyzes malware on physical machines (bare metal) defeating any VM evasions.\r\nReferences:\r\n[1] http://www.welivesecurity.com/2013/08/26/nymaim-obfuscation-chronicles/\r\n[2] http://www.ragestorm.net/blogs/?p=376\r\n[3] https://www.joesecurity.org/joe-sandbox-technology#cookbooks\r\nSource: https://www.joesecurity.org/blog/3660886847485093803\r\nhttps://www.joesecurity.org/blog/3660886847485093803\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.joesecurity.org/blog/3660886847485093803" ], "report_names": [ "3660886847485093803" ], "threat_actors": [], "ts_created_at": 1775434030, "ts_updated_at": 1775791252, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/32e71f489c35f56c047a24fe2f05440eefee256a.pdf", "text": "https://archive.orkl.eu/32e71f489c35f56c047a24fe2f05440eefee256a.txt", "img": "https://archive.orkl.eu/32e71f489c35f56c047a24fe2f05440eefee256a.jpg" } }