{ "id": "c730d878-2bc0-4733-874d-c6e2af2dd1bd", "created_at": "2026-04-06T00:17:55.098889Z", "updated_at": "2026-04-10T03:23:51.436269Z", "deleted_at": null, "sha1_hash": "c4893b78d12dbb94b9d3fa415a9ce701fb0d75a3", "title": "Virus Bulletin :: Compromised library", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 650800, "plain_text": "Virus Bulletin :: Compromised library\r\nBy Raul AlvarezFortinet, CanadaEditor: Helen Martin\r\nArchived: 2026-04-05 22:23:11 UTC\r\n2012-12-03\r\nAbstract\r\nThe Floxif DLL file infector implements both anti‑static- and anti-dynamic-analysis techniques. Raul Alvarez\r\ndescribes how.\r\nCopyright © 2012 Virus Bulletin\r\nTable of contents\r\nIn the October issue of Virus Bulletin [1] I wrote about the Quervar file infector, which infects .EXE, .DOC,\r\n.DOCX, .XLS and .XLSX files. We have seen hundreds of file infectors that can infect executable files, and we\r\nalso have seen document-infecting malware. However, Quevar infects document files not because they are\r\ndocuments, but because they have the extension used by document files – if you rename any file with ‘.DOC’ or\r\n‘.XLS’ as the first three letters of the extension name, chances are, they would be infected.\r\nJust a few weeks after Quervar, we discovered a file infector whose main target is DLL files. The malware code is\r\nnot highly encrypted, but it has some interesting sophistication. This article focuses on the DLL file infector\r\ndubbed Floxif/Pioneer. We will uncover how it implements both anti-static- and anti-dynamic-analysis techniques.\r\nExecuting an infected DLL\r\nOnce an infected DLL is loaded into memory, a jump instruction at the entry point of the file will lead to the\r\nmalware body. This instruction is a five-byte piece of code that is added by Floxif every time it infects a DLL. The\r\noriginal five bytes of the host file are stored somewhere in the virus body.\r\nFloxif starts by getting the imagebase of kernel32.dll by parsing the Process Environment Block (PEB). Once the\r\nimagebase is established, it starts parsing the exported API names of kernel32.dll, searching for ‘GetProcAddress’\r\nand eventually getting the equivalent address for this API.\r\nOnce the GetProcAddress API has been found, it starts getting the API addresses of GetProcessHeap,\r\nGetModuleFileNameA, GetSystemDirectoryA, GetTempPathA, CloseHandle, CreateFileA, GetFileSize,\r\nReadFile, VirtualProtect, LoadLibraryA and WriteFile.\r\nEvery time an API (from the list mentioned above) is needed, the virus gets its equivalent address and executes it.\r\nThe following is a summary of the execution:\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 1 of 7\n\nFloxif reserves a memory space, opens the original DLL file and loads it in a newly created space. It starts\r\ndecrypting part of the virus code from the newly loaded DLL file in memory, revealing the contents of the UPX\r\nversion of symsrv.dll, which will be dropped later. (Symsrv.dll plays an important role in the overall infection\r\nprocess.) The decryptor is a simple combination of XOR 0x2A and NOT instructions.\r\nAfter decrypting the content of the symsrv.dll file, it also decrypts the strings (‘C:\\Program Files\\Common\r\nFiles\\System\\symsrv.dll’) where the file will be dropped. After dropping symsrv.dll, Floxif will load it as one of\r\nthe modules of the infected DLL file in memory using the LoadLibraryA API. (It is interesting to note that the\r\ncontent of symsrv.dll is already accessible by Floxif, but it still reloads symsrv.dll as a module.)\r\nActing as a module, Floxif can use the exported functions of symsrv.dll as some sort of API. Two exported APIs\r\nare contained in symsrv.dll, namely: FloodFix and crc32. The virus gets its name from the FloodFix API. (The\r\ncrc32 API is a continuous loop to a call to a sleep function with a one-minute interval.)\r\nOnce the symsrv.dll module is properly loaded into the host DLL, the virus will execute the FloodFix API. Let’s\r\ntake a closer look at what this API does.\r\nFirst, it changes the protection of the memory used by the host DLL between the start of the PE header and before\r\nthe section header, to PAGE_EXECUTE_READWRITE. Then, it restores the virtual address and the size of the\r\nbase relocation table. Afterwards, it resets the protection of the same memory area to PAGE_READONLY.\r\nNext, it changes the protection of the whole .text section to PAGE_EXECUTE_READWRITE and restores 3,513\r\nbytes of code. Then, it resets the protection to PAGE_EXECUTE_READ. Afterwards, it restores the original five-byte code to the host DLL entry point.\r\nFinally, jumping to the entry point of the host DLL file, it executes the original file.\r\nThe main function of the FloodFix API is to restore the host DLL in its original form in memory and to execute\r\nthe host DLL, starting at its entry point, while the virus runs in the background.\r\nAnti-static-analysis trick\r\nBefore we go any further, let’s look into Floxif’s anti-static-analysis trick. If the malware code is not encrypted, or\r\nbinary dumped from the decrypted code, we can quickly take a look at its functionality using static analysis. In the\r\ncase of Floxif, it looks as if the code is corrupted, because a disassembler can’t render it properly. Figure 1 shows\r\nwhat the virus code looks like if we are just browsing it.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 2 of 7\n\nFigure 1. Browsing the virus code.\r\nThe lines of code highlighted in the figure are not junk code or corrupted data. The disassembler/debugger can’t\r\ndisassemble the code properly because an ‘EXTRA’ byte has been added after the RETN instruction. By default,\r\nthe disassembler will re-interpret the code after the RETN as a new function, and it will look like junk/corrupted\r\ncode.\r\nThe call to the Reroute function leads to another call, this time to the Reroute2 function. Using static analysis, a\r\ndisassembler won’t be able to follow the RETN 8 instruction. We can assume that it will jump back to the caller,\r\nhence we will just end up at the first call.\r\nUsing a debugger, following the RETN 8 instruction from the Reroute2 function will lead to another routine,\r\nwhich in turn will jump to another location – but instead of jumping to the location straight after the RETN, the\r\nnew location is just after the extra byte.\r\nFigure 2 shows the disassembler’s attempt to interpret the code after the RETN following the first CALL\r\ninstruction, and the equivalent code once the proper jump has been established.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 3 of 7\n\nFigure 2. Disassembler’s attempt to interpret code after the RETN, and equivalent code once the proper\r\njump has been established.\r\nThe byte (FF) at address 100046A2 was added to disorient the disassembler. To emphasize the point, modifying\r\nthe byte FF to 90 (NOP instruction) will yield the proper representation of the code which the CALL\r\n\u003csymsrv.__Reroute__\u003e will be jumping into.\r\nThis anti-static-analysis trick is an attempt to force the analyst to perform dynamic analysis using a debugger.\r\nAnti-dynamic-analysis trick\r\nOnce we have decided that dynamic analysis is the better alternative, Floxif has another surprise.\r\nThe FloodFix API found at symsrv.dll doesn’t do anything other than restoring the host DLL and its entry point.\r\nSome dynamic analysis approaches involve modifying the instruction pointer (EIP) to start at some interesting\r\npart of the code, assuming that the data and code are properly configured.\r\nFloxif is aware of this method. To implement an anti-dynamic-analysis trick, Floxif hooks the\r\nKiUserExceptionDispatcher API of ntdll.dll. Any attempt to change the EIP to anywhere within symsrv.dll might\r\nresult in the error message shown in Figure 3. Also shown in Figure 3 is the hook calling the address 10001220,\r\nwhich contains the function that displays an error message. After displaying the message box, the virus will\r\nterminate its execution.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 4 of 7\n\nFigure 3. Hook calling the address 10001220, which contains the function that displays an error message.\r\nThis anti-dynamic-analysis trick is easy to overlook because the error message resembles a valid error message\r\nfrom the operating system.\r\nNow, the infection routine\r\nWe know that the infection routine is not triggered in FloodFix or in the crc32 API. The infection routine is\r\ntriggered once symsrv.dll is loaded into the memory space of the infected DLL file, using a call to the LoadLibrary\r\nAPI.\r\nThereby, the virus is already infecting the system in the background while the FloodFix API is being called.\r\nLet’s take a look at what happens behind the scenes:\r\nFloxif adjusts the privilege of the access token to enable it to hook the KiUserExceptionDispatcher API from\r\nntdll.dll. The KiUserExceptionDispatcher API is used for some sort of anti-dynamic-analysis, as discussed earlier.\r\nTo hook the API, it gets its virtual address by loading ntdll.dll using LoadLibraryA, then using GetProcAddress to\r\nget the API’s address.\r\nOnce the address of the KiUserExceptionDispatcher API has been acquired, the virus parses the API code looking\r\nfor a jump instruction. Once found, it saves the original jump location and overwrites it with a relative value that\r\nwill enable it to jump to 10001220 (Figure 3 shows the hooked location).\r\nAfter hooking the KiUserExceptionDispatcher API, the virus creates a mutex named ‘Global\\SYS_E0A9138’ (see\r\nFigure 4), which is initially encrypted using a NOT instruction.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 5 of 7\n\nFigure 4. The virus creates a mutex.\r\nAfter creating the mutex, it stores the names of the %system%, %windows% and %temp% folders using the\r\nGetSystemDirectoryA, GetWindowsDirectoryA and GetTempPathA APIs, respectively. Floxif avoids infecting\r\nfiles found in these folders.\r\nNext, it starts enumerating the modules for each process running in the system. Floxif does this by getting the\r\nprocess list using a combination of the CreateToolhelp32Snapshot, Process32First and Process32Next APIs. It\r\ngets the module list from each process by using a combination of the CreateToolhelp32Snapshot, Module32First\r\nand Module32Next APIs.\r\nEach module’s path is checked against the three folders whose names were stored earlier: %system%,\r\n%windows%, and %temp%. Provided the module is not located in any of the three folders mentioned, the virus\r\nwill read the file to memory and infect it. Then, it renames the original DLL file from \u003cfilename.DLL\u003e to\r\n‘\u003cfilename.DLL\u003e.DAT’. Floxif then creates a new file with the infected version, which it names \u003cfilename.DLL\u003e\r\n(i.e. the same as the original).\r\nIt will delete \u003cfilename.DLL.DAT\u003e the next time the system is restarted by using the MoveFileExA API with the\r\nparameter NewName=NULL Flags=DELAY_UNTIL_REBOOT.\r\nThen, the conclusion\r\nAnti-static- and anti-dynamic-analysis techniques are not new. We encounter them on a regular, if not daily basis.\r\nThere are even more sophisticated techniques than these, but we seldom see them being discussed. It is interesting\r\nto see a piece of malware that infects DLL files employing anti-analysis techniques. It is possible that I have\r\nmissed other techniques that are deployed by the malware, such as anti-debugging, anti-emulation, or anti-anything-else.\r\nWhat seems certain is that we are likely to see more of both Quervar and Floxif messing our files around.\r\nBibliography\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 6 of 7\n\nSource: https://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nhttps://www.virusbulletin.com/virusbulletin/2012/12/compromised-library\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.virusbulletin.com/virusbulletin/2012/12/compromised-library" ], "report_names": [ "compromised-library" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434675, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c4893b78d12dbb94b9d3fa415a9ce701fb0d75a3.pdf", "text": "https://archive.orkl.eu/c4893b78d12dbb94b9d3fa415a9ce701fb0d75a3.txt", "img": "https://archive.orkl.eu/c4893b78d12dbb94b9d3fa415a9ce701fb0d75a3.jpg" } }