{ "id": "0cd63871-7fd9-4754-a13f-3b3363de9460", "created_at": "2026-04-06T00:17:17.25835Z", "updated_at": "2026-04-10T03:26:17.717997Z", "deleted_at": null, "sha1_hash": "dca00759c5e939a167522d1eda7437299a5a78bb", "title": "Malspam with Lokibot vs. Outlook and RFCs - SANS ISC", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 252708, "plain_text": "Malspam with Lokibot vs. Outlook and RFCs - SANS ISC\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 21:33:54 UTC\r\nCouple of weeks ago, my phishing/spam trap caught an interesting e-mail carrying what turned out to be a sample\r\nof the Lokibot Infostealer.\r\nAt first glance, the e-mail appeared to be a run of the mill malspam message.\r\nThe text was a low-quality translation of English into Czech.\r\nIt claimed that the recipient needed to verify contents of attached file, that was supposed to contain\r\ninformation about an upcoming funds transfer.\r\nThe sender name and signature were supposed to look like the message came from an employee of one of\r\nthe major Czech banks.\r\nThe message, however, turned out to be more interesting than it first appeared…\r\nBut before we get to that, let’s quickly look at the attachment, which was interesting in its own right. The attached\r\nZIP archive contained an ISO file, which in turn contained an EXE. As it turned out, the executable was created\r\nwith the Nullsoft Scriptable Install System, a legitimate tool for creating installer packages for Windows, which is\r\nsometimes used by malware authors in lieu of/in addition to a packer[1].\r\nhttps://isc.sans.edu/diary/27282\r\nPage 1 of 8\n\nEXEs created with NSIS can be opened using 7-Zip[2]. Using this approach, one can easily get access to their\r\ncontents, which in this case meant only an NSI installation script and a single DLL (0xtwa2t09nc.dll) located\r\nwithin a $PLUGINSDIR subdirectory.\r\nAs its name suggests, an NSI installation script should basically specify which steps are to be taken during an\r\ninstallation. In this case it contained only one function of note named .onInit.\r\nAs you may see, the .onInit function was simply supposed to call another function called Ycksxjzoiwxisk from the\r\nDLL located in the $PLUGINSDIR directory.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 2 of 8\n\nAfter this function was called, a malicious payload - which turned out to be a version of the Lokibot infostealer -\r\nwould be decoded and loaded into memory. It would then copy the original executable to %appdata% directory,\r\ncreate a registry key pointing to the copy of the application, remove the original executable and stay resident.\r\nDuring its in-memory residence, it would try to gather sensitive data (configurations, passwords, etc.) from a list\r\nof file system and registry locations.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 3 of 8\n\nIt would then try to contact a C2 server and exfiltrate the collected data to it using HTTP. At the time of analysis,\r\nthe server contacted by this version of the malware already appeared to be down and all attempts at accessing it by\r\nthe malware were met with a HTTP 404 error.\r\nA small point to note is that the malware seemed to use a fixed ~60 second beaconing period.\r\nI’ve mentioned that the malware created a registry key after it copied the original malicious executable to the\r\n%appdata% directory. From this, you may have (quite reasonably) assumed that the key in question would have\r\nbeen created in one of the usual places that might be used to ensure persistence of the malware. This might indeed\r\nhave been what authors of the malware were going for, but either due to encoding issues or some other reason,\r\nwhen I executed the malware in a VM (English version of W10), the key ended up in the root of the HKCU hive\r\nwith an unexpected name.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 4 of 8\n\nIt is clear, that if the registry modification was indeed an attempt at ensuring persistence, it didn’t go according to\r\nplan. This was however not the only interesting thing regarding encoding with our malspam… Which brings us\r\nback to the e-mail message.\r\nAlthough, as I’ve mentioned, at first the e-mail appeared quite ordinary, a second look at it led to an interesting\r\ndiscovery. When an e-mail is opened in Outlook, it normally either displays both the name and an address of the\r\nsender…\r\n…or Outlook may, under certain specific conditions, display only the name of the sender. If one then hovers on the\r\nname with a cursor, the name will turn blue and a corresponding Outlook contact card will be displayed.\r\nApart from that, one could simply right-click on the name (or on the icon with portrait or initials next to it) and\r\ndisplay the contact card (and the e-mail address) that way.\r\nIn the case of our malspam, however, this did not happen. The name of the sender was not interactive in any way\r\nand if the icon with initials was right-clicked and the contact card was displayed, it was empty with no e-mail\r\naddress present.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 5 of 8\n\nIf one were to click on the “Reply” button, the behavior of Outlook would again seem unusual, as it would only\r\ndisplay the name of the sender as text in the “To” field, and not any e-mail address.\r\nAfter a quick analysis, the reason for these issues became clear - they were caused by the use of non-RFC-compliant sender address in the message, or - more specifically - by incorrectly used mixed-encoding. Per RFC\r\n2047[3], non-ASCII encodings may be used in e-mail headers, the only requirement appears to be that the\r\nencoded text is formatted according to the following specification:\r\n=?charset?encoding?encoded-text?=\r\nThe use of mixed-encoding in a single header is allowed by the RFC as well, if the two encodings are whitespace\r\nseparated:\r\nOrdinary ASCII text and 'encoded-word's may appear together in the\r\nsame header field. However, an 'encoded-word' that appears in a\r\nheader field defined as '*text' MUST be separated from any adjacent\r\n'encoded-word' or 'text' by 'linear-white-space'.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 6 of 8\n\nIn cases when a sender address contains non-ASCII characters, it is therefore quite normal and proper to use – for\r\nexample – a UTF-8 encoded string for the name, followed by an ASCII string, as in the following case:\r\nFrom: =?UTF-8?Q?Jan_Kop=C5=99iva?= \u003cjan@notimportant.tld\u003e\r\nThis would result in the following sender information being displayed:\r\nSo where is the issue with our malspam message? Let’s take a look at its From header:\r\nFrom: =?UTF-8?B?xIxlc2vDoSBzcG/FmWl0ZWxuYQ==?=, a.s. \u003cinfo@[redacted].xyz\u003e\r\nAs you may see, there is not a white space character after the end of the UTF-8 encoded text. However even if we\r\nwere to put a whitespace after it, things would not look as they should – Outlook would simply display the same\r\ntext in a decoded form, followed by the encoded form…\r\nYou can however probably guess where the issue lies – it is in the comma. Comma is a special character in the\r\narea of e-mail communication (consider that we separate multiple recipients by it) and therefore if it were used in\r\na display name of a sender, it would need to be quoted to be compliant with RFC 5322[4]. This is something the\r\nsenders of the malspam probably didn’t know – they simply separated the intended display name into two parts:\r\none with non-ASCII characters, which would have to be UTF-8 encoded, and\r\nthe other one (\", a.s.\"), that didn't contain non-ASCII characters and could therefore be left in the original\r\nunencoded form… Or not, as our example shows.\r\nIf one were to put the comma, or the entire second part of the display name, in quotes, the sender information\r\nwould finally look as it was supposed to.\r\nAs we may see, the “missing address” issue was caused by a non-RFC-compliant message being interpreted by\r\nOutlook, that expects to parse RFC-compliant content.\r\nSo, is this a vulnerability? Not really – Outlook appears to be working pretty much in accordance with the RFC\r\nspecification… Unfortunately, as our malspam message shows, distributors of malicious e-mail messages don’t\r\nnecessarily have to conform to such standards, which may result in an unexpected behavior when such a message\r\nis received.\r\nhttps://isc.sans.edu/diary/27282\r\nPage 7 of 8\n\nAlthough a missing sender address in an e-mail from an unknown/external sender would be most suspicious to\r\nany security-minded recipient, to most regular users the fact that only a (potentially well-known) name would be\r\ndisplayed where a sender address should be could make any message appear much more trustworthy. So even\r\nthough the use of non-compliant sender addresses probably won’t be the “next big thing” in phishing, it is\r\ncertainly good to know that it is possible and that it is used in the wild, even if (at least so far) completely\r\nunintentionally. And it may also be worth it to mention the corrensponding behavior of Outlook in any advanced\r\nsecurity awareness classes dealing with targetted attacks that you might teach...\r\nIndicators of Compromise (IoCs)\r\nCeskasporitelna, a.s.Swift_260321_scan.zip (172 kB)\r\nMD5 - bcd356d0c4c8d80bff2dea8045602044\r\nSHA1 - f67f9dee7683aeb617183e0ceab4db5830a417f8\r\nCeskasporitelna, a.s.Swift_260321_scan.exe (511 kB)\r\nMD5 - f6a59e6f73bc89e1d75db46f32d624dc\r\nSHA-1 - ae70271d98402a100fcf3f6bc2d209025c9c321f\r\n0xtwa2t09nc.dll (116 kB)\r\nMD5 - 93d707a549d1b91001efbd75e858064d\r\nSHA-1 - 3939a8e4935e4561a005fee08ac831ff0bd4f207\r\n[1] https://threatpost.com/raticate-group-industrial-firms-revolving-payloads/155775/\r\n[2] https://isc.sans.edu/forums/diary/Quick+analysis+of+malware+created+with+NSIS/23703/\r\n[3] https://tools.ietf.org/html/rfc2047\r\n[4] https://tools.ietf.org/html/rfc5322\r\n-----------\r\nJan Kopriva\r\n@jk0pr\r\nAlef Nula\r\nSource: https://isc.sans.edu/diary/27282\r\nhttps://isc.sans.edu/diary/27282\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://isc.sans.edu/diary/27282" ], "report_names": [ "27282" ], "threat_actors": [ { "id": "0d07b30c-4393-4071-82fb-22f51f7749e0", "created_at": "2022-10-25T16:07:24.097096Z", "updated_at": "2026-04-10T02:00:04.865146Z", "deleted_at": null, "main_name": "RATicate", "aliases": [], "source_name": "ETDA:RATicate", "tools": [ "AgenTesla", "Agent Tesla", "AgentTesla", "BetaBot", "BlackRAT", "BlackRemote", "Bladabindi", "CloudEyE", "ForeIT", "Formbook", "GuLoader", "Jorik", "Loki", "Loki.Rat", "LokiBot", "LokiPWS", "NSIS", "Negasteal", "NetWeird", "NetWire", "NetWire RAT", "NetWire RC", "NetWired RC", "Neurevt", "Nullsoft Scriptable Install System", "Origin Logger", "Recam", "Remcos", "RemcosRAT", "Remvio", "Socmer", "ZPAQ", "njRAT", "vbdropper", "win.xloader" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434637, "ts_updated_at": 1775791577, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/dca00759c5e939a167522d1eda7437299a5a78bb.pdf", "text": "https://archive.orkl.eu/dca00759c5e939a167522d1eda7437299a5a78bb.txt", "img": "https://archive.orkl.eu/dca00759c5e939a167522d1eda7437299a5a78bb.jpg" } }