{ "id": "4d942353-540e-464d-96ed-b6915a8c222c", "created_at": "2026-04-06T00:10:25.440242Z", "updated_at": "2026-04-10T13:12:46.249242Z", "deleted_at": null, "sha1_hash": "16178f0c781b79d01b9a131814b3dec0a8f81a9f", "title": "BackSwap malware finds innovative ways to empty bank accounts", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 271787, "plain_text": "BackSwap malware finds innovative ways to empty bank accounts\r\nBy Michal Poslušný\r\nArchived: 2026-04-05 14:43:52 UTC\r\nBanking malware (also referred to as banker) has been decreasing in popularity among cybercrooks for a few\r\nyears now, one of the reasons being that both anti-malware companies and web browser developers are\r\ncontinuously widening the scope of their protection mechanisms against banking Trojan attacks. This results in\r\nconventional banking malware fraud becoming more complicated to pull off every day, resulting in malware\r\nauthors shifting their time and resources into developing easier-to-make and more profitable types of malware like\r\nransomware, cryptominers, and cryptocurrency stealers.\r\nWe have discovered a new banking malware family that uses an innovative technique to manipulate the browser:\r\ninstead of using complex process injection methods to monitor browsing activity, the malware hooks key\r\nWindows message loop events in order to inspect values of the window objects for banking activity.\r\nOnce banking activity is detected, the malware injects malicious JavaScript into the web page, either via the\r\nbrowser’s JavaScript console or directly into the address bar. All these operations are done without the user’s\r\nknowledge. This is a seemingly simple trick that nevertheless defeats advanced browser protection mechanisms\r\nagainst complex attacks.\r\nIntroduction\r\nWe first noticed the group behind this banking malware spreading their earlier projects – one of them being\r\nmalware that was stealing cryptocurrency by replacing wallet addresses in the clipboard – back in January of this\r\nyear. The group focused on clipboard malware for a few months and eventually introduced the first version of the\r\nbanking malware, detected by ESET as Win32/BackSwap.A, on March 13 2018.\r\nIn the figure below we can see a dramatic spike in detection rate compared to the previous projects, as viewed\r\nfrom our backend processes. The authors have been very active in the development of the banker and have\r\ncontinued to introduce new versions pretty much on a daily basis, taking breaks only at weekends.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 1 of 8\n\nFigure 1. Overview of detections of Win32/BackSwap.A banking malware and related, previous projects.\r\nDistribution and execution\r\nThe banker is distributed through malicious email spam campaigns that carry an attachment of a heavily\r\nobfuscated JavaScript downloader from a family commonly known as Nemucod. The spam campaigns are\r\ntargeting Polish users.\r\nVery often the victim machines are also compromised by the well-known Win32/TrojanDownloader.Nymaim\r\ndownloader, which seems to be spread using a similar method. At the time of writing we do not know whether this\r\nis just a coincidence or if these two families are directly connected.\r\nThe payload is delivered as a modified version of a legitimate application that is partially overwritten by the\r\nmalicious payload. The application used as the target for the modification is being changed regularly – examples\r\nof apps misused in the past include TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg,\r\nand FileZilla Server. The app is modified to jump to the malicious code during its initialization. One of the\r\ntechniques used to achieve this is adding a pointer to the malicious payload into the _initterm() function table,\r\nwhich is an internal part of C Run-Time Library that initializes all global variables and other parts of the program\r\nthat need to be initialized before the main() function is called.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 2 of 8\n\nFigure 2. _initterm pointer array of a legitimate application with pointer to banker’s shellcode at the end.\r\nThis method might be reminiscent of “trojanization”, but the difference is that the original application no longer\r\nworks, and once control is transferred to the malware, it will never return to the original code. Therefore, the\r\nintent is not to fool users into thinking they are running the legitimate app, but rather to increase the “stealthiness”\r\nof the malware against analysis and detection. This makes the malware harder for an analyst to spot, as many\r\nreverse engineering tools like IDA Pro will show the original main() function as a legitimate start of the\r\napplication code and an analyst might not notice anything suspicious at first glance.\r\nThe payload is a position-independent blob of code with all its data embedded within. The character strings are\r\nstored in plain text, which ruins its otherwise very small footprint, as all required Windows APIs are looked up by\r\nhash during runtime. The malware starts by copying itself into a startup folder in order to ensure persistence and\r\nthen proceeds with its banking functionality.\r\nConventional injection methods\r\nTo steal money from a victim’s account via the internet banking interface, typical banking malware will inject\r\nitself or its specialized banking module into the browser’s process address space. For many reasons, this is not an\r\neasy task – first of all, as mentioned before, the injection might be intercepted by a third-party security solution.\r\nThe injected module also needs to match the bitness of the browser – a 32-bit module cannot be injected into a 64-\r\nbit browser process and vice versa. This results in banking trojans usually having to carry both versions of a given\r\nmodule in order to support both 32-bit and 64-bit versions of the browsers.\r\nWhen successfully injected, the banking module needs to find browser-specific functions and hook them. The\r\nmalware looks for functions that are responsible for sending and receiving HTTP requests in plain text before\r\nencryption, and after decryption, respectively. The difficulty of finding these functions varies from browser to\r\nbrowser – in the case of Mozilla Firefox, the functions are exported by the nss3.dll library and their addresses can\r\nbe effortlessly looked up by their widely known names. On the other hand, Google Chrome and other Chromium-based browsers have these functions hidden and implemented deep inside the binary, which makes them very hard\r\nto find. This forces the malware authors to come up with specialized methods and patterns that only work for the\r\nspecific version of the browser. Once a new version comes out, new methods and patterns must be implemented.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 3 of 8\n\nIf the right functions are found and hooks are successfully installed (note that hooks may also be detected by a\r\nsecurity solution), the banking trojan can begin to modify the HTTP traffic or redirect the victim to a different\r\nwebsite impersonating a bank while faking the validity of a certificate. Similar techniques are incorporated by\r\ncurrently active, high-profile banking trojans like Dridex, Ursnif, Zbot, Trickbot, Qbot and many others.\r\nNew browser manipulation technique\r\nWin32/BackSwap.A has a completely different approach. It handles everything by working with Windows GUI\r\nelements and simulating user input. This might seem trivial, but it actually is a very powerful technique that solves\r\nmany “issues” associated with conventional browser injection. First of all, the malware does not interact with the\r\nbrowser on the process level at all, which means that it does not require any special privileges and bypasses any\r\nthird-party hardening of the browser, which usually focuses on conventional injection methods. Another advantage\r\nfor the attackers is that the code does not depend either on the architecture of the browser or on its version, and\r\none code path works for all.\r\nThe malware monitors the URL currently being visited by installing event hooks for a specific range of relevant\r\nevents available through the Windows message loop, such as EVENT_OBJECT_FOCUS,\r\nEVENT_OBJECT_SELECTION, EVENT_OBJECT_NAMECHANGE and a few others. The hook will look for\r\nURL patterns by searching the objects for strings starting with “https” retrieved by calling the get_accValue\r\nmethod from the event’s IAccessible interface.\r\nFigure 3. Technique used for retrieving currently-visited URLs from the browser. These URLs are retrieved by\r\nchecking the [ht]tp[s] substring (in red).\r\nThe malware will then look for bank-specific URLs and window titles in the browser that indicate that the victim\r\nis about to make a wire transfer.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 4 of 8\n\nFigure 4. Banker looks for specific bank strings – the first string is a window title, the second is a part of a URL.\r\nOnce identified, the banker loads malicious JavaScript appropriate for the corresponding bank from its resources\r\nand injects it into the browser. The script injection is also done in a simple, yet effective way.\r\nIn older samples, the malware inserts the malicious script into the clipboard and simulates pressing the key\r\ncombination for opening the developer’s console (CTRL+SHIFT+J in Google Chrome, CTRL+SHIFT+K in\r\nMozilla Firefox) followed by CTRL+V, which pastes the contents of the clipboard and then sends ENTER to\r\nexecute the contents of the console. Finally, the malware sends the console key combination again to close the\r\nconsole. The browser window is also made invisible during this process – to regular users it might seem as if their\r\nbrowser simply froze for a moment.\r\nIn the newer variants of the malware, this approach has been upgraded – instead of interacting with the\r\ndeveloper’s console, the malicious script is executed directly from the address bar, via JavaScript protocol URLs,\r\na little-used feature supported by most browsers. The malware simply simulates pressing CTRL+L to select the\r\naddress bar followed by the DELETE key to clear the field, then “types” in “javascript:” by calling\r\nSendMessageA in a loop, and then pastes the malicious script with the CTRL+V combination. It then executes the\r\nscript by sending the ENTER key. At the end of the process, the address bar is cleared to remove any signs of\r\ncompromise.\r\nIn Figure 5 we can see a part of the console injection code: first, the malware determines the browser by checking\r\nthe class name of the foreground window (marked in blue). The malicious JavaScript is copied into the clipboard\r\n(marked in red). Then, the opacity of the browser window is changed to 3, which turns it invisible (marked in\r\npurple). Green marks the part of the ToggleBrowserConsole function that turns the browser’s console on and off.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 5 of 8\n\nFigure 5. Script injection technique.\r\nWin32/BackSwap.A supports attacks against Google Chrome, Mozilla Firefox and in recent versions its authors\r\nalso added support for Internet Explorer. However, this method will work for most browsers today, as long as they\r\nhave a JavaScript console available or implement execution of JavaScript from the address bar, both of which are\r\nstandard browser features these days.\r\nAll three supported browsers have an interesting protective feature, which was originally designed as a\r\ncountermeasure against Self-XSS attacks: When users attempt to paste text starting with “javascript:” into the\r\naddress bar, the protocol prefix is removed and users need to type it into the address bar manually to actually\r\nexecute the script. Win32/BackSwap.A bypasses this countermeasure by simulating the typing of the prefix into\r\nthe address bar, letter by letter, before pasting in the malicious script.\r\nAnother countermeasure implemented by Mozilla Firefox disallows pasting scripts into the console by default and\r\ninstead shows a message warning users about potential risks, forcing them to type in “allow pasting” first. The\r\nmalware bypasses this by executing the shell command shown in Figure 6, which modifies the prefs.js\r\nconfiguration file and removes this countermeasure.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 6 of 8\n\nFigure 6. The shell command used to remove Firefox script console pasting protection.\r\nMalicious JavaScript\r\nThe banker implements a specific script for each targeted bank, as every banking site is different and has different\r\nsource code and variables. These scripts are injected into pages the malware identifies as initiating a wire transfer\r\nrequest, such as paying a utility account. The injected scripts secretly replace the recipient’s bank account number\r\nwith a different one and when the victim decides to send the wire transfer, the money will be sent to the attackers\r\ninstead. Any safeguards against unauthorized payment, such as 2-factor authorization, won’t help in this case, as\r\nthe account owner is willingly sending the wire transfer.\r\nWin32/BackSwap.A has had malicious scripts targeting five Polish banks in total - PKO Bank Polski, Bank\r\nZachodni WBK S.A., mBank, ING and Pekao. Its authors sometimes remove some banks from the list of targets\r\nand in the most recent version, for example, they left only three banks - PKO BP, mBank and ING. In older\r\nversions, the attackers were retrieving the receiving bank account numbers from C\u0026C servers that were hosted on\r\nhacked WordPress websites. In the recent versions, they have stored these account numbers directly in the\r\nmalicious scripts. The malicious bank account numbers change very frequently, and pretty much every campaign\r\nhas a new one.\r\nAs we can see in the figure below, the banker will only steal money if the wire transfer amount is in a certain\r\nrange - they usually target payments between 10,000 and 20,000 PLN, which is around 2,800 – 5,600 USD. The\r\nscript replaces the original recipient bank account, and also replaces the input field for that number with a fake one\r\nthat displays the original bank account, so the user sees the valid number and thus is unlikely to be suspicious.\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 7 of 8\n\nFigure 7. Part of the malicious JavaScript. The areas in red show the checking of the wire transfer amount and\r\nreplacement of the recipient’s bank account number.\r\nConclusion\r\nWin32/BackSwap.A shows us that in the ongoing battle between the security industry and authors of banking\r\nmalware, new malicious techniques do not necessarily need to be highly sophisticated to be effective. We think\r\nthat, as browsers become better protected from conventional code injection, malware authors will attack the\r\nbrowsers in different fashions and Win32/BackSwap.A has just shown us one of the possibilities.\r\nESET solutions detect and block the threat as Win32/BackSwap.A trojan.\r\nWe have notified the affected browser vendors about the innovative script injection technique.\r\nSpecial thanks to Paweł Śmierciak for discovering this family and his help in this research.\r\nIoCs\r\n9BC4C1D5403DDD90712CE87225490A21D1EDC516 JS/Nemucod.EAN trojan\r\nCF5A74C268661501156663F74CD5E20603B0F261 Win32/BackSwap.A trojan\r\n6251F9AD0E5F551AC4A6B918EF366E86C4CCFDC4 Win32/BackSwap.A trojan\r\n2DC9760A7C6E9D261C73EFB7B2604840734BC058 Win32/BackSwap.A trojan\r\nA68901D0D8C1247FF280F9453E3AE45687C57566 Win32/BackSwap.A trojan (JavaScript)\r\nSource: https://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nhttps://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MITRE", "ETDA" ], "origins": [ "web" ], "references": [ "https://www.welivesecurity.com/2018/05/25/backswap-malware-empty-bank-accounts/" ], "report_names": [ "backswap-malware-empty-bank-accounts" ], "threat_actors": [ { "id": "9f101d9c-05ea-48b9-b6f1-168cd6d06d12", "created_at": "2023-01-06T13:46:39.396409Z", "updated_at": "2026-04-10T02:00:03.312816Z", "deleted_at": null, "main_name": "Earth Lusca", "aliases": [ "CHROMIUM", "ControlX", "TAG-22", "BRONZE UNIVERSITY", "AQUATIC PANDA", "RedHotel", "Charcoal Typhoon", "Red Scylla", "Red Dev 10", "BountyGlad" ], "source_name": "MISPGALAXY:Earth Lusca", "tools": [ "RouterGod", "SprySOCKS", "ShadowPad", "POISONPLUG", "Barlaiy", "Spyder", "FunnySwitch" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "18a7b52d-a1cd-43a3-8982-7324e3e676b7", "created_at": "2025-08-07T02:03:24.688416Z", "updated_at": "2026-04-10T02:00:03.734754Z", "deleted_at": null, "main_name": "BRONZE UNIVERSITY", "aliases": [ "Aquatic Panda", "Aquatic Panda ", "CHROMIUM", "CHROMIUM ", "Charcoal Typhoon", "Charcoal Typhoon ", "Earth Lusca", "Earth Lusca ", "FISHMONGER ", "Red Dev 10", "Red Dev 10 ", "Red Scylla", "Red Scylla ", "RedHotel", "RedHotel ", "Tag-22", "Tag-22 " ], "source_name": "Secureworks:BRONZE UNIVERSITY", "tools": [ "Cobalt Strike", "Fishmaster", "FunnySwitch", "Spyder", "njRAT" ], "source_id": "Secureworks", "reports": null }, { "id": "6abcc917-035c-4e9b-a53f-eaee636749c3", "created_at": "2022-10-25T16:07:23.565337Z", "updated_at": "2026-04-10T02:00:04.668393Z", "deleted_at": null, "main_name": "Earth Lusca", "aliases": [ "Bronze University", "Charcoal Typhoon", "Chromium", "G1006", "Red Dev 10", "Red Scylla" ], "source_name": "ETDA:Earth Lusca", "tools": [ "Agentemis", "AntSword", "BIOPASS", "BIOPASS RAT", "BadPotato", "Behinder", "BleDoor", "Cobalt Strike", "CobaltStrike", "Doraemon", "FRP", "Fast Reverse Proxy", "FunnySwitch", "HUC Port Banner Scanner", "KTLVdoor", "Mimikatz", "NBTscan", "POISONPLUG.SHADOW", "PipeMon", "RbDoor", "RibDoor", "RouterGod", "SAMRID", "ShadowPad Winnti", "SprySOCKS", "WinRAR", "Winnti", "XShellGhost", "cobeacon", "fscan", "lcx", "nbtscan" ], "source_id": "ETDA", "reports": null }, { "id": "d53593c3-2819-4af3-bf16-0c39edc64920", "created_at": "2022-10-27T08:27:13.212301Z", "updated_at": "2026-04-10T02:00:05.272802Z", "deleted_at": null, "main_name": "Earth Lusca", "aliases": [ "Earth Lusca", "TAG-22", "Charcoal Typhoon", "CHROMIUM", "ControlX" ], "source_name": "MITRE:Earth Lusca", "tools": [ "Mimikatz", "PowerSploit", "Tasklist", "certutil", "Cobalt Strike", "Winnti for Linux", "Nltest", "NBTscan", "ShadowPad" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434225, "ts_updated_at": 1775826766, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/16178f0c781b79d01b9a131814b3dec0a8f81a9f.pdf", "text": "https://archive.orkl.eu/16178f0c781b79d01b9a131814b3dec0a8f81a9f.txt", "img": "https://archive.orkl.eu/16178f0c781b79d01b9a131814b3dec0a8f81a9f.jpg" } }