{
	"id": "8aa72b50-a862-4c4f-b2f3-5b9e2e67ed03",
	"created_at": "2026-04-06T00:06:14.394925Z",
	"updated_at": "2026-04-10T03:20:27.628655Z",
	"deleted_at": null,
	"sha1_hash": "14f6c64b4e49a2be86eaae5c87a01f18eca8ddc9",
	"title": "BackSwap Banker Malware Hides Inside Replicas of Legitimate Programs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 67559,
	"plain_text": "BackSwap Banker Malware Hides Inside Replicas of Legitimate\r\nPrograms\r\nBy sharon\r\nPublished: 2018-08-06 · Archived: 2026-04-05 14:56:07 UTC\r\nThis post will focus on a deep dive analysis of how the BackSwap banker malware hides its malicious code inside\r\nreplicas of popular, legitimate computer programs. The Cyberbit Malware Research team analyzed four samples\r\nof this banking malware. The fourth sample is a new variant that has not been previously analyzed and was found\r\nto contain an interesting method for decrypting its code during runtime.\r\nThe recent research on BackSwap banker published by ESET and CERT.PL, uncovered BackSwap was using a\r\ntechnique that hooks the Windows message loop events to look for banking activity, instead of injecting code\r\ndirectly into the browser’s process.\r\nWe will take a deeper look at another interesting property of this banking malware, the masquerading technique it\r\nuses to hide its code inside malicious replicas of legitimate computer programs like FileZilla, 7-zip, OllyDbg and\r\nWinGraph32. These maliciously-altered copies of real programs will appear completely legitimate to users during\r\ndownload.\r\nBackSwap plants its code in the initialization phase of the program, in an early stage of the program execution,\r\nreplacing the normal flow with its malicious instructions. The program will not return to its normal execution after\r\nthe malicious code begins running, in each variant we have seen the code was placed in a different part of the\r\nprogram, making detection and analysis challenging.\r\nAnalysis of 4 BackSwap Banking Malware Samples\r\nSample 1: 7-Zip\r\nSHA256: 16fe4de2235850a7d947e4517a667a9bfcca3aee17b5022b02c68cc584aa6548\r\nThis malware sample masquerades itself as the popular free and open-source file compression and archiver\r\nprogram “7-Zip”. The icon is identical to the original program, as well as in the other samples infected with this\r\nmalware. By looking at the properties of this file, nothing looks suspicious:\r\nBackSwap Malware Properties file masquerading as 7-Zip\r\nFigure 1 – Properties of the file masquerading as 7-Zip\r\nThe _initterm function\r\nThis purpose of the _initterm function is to walk through function pointers and execute the functions pointed to by\r\nthem. For example, it is used to initialize global variables of the program.\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 1 of 6\n\nLet’s look at the function pointers that the original _initterm of the legitimate 7-Zip (version 16.2.0.0) receives:\r\nBackSwap Malware 7zip_initterm\r\nFigure 2 – the function pointers passed to _initterm\r\nGoing inside the last pointer, sub_4328f8, we see initialization of variables\r\nBackSwap Malware 7zip inside last pointer\r\nFigure 3 – initialization of global variables in the function pointer passed to _initterm\r\nAnd it continues:\r\nBackSwap Malware zip inside last pointer\r\nFigure 4 – continue of figure 3 (some lines were truncated)\r\nHowever, while analyzing the version infected with BackSwap, we can see some malicious code right after the\r\nlast legitimate command (mov byte_44d5cd, al) instead of the “retn” command:\r\nBackSwap Malware 7zip first malware code\r\nFigure 5 – After the highlighted command, the malicious code begins\r\nScrolling down a bit, we can see a call to VirtualAlloc with RWX permissions. This hints to us the malware will\r\nuse it for continuing its execution. If we carefully examine the instructions there are “push” instructions which\r\npass the parameters to the VirtualAlloc.Notice that the push instructions are scattered among many other\r\ninstructions, which makes the analysis of this malware tricky.\r\nThe call and parameters are as follows:\r\nVirtualAlloc(0,0x3e00,0x3000, 0x40)\r\nBackSwap Malware 7zip valloc\r\nFigure 6 – push instructions among the code. In this figure you can see the push instructions of 0x40\r\n(PAGE_EXECUTE_READWRITE), 0x3000 (MEM_COMMIT | MEM_RESERVSE) and 0x3e00 (size of allocation)\r\n  BackSwap Malware 7zip_valloc_2\r\nFigure 7 – The last push instruction (0x0 – the optional starting address) is highlighted. The last line in the figure\r\nshows the call to VirtualAlloc\r\nThe size of allocation is 4 pages (16kb). To find further evidence, we look at a running instance of this malware at\r\nprocess hacker and see this memory region:\r\nBackSwap Malware 7zip phacker\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 2 of 6\n\nFigure 8 – A running instance of this malware. It first drops itself to the startup folder as “taskslist.exe” and runs\r\nit again. The allocated RWX memory region is highlighted.\r\nI will skip the deep drill down into the malware’s functionality as it is well documented in the reports we linked to\r\nat the top of this post, but let’s have a closer look at this code executed from this allocated region:\r\nThe first commands indicate that this code is Position-Independent-Code (PIC) as you can see the trick of “call\r\n$0” followed by “pop ebx”. When using the call instruction, the return address of that call instruction is pushed\r\ninto the stack. The next pop instruction moves the address at the top of the stack into the ebx register, so the\r\nmalware knows where it is in the process’ memory.\r\nBackSwap Malware 7zip PIC\r\nFigure 9 – Retrieving EIP\r\nWe can also see the malware trying to retrieve the address of kernel32.dll from the PEB, since this is a PIC and it\r\ndoesn’t know where the windows libraries are loaded.\r\nBackSwap Malware 7zip PEB\r\nFigure 10 – Checking the PEB for the address of kernel32.dll\r\nSample 2: FileZilla\r\nSHA256: 2223a93521b261715767f00f0d1ae4e692bd593202be40f3508cb4fd5e21712b\r\nThis sample masquerades itself as the free cross-platform FTP application, program “FileZilla”. One of the virtual\r\nfunctions of a class called “CWinThread” is patched. During the program initialization, in wWinMain function,\r\nthere is an initialization of this class using AfxGetThread() – which returns a pointer to the CWinThread object\r\nthat represents the currently executing thread. After that, one of the virtual functions in that class, at offset 0x50, is\r\nexecuted.\r\nLet’s have a look at the WinMain function of the original, clean FileZilla:\r\nBackSwap Malware FileZilla wWinMain\r\nFigure 11 – CWinThread is initialized and one of its virtual functions at offset 0x50 is called\r\nFrom our dynamic analysis, we identified that the executed function resides at 0x410935, which, as expected is in\r\noffset 0x50 from the start of the vtable of the CWinThread class. This can be computed, as 0x4BAB0C –\r\n0x4BAABC = 0x50\r\nBackSwap Malware filezilla vtable1\r\nFigure 12 – the vtable of the CWinThread class\r\nNow let’s compare the function that starts 0x410935 at the original FileZilla and at the infected FileZilla\r\nFigure 13 shows the clean FileZilla, where there is a call to WSAStartup.\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 3 of 6\n\nBackSwap Malware filezilla clean code\r\nFigure 13 – part of the function at 0x410935 of the original clean FileZilla\r\nFigure 14 shows that the malicious code starts right after “push 101h” instruction, without calling WSAStartup\r\nBackSwap Malware filezilla infected code\r\nFigure 14 – part of the function at 0x410935 of the infected FileZilla file, instead of calling WSAStartup, the\r\nmalicious code takes place\r\nAnother thing to note in this banking malware, compared to the previous sample, is the use of GetProcAddress to\r\nget the address of VirtualAlloc, instead of calling it directly. The parameters for VirtualAlloc, in this case, remain\r\nthe same.\r\nBackSwap Malware filezilla getprocaddress\r\nFigure 15 – Using GetProcAddress to get the address of VirtualAlloc. On the last line you can see the “push 40h”\r\ncommand which is the pages’ protection parameter – RWX in this case.\r\nSample 3: OllyDbg\r\nSHA256: f51336e862b891f78f2682505c3d38ea7de5b0673d6ef7a3b0907c0996887c22\r\nThis BackSwap malware sample masquerades itself as OllyDbg, the x86 debugger. This is a bit surprising as this\r\nprogram is a favorite of security researchers who use it for dynamic code analysis. Even the most security-aware\r\nusers are known to obtain unsigned tools from download sites.\r\nThis time, the malicious code hides in the WinMain function. In the original clean OllyDbg – the WinMain\r\nfunctions calls another function, CreateWindowExA (Figure 16).\r\nBackSwap Malware ollydbg clean\r\nFigure 16 – The clean version of OllyDbg contains a call to CreateWindowExA\r\nIn the infected version of OllyDbg, the parameters for CreateWindowExA are pushed into the stack but instead of\r\ncalling CreateWindowExA, the malicious code starts its execution (Figure 17).\r\nBackSwap Malware ollydbg_infected\r\nFigure 17 – Instead of calling CreateWindowExA – the malicious code executes\r\nSample 4: wingraph plugin\r\nSHA256: 6bb85a033a446976123b9aecf57155e1dd832fa4a7059013897c84833f8fbcf7\r\nThis sample masquerades itself as the program wingraph32. This sample is the newest we observed and was\r\nuploaded to VirusTotal on July 11\r\nth\r\n, 2018 at 7:14:24.\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 4 of 6\n\nThis time the malicious code is triggered by the call to _init_exit_proc which is also called at the initialization\r\nphase of the program. _init_exit_proc executes functions according to the pointer it receives. Functions are\r\nexecuted in a loop according to the pointer which is incremented in each step. One of the functions that\r\n_init_exit_proc calls was patched. The address of the function patched is 0x497a38.\r\nBackSwap Malware wingraph init exit proc\r\nFigure 18 – There are 2 loops in _init_exit_proc that go over function pointers. One of the functions executed in\r\nthe second loop is the one patched by the malware\r\nBackSwap Malware wingraph original\r\nFigure 19 – the function at 0x497a38 of the unpatched version of wingraph, notice that after the “sub” command\r\nthere is a “retn” command.\r\nBackSwap Malware wingraph infected\r\nFigure 20 – instead of the “retn” command, the malicious code executes\r\nIn this sample the allocation size of the first VirtualAlloc by the malicious code is different. It is 0x5912 bytes\r\nwhich translates to allocation of 6 pages (24KB).\r\nIn this sample, the malware uses additional protection, by copying an encrypted code to the allocated memory\r\nregion, and then decrypting it.\r\nBackSwap Malware wingraph algo\r\nFigure 21 – The algorithm used to decrypt the encrypted code (0x582dc3 to 0x582e0e)\r\nBackSwap Malwrae wingraph algo\r\nFigure 22 – The encrypted code, before decryption\r\nBackSwap Malware wingraph algo\r\nFigure 23 – The encrypted code, after decryption, notice the “call $0, pop ebx” commands which are identical to\r\nthe commands in the previous samples and indicate that this code is position independent.\r\nThe decryption algorithm can be translated to the following pseudo-code:\r\nBackSwap Malware wingraph pseudo code\r\nFigure 24 – The pseudo code of the decryption algorithm\r\nProtecting Against BackSwap Malware\r\nOur analysis shows that the BackSwap malware is hidden inside various legitimate and popular programs, often\r\nchanging its location within the program. The BackSwap malware code also varies from sample to sample and\r\nuses different obfuscation techniques each time. We suspect the authors used an automatic tool to infect these\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 5 of 6\n\nprograms with the malware. We expect this masquerading technique to be used in more malware in the future and\r\ntherefore recommend the following precautions:\r\nDownload software only from official publisher website\r\nDownload open source software only from the original verified GitHub account and verify it is signed by\r\nthe official publisher before running.\r\nHod Gavriel is a malware analyst at Cyberbit.\r\nBoris Erbesfeld is a principal software engineer at Cyberbit.\r\nLearn more about Cyberbit EDR Kernel-Based Endpoint Detection vs. Whitelisting\r\nSource: https://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nhttps://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.cyberbit.com/blog/endpoint-security/backswap-banker-malware-hides-inside-replicas-of-legitimate-programs/"
	],
	"report_names": [
		"backswap-banker-malware-hides-inside-replicas-of-legitimate-programs"
	],
	"threat_actors": [],
	"ts_created_at": 1775433974,
	"ts_updated_at": 1775791227,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/14f6c64b4e49a2be86eaae5c87a01f18eca8ddc9.pdf",
		"text": "https://archive.orkl.eu/14f6c64b4e49a2be86eaae5c87a01f18eca8ddc9.txt",
		"img": "https://archive.orkl.eu/14f6c64b4e49a2be86eaae5c87a01f18eca8ddc9.jpg"
	}
}