{
	"id": "d7fc6ef7-d5e5-4910-b3d8-678e29d67e66",
	"created_at": "2026-04-06T01:30:08.203862Z",
	"updated_at": "2026-04-10T03:21:17.368691Z",
	"deleted_at": null,
	"sha1_hash": "cd447dbb16ea72551da7823cd7c5d591d6ea12f6",
	"title": "The Evolution of BackSwap",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 116344,
	"plain_text": "The Evolution of BackSwap\r\nBy deugenio\r\nPublished: 2018-11-30 · Archived: 2026-04-06 01:14:25 UTC\r\nThe Story of An Innovative Banking Malware\r\nResearch By: Itay Cohen\r\nIntroduction\r\nThe BackSwap banker has been in the spotlight recently due to its unique and innovative techniques to steal\r\nmoney from victims while staying under the radar and remaining undetected. This malware was previously\r\nspotted targeting banks in Poland but has since moved entirely to focus on banks in Spain. The techniques used by\r\nit were thoroughly described by our fellow researchers at the Polish CERT and Michal Poslusny from ESET, who\r\nrevealed and coined the malware’s name earlier this year. However after witnessing ongoing  improvements to its\r\nmalicious techniques we decided to share this information to the wider research community.\r\nIn the following research paper, we will focus on the evolution of BackSwap, its uniqueness, successes, and even\r\nfailures. We will try to give an overview of the malware’s different versions and campaigns, while outlining its\r\ntechniques, some of which were proven inefficient and dropped soon after their release by the developers. We will\r\nalso share a detailed table of IOC and a Python3 script used to extract relevant information from BackSwap’s\r\nsamples.\r\nBackSwap Overview\r\nBanking malware is not a new phenomenon. Zbot, Gozi, Dridex, Carberp and other notorious banking trojans took\r\nadvantage of the embracement and the increased use of the internet for issuing bank transactions, and made good\r\nprofit from it. For years, these malware families found advanced and sophisticated ways to steal bank credentials\r\nand credit card details from innocent victims, and abuse this information for stealing money. In response to this,\r\nthe security industry, as well as web-browser companies such as Google and Mozilla, fought back with better\r\nsecurity mechanisms and detections.\r\nMost banking malware steals money by injecting their code into the memory of the victim’s browser. This code\r\nwould in turn hook the appropriate communication functions in the browser, so as to intercept any private banking\r\ndata. This data would then be issued to the attacker via some protocol of exfiltration. This approach has proven to\r\nbe quite complex and unstable, as the injected code must be adapted to each target browser. Moreover, the\r\nattackers have to keep track of the fast and ever-changing code of modern browsers, which is indeed a challenge.\r\nThis, among other reasons, could explain what seems to be a decrease in the popularity of banking malware.\r\nIndeed we have seen a lot of the aforementioned banking trojans replaced with far more lucrative and profitable\r\nmalware families, crypto miners and ransomware are good examples to name a few. This set a perfect scenario for\r\nthe appearance of BackSwap, which is unique in it being both simple and yet effective in stealing banking\r\ncredentials.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 1 of 16\n\nBackSwap is written in assembly as position independent code, which hides itself inside a big set of popular and\r\nlegitimate software. Some examples for this are programs like 7-Zip, FileZilla and Notepad++. On the surface, the\r\nexecutable for this programs look innocent, but in fact they are bundled with code that was meticulously\r\nimplanted by the attackers, and is not evident at first sight. This code is what will eventually execute when the\r\nuser launches any of the aforementioned applications, while the real legitimate code will never run.\r\nThis payload described above can be found in arbitrary places inside the original program, such that it  overrides\r\nvery particular chunks of the original code. This method is used for the purpose of diverting the execution of the\r\nlegitimate code to a compact piece of shellcode that constitutes the malware’s logic. This latter code is very small\r\nin comparison to the size of the original program, thus further complicating the ability to detect it by security tools\r\nand endpoint products. Such systems would scan only chunks of the binaries they deal with, which gives way for\r\nBackswap to hide deep within code that will otherwise not be flagged as malicious.\r\nThe method of diversion mentioned above demonstrates a level of creativity that is not common in banking\r\nmalware, and would more likely be spotted in targeted attacks and APT campaigns. In this technique, the\r\ndevelopers modified some C runtime initialization code, usually bundled to the executable by the compiler, which\r\nusually appears as pieces of code that execute prior to the program’s main function. In particular, they hijacked a\r\npiece of code that initializes internal data structures by invoking a set of callbacks from a predefined function\r\npointer table. This table (used by the __initterm() function from CRT) is added with an additional pointer, that will\r\nin turn cause the C runtime to invoke the malware’s code before executing the original program.\r\nAfter the initialization code transfers the execution to the malicious code planted by BackSwap, the latter would\r\neither allocate a dedicated memory space for the final payload, would sometimes create a new thread or would\r\nsimply divert the instruction pointer to the final payload. As mentioned earlier, this payload is entirely written in\r\nassembly and invoked as position independent code. Such code can be executed anywhere in the memory,\r\nregardless of its base address. Since this code cannot assume where it would be located, it uses relative addresses,\r\njumps, and indirect calls instead of hard-coded memory addresses. Writing a whole malware in this fashion is not\r\ntrivial, nor easy to write, or analyzed by researchers. Even though BackSwap’s position-independent payload went\r\nthrough several major changes and improvements in the last year, the developers did not drop this technique and\r\nhave stuck to it since the very first variant, which may signify its effectiveness.\r\nOne of the things that caught our attention, and was also mentioned in the publication by the Polish CERT, is how\r\nBackSwap uses its hard-coded strings. Unlike regular programs where strings are most likely to be found in read-only data sections, PIC code has to handle it differently. In particular, BackSwap uses a rare technique where the\r\nstrings are not separated from the code but reside as integral part of it, such that whenever BackSwap wants to\r\npush a string to the stack (e.g in order to pass it as a function argument), it is placed inline with the code right after\r\na CALL instruction to the address that follows the end of the string. Thus, when the call is invoked, the subsequent\r\naddress to the instruction pointer’s value is saved in the stack, and this address would point to the inlined string.\r\nTo clarify this method we can look at the following pseudo assembly code that prints “ABC” using printf:\r\n0x00 e8 04 00 00 00 call 9\r\n0x05 41 42 43 00 ; string \"ABC\" len=4\r\n0x09 e8 f1 f1 ff ff call _printf\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 2 of 16\n\nUsing strings inside a code isn’t trivial and many disassemblers, like IDA Pro, can’t handle it correctly. Radare2,\r\nor its graphic-user-interface program — Cutter — can handle this quite well, and treat the strings as part of the\r\nfunction, as can be seen in the image below.\r\nFigure 1: Call-over-string technique as shown in Cutter\r\nBecause of BackSwap’s position-independent nature, it can’t rely on the Import Address Table to retrieve the\r\naddresses of common Windows API functions. Instead, it uses a common technique, used mostly in injected code,\r\nwhereby the PEB structure (Process Environment Block) is processed in order to find the list of loaded modules,\r\nfrom which the address of kernel32.dll can be retrieved. Then, by parsing the PE structure and locating the\r\n`LoadLibraryA` API functions, BackSwap loads more DLLs, the names of which are hardcoded in it.\r\nIn order to load all the functions that are needed for its execution, BackSwap creates an uninitialized table with\r\nhardcoded hashes of function names. It then iterates over all the export functions of the loaded libraries and\r\ncalculates a hash number for each function name. These function names are compared to the precalculated hashes\r\nin the table and if there is a match, BackSwap fills the address of the corresponding function in its table. This way,\r\nBackSwap implements and builds its very own Import Table in run-time.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 3 of 16\n\nFigure 2: PEB parsing and detection of kernel32 base address from one of the loaded libraries lists\r\nAfter initializing all the crafted table with all required function addresses, BackSwap begins to prepare the ground\r\nfor its core functionality – stealing credentials and money from its victims. First, it checks if another instance of\r\nitself is already running. It does so by using a technique which is similar to checking the existence of a Mutex in\r\nthe system. Namely, it determines if a Windows event object which has the name pattern ` \u003cUSERNAME\u003e-\r\n\u003cCOMPUTERNAME\u003e ` already exists. If so, the malware will terminate the execution, as it infers another copy is\r\nrunning in the system.\r\nDepending on its version, and following the above check, BackSwap would create several threads and setup event\r\nhooks for a range of events using the `SetWinEventHook` function. Although there are some changes in this\r\nbehavior between different versions of the malware, the essential logic is the same – the hooked events are\r\nintended to intercept activity that occurs with relation to window applications across the computer. Some of the\r\nhooked events can be seen below.\r\n0x8005 EVENT_OBJECT_FOCUS\r\n0x8006 EVENT_OBJECT_SELECTION\r\n0x8007 EVENT_OBJECT_SELECTIONADD\r\n0x8008 EVENT_OBJECT_SELECTIONREMOVE\r\n0x8009 EVENT_OBJECT_SELECTIONWITHIN\r\n0x800A EVENT_OBJECT_STATECHANGE\r\n0x800B EVENT_OBJECT_LOCATIONCHANGE\r\n0x800C EVENT_OBJECT_NAMECHANGE\r\n0x800D EVENT_OBJECT_DESCRIPTIONCHANGE\r\n0x800E EVENT_OBJECT_VALUECHANGE\r\nUpon each event interception, the triggered hook function would search for a URL starting with `https` in the\r\ninformation gathered from the hooked events. In newer versions of BackSwap, if a URL was found, the malware\r\nwill in turn decrypt a resource from its .rsrc section which turns out to be its web-injects, a piece of javascript code\r\nthat is injected to the internet browser in order to manipulate objects in pages visited by the user. This code will be\r\nparsed, and the found URL would be checked to see if it matches one of the banks targeted by the malware.  \r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 4 of 16\n\nThe approach taken by BackSwap to insert the javascript code in to the browser is simple, yet unique and\r\npowerful. Instead of injecting code straight to the browser’s memory, the malware mimics a user interaction with\r\nthe browser’s window by sending keystrokes to it. Namely, It opens the browser’s Developer’s Tools or sets the\r\nfocus to the URL bar and pastes the malicious javascript by faking a press on Ctrl+V. This unique way will go\r\nunder the radar of many security tools because it is hard to tell the difference between this and a legitimate user\r\ninteraction. Different versions of BackSwap interact differently with the browser and we will describe these\r\ndifferences later in the article.\r\nThe content of the javascript web-injects is the component of BackSwap that changes most often across versions\r\nand samples. Obviously, it has to be unique for each targeted bank, but Backswap does an extra mile in changing\r\nwhat the javascript does, how it would manipulate the victim’s browser to send money to the criminals and how it\r\nwill pass the stolen credentials to the C\u0026C server.\r\nOne of the threads created by the malware will loop infinitely and check if the javascript web-inject passed any\r\ncredentials to send to the C\u0026C. It could be either by saving the stolen information to the clipboard or by changing\r\nthe window’s title. Once again, These techniques of sending information from the JS to the binary differ between\r\nversions of BackSwap, and will be discussed with more detail later on.\r\nBackSwap Evolution\r\nDuring the past few months we have tracked hundreds of Backswap samples and were able to observe many\r\nchanges amongst them. By inspecting all this data, we could sort the samples into groups and note the changes and\r\nmodifications in the malware’s behavior from its appearance in the wild to present time.\r\nEarly Versions\r\nThe first samples of BackSwap were spotted at the middle of March 2018 and, naturally, is considered the\r\nsimplest in its evolution. These samples almost did not contain any measures to complicate the analysis of the\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 5 of 16\n\npayload, which was inserted as-is to the original program (Mostly 7-Zip but also WinGraph and SQLMon). For\r\nthis reason, a lot of the malware’s strings, including targeted banks and browsers, were all visible. Hence, it was\r\npossible to infer that the targeted banks were all Polish and each sample inspected was targeting between 1 and 3\r\nbanks. The most common targeted bank sites in these samples were ipko.pl, 24.pl and mbank.pl.\r\nAnother characteristic of this initial version is that it kept an encrypted resource for each one of the banks it\r\ntargeted, where the encryption method used was a simple singly byte XOR with the value 0x9. Its interesting to\r\nnote that while this method is very weak from a cryptographic standpoing, BackSwap keeps using it to this day.\r\nThe web-injects code itself was also quite straight-forward, and contained the placeholder\r\n‘xxxxxxxxxxxxxxxxxxxxxxxxxx’ that was set by the malware to hold an IBAN for stolen money transactions.\r\nWhenever the victim entered one of the targeted banking websites and wanted to perform a transaction, the web-inject code would replace the target IBAN with the aforementioned one, thus transferring the money to the\r\nattackers instead of the real intended recipient.\r\nA month later, in April 2018, more banks were added as targets, and some of the samples contained up to six\r\ndifferent resources in a single binary. The Javascript implementation of the web-injects code improved and\r\ncontained a new way for it to interact with the code in the PE binary, using the title of the browser’s window. The\r\nshellcode checks for changes to the text in the title of the browser and grabs the information which is sent to it but\r\nthe WebInjects. Additionally, a background thread in the malware’s PE took any stolen information and stored it in\r\na log file on the computer, which was later sent to a C\u0026C server.\r\nIn the middle of April, BackSwap began to create fake input objects in the DOM of the targeted websites. These\r\nfake input fields look exactly like the original ones, But while the users fill the fake fields, the original fields are\r\nnow hidden and contain the attacker’s IBAN. This change in BackSwap was thoroughly presented and\r\ndemonstrated by F5 in this article. At the same time, the malware started to abandon a former injection technique\r\nwhereby the victim’s browser was opened to the developer’s tools utility, where web-injects code would be pasted\r\nto alter the current page. Instead it moved to a technique where the malicious javascript would be pasted in the\r\nURL address bar.\r\nAt the end of April, BackSwap started using another XOR key for the first time in order to encrypt its resources,\r\nthis time it was 0xb. This type of change has promptly become typical for BackSwap, to the extent that we were\r\nable to spot eight different encryption keys in May. In fact, all recent samples come with a distinctive key.\r\nHowever, as noted before, it still uses a single-byte XOR which is a weak encryption method.\r\nApart from the change in XOR key, the authors also moved the IBAN to be hardcoded in the web-injects\r\njavascript, as opposed to the binary where it previously resided. This persisted  through most of the samples in\r\nMay, where some had additional names appended, which most likely correspond to money mules that participated\r\nin the operation.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 6 of 16\n\nFigure 3: Hard-coded information of a money mule.\r\nThe web-injects in May also presented a new function named ` copyStringToClipboard ` which was responsible\r\nfor copying a given string to the clipboard, as the name suggests. This string contained stolen information that was\r\nfilled by the victim and was picked up by a thread in the malware’s PE that read and processed it.\r\nAdditionally, in the same month BackSwap began tracking the number of infected machines, which was done by\r\nsending an HTTP request to a popular Russian website, yadro.ru, that tracks hit-counts for websites. This method\r\nis very simple and effective for collecting victim telemetry from the attacker’s site, as it’s hard to flag by security\r\nproducts, with the target site for collection of this data being legitimate.\r\nEncrypted Payload Inside a BMP Image\r\nJune 2018 was a significant month for the evolution of BackSwap, in which the developers introduced a unique\r\ntechnique for payload encoding that wasn’t described before in relation to BackSwap. In this technique, the PIC\r\ndescribed before is encrypted, and embedded inside a BMP image, taking advantage of a unique characteristic of\r\nthe BMP header.\r\nFigure 4: First image to introduce embedded position-independent code\r\nThe magic header of a BMP file is 0x42, 0x4D which corresponds to “BM” in ASCII. This pair of hexadecimal\r\nnumbers happens to also be valid x86 instructions. The following screenshot from radare2 will demonstrate this\r\ninterpretation of the bytes.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 7 of 16\n\nThe criminals behind BackSwap took advantage of the BMP header in order to make the code look more innocent.\r\nAfter the execution of these dummy instructions, there is a JMP instruction to an address that starts the decryption\r\nroutine of the PIC as can be seen in the following screenshot. The decryption routine is quite simple and can be\r\neasily analyzed.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 8 of 16\n\nWhile the first BMP image was rather abstract and hard to understand, the subsequent ones turned out to be\r\nmeaningful and based on real images, either from the internet or created by the attackers. The first example to\r\nshow up is an image from a famous scene in Al Pacino’s famous movie “Scarface”.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 9 of 16\n\nThe first sample with this image also contained a change in how BackSwap’s web-injects interact with the PE\r\nbinary. The previously described technique where a window’s title was changed to convey information was\r\nremoved, leaving the clipboard as the single entity for communicating with the malware’s code in the PE binary.\r\nRecent Versions\r\nThe biggest respite in BackSwap’s activity was in July 2018. We detected almost no activity in its development as\r\nwell as its distribution and estimated that some major improvements were likely to arrive. Indeed, In August 2018\r\nwe were provided with new samples that signified a particular turning point for the malware as we could observe\r\nsome new changes in it.\r\nFirst, it shifted its malicious operation to focus almost entirely on Spanish banks while totally abandoning any\r\npreviously targeted Polish banks.\r\nFigure 5: Some of the Spanish and Polish banks that are targeted by BackSwap\r\nExcept for the targets, BackSwap changed the way it stores its web-injects. Instead of keeping it in different\r\nresources for each targeted bank, as it did before, it aggregated all of them into a single resource, such that each\r\nweb-inject code snippet was delimited by a particular separator keyword. During August we detected two such\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 10 of 16\n\nseparators being used, the first one was “ [start:] ” and the second “ [fartu:] ”. Moreover, the targeted bank\r\nsites were not stored in the malware’s PIC anymore, but in the web-inject code itself. An example for this new\r\nform of web-injects can be seen below.\r\nA few samples from August were found using external websites to store their javascript payload. While the web-injects were still stored in the .rsrc section of the hijacked program, they were simply a wrapper and imported\r\nthe malicious javascript code from other servers. This was the first and only time we saw BackSwap doing\r\nthis. Storing malicious code on 3rd party servers is less stable since security vendors and the website itself can\r\ntake down the malicious pages.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 11 of 16\n\nBackSwap introduced few more BMP images during August. We spotted images of Cartman, an old lady, Link\r\nfrom The Legend of Zelda video game series and an image of the Russian president, Vladimir Putin. At the end of\r\nAugust, the criminals added a rather childish text to a version of Putin’s image where they try to offend the AV\r\nindustry.\r\nFigure 6: BackSwap’s PIC embedded in an image of Putin.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 12 of 16\n\nThe variants from September through November haven’t shown any major changes. We observed some\r\nmodifications in the PIC payload, especially more encryption layers and tons of junk-code that is meant to make\r\nthe analysis more complicated as well as making the malware harder to detect. During these months BackSwap\r\nintroduced more separators to its Javascript web-injects such as [mumuo:] and [pghtyq] in September,\r\n[tempo:] and [code:] in October, and the most recent [joke:] in November. It also added more versions\r\nfor its BMP images. The main image used in October was of Stalin taken from a famous propaganda poster, and\r\nmost of November’s samples  had an image of a man waving the LGBTQ pride flag.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 13 of 16\n\nThe most recent sample that we spotted, from the end of November, introduced a new image taken from a 1970’s\r\nRussian TV-series called “Seventeen Moments of Spring” (Семнадцать мгновений весны) based on a novel with\r\nthe same name. The delimiter in the web-injects was also changed and is now “ [asap:] ”. This isn’t the only\r\nchange, as it seems that the way the malware transfers information from the Javascript web-inject code to the\r\nexecuted shellcode in the PE changed as well. As described earlier, BackSwap used to send the victim’s\r\ncredentials and other messages to the shellcode via the clipboard, which is now replaced by sending the same data\r\nthrough the browser’s URL.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 14 of 16\n\nFigure 7: Backswap newest BMP image\r\nBackSwap’s latest sample was also sending another childish message to the AV industry, asking the industry to\r\nstay out of its way. Well, this is not going to happen.\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 15 of 16\n\nFigure 8: image of  the latest message to the AV industry\r\nConclusion\r\nWhile banking trojans seem to have become a far less prominent method of stealing money in the cyber criminal\r\nworld, BackSwap is the evidence that this monetization model is not dead yet. In fact, when it comes to\r\nBackSwap it seems that the opposite is true As described in this publication we can definitely see ongoing efforts\r\nby the malware’s authors to improve it and make it more evasive from security products.\r\nMoreover, users should be cautious when downloading software from unauthorized sources, as this malware\r\ndemonstrates the ability to bypass security measures by pretending to be a legitimate application. In light of such a\r\nthreat, it is highly recommended to obtain software only from the sites of its original distributors.\r\nWe at Check Point Research are continuing to track this threat so as to provide the best mitigation against it, even\r\nin light of its dynamic and constantly changing nature.\r\nAppendix\r\nbackswap_extractor.py – A radare2-based Python3 script which can be used to decrypt and\r\nextract information from several versions of BackSwap including its\r\nposition-indepndent payload.\r\nbackswap-ioc.csv – A table of IOC and other relevant information about BackSwap’s samples.\r\nSource: https://research.checkpoint.com/the-evolution-of-backswap/\r\nhttps://research.checkpoint.com/the-evolution-of-backswap/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://research.checkpoint.com/the-evolution-of-backswap/"
	],
	"report_names": [
		"the-evolution-of-backswap"
	],
	"threat_actors": [],
	"ts_created_at": 1775439008,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cd447dbb16ea72551da7823cd7c5d591d6ea12f6.pdf",
		"text": "https://archive.orkl.eu/cd447dbb16ea72551da7823cd7c5d591d6ea12f6.txt",
		"img": "https://archive.orkl.eu/cd447dbb16ea72551da7823cd7c5d591d6ea12f6.jpg"
	}
}