{ "id": "826a561f-7768-4170-950c-247678099cdf", "created_at": "2026-04-06T00:10:39.032578Z", "updated_at": "2026-04-10T03:36:36.877115Z", "deleted_at": null, "sha1_hash": "9483fd2dc653bed5ab67a5dc351f5d31691a61e5", "title": "LOLSnif – Tracking Another Ursnif-Based Targeted Campaign", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 66566, "plain_text": "LOLSnif – Tracking Another Ursnif-Based Targeted Campaign\r\nBy Deutsche Telekom AG\r\nPublished: 2020-05-14 · Archived: 2026-04-05 20:31:25 UTC\r\nTool leaks are very interesting occurrences in cyber security. On one hand, they may burn the leaked tool since it\r\ngot either publicly known or it facilitates the analysis of the tool significantly.  On the other hand, it transfers\r\ncapabilities to other, possibly lower-skilled actors. In my new blog post I analyze a newer version of Ursnif, which\r\nhas been turned into an exploration tool and downloader. Because: In case of malicious software, source code\r\nleaks are very remarkable events. But first a small classification to get started. A notable example from the cyber\r\nsecurity history was the leak of the exploit code “Eternal Blue” (CVE-2017-0144) in 2017. This very powerful\r\nremote exploit empowered many lower-skilled actors to conduct intrusions with ease. \r\nSuch leaks have occurred every now and then and they will most likely continue to occur in the years to come.\r\nThe leak of the banking Trojan Zeus definitely shaped the malware landscape during the 2010s. Its source code\r\nwas leaked in 2010. What followed was a plethora of offspring that share the same code base with the original\r\nZeus banking Trojan. For instance, the zeusmuseum lists 28 families including Citadel, Pandabanker, and more\r\nrecently Zloader. Many families continued to operate as banking Trojans like their ancestor but some of them\r\nadopted another purpose like the downloader Zloader.\r\nBesides the Zeus source code leak, there are many more interesting leaks, each of them deserves its own story. In\r\nthis blog article, I focus on another malware family whose source code got leaked in 2014. This family is called\r\nUrsnif (also known as Gozi2/ISFB). Ursnif is a fully-fledged banking Trojan. There has been many great technical\r\nas well as historical work on this family in the recent years. For instance, Maciej Kotowicz wrote a very good\r\nwrite-up on this family in 2016 and the podcast “Malicious Life” produced two episodes about the history of Gozi,\r\nthe ancestor of Ursnif. Today, the source code of Ursnif can be easily found on the Internet. Many actors took this\r\nsolid code base and based their work on it. \r\nIn this blog post, I analyze a recent Ursnif variant, which was repurposed to be a reconnaissance tool and\r\ndownloader. It is a modern variant utilizing techniques like LOLBins, Component Object Model (COM) interfaces\r\nto instrument the Internet Explorer and as a consequence bypass local proxies as well as Windows Management\r\nInstrumentation (WMI) to interact with the operating system in place of native Win32 APIs. Campaigns associated\r\nwith this variant start with a cascade of several layers of obfuscation, which ensures that the detection rate is very\r\nlow, even several days after a campaign has started. This variant plays an important role in these campaigns which\r\nappear to be targeted cybercrime attacks.\r\nIt was first publicly mentioned in August 2019, which is in line with the registration dates of some associated\r\ndomains and it gained momentum in autumn and winter 2019/2020. Recently, a blog article scrutinized one of its\r\ncampaigns in April 2020, pointing out its use of LOLBins. In a nutshell, LOLBins stands for “Living Off the Land\r\nBinaries”, which means to utilize system tools that are already on a target system in order to carry out nefarious\r\npurposes. For instance, there are dozens of Windows system tools that can be utilized to download files, dump\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 1 of 6\n\ncredentials, or execute other binaries. As a consequence, attacks do not need to bring their own tools and may hide\r\ntheir traces in other legitimate uses of these tools. \r\nTo the best of my knowledge, it is not yet tracked under its own name. Since the Ursnif variant that I will look into\r\nin this blog article makes use of LOLBins and there is already a reference to this (“Ursnif via LOLbins”), I will\r\nrefer to it as LOLSnif in the following.\r\nDigging Deeper into A Recent Campaign\r\nAt first, I will look into a recent LOLSnif campaign started on 2020-04-07 in order to get an idea of the actors\r\nTTPs. Later, I will zoom out and review recent activity of other campaigns of the associated actor.\r\nEach campaign begins with a cascade of several layers of obfuscation. It all starts with a spam email that contains\r\nan encrypted ZIP archive. The mail mentions the password for decryption and encourages the recipient to open it.\r\nThe next layer is a 1.34 MB sized, heavily obfuscated JavaScript file called “my_presentation_v8s.js”\r\n(4d98790aa67fb14f6bedef97f5f27ea8a60277dda9e2dcb8f1c0142d9619ef52). Its first submission to VirusTotal\r\nwas on 2020-04-07 and its initial detection rate was very low. This JavaScript file ultimately drops a PE\r\nexecutable with file name “UtBuefba.txt“ as well as a text file to “AppData\\Local\\Temp”. The text file contains\r\nwhat appears to be an eight character long ASCII key that the PE executable requires to unpack properly. This\r\nmight be a way to thwart analysis if only the PE executable is shared.\r\nThe DLL is first launched via “regsvr32.exe -s [redacted]\\AppData\\Local\\Temp\\\\UtBuefba.txt”. The option “-s”\r\nstands for silent registration, which does not show a dialog box. Even though DLLs to be loaded with regsvr32 are\r\nrequired to comprise the exports “DllRegisterServer” and “DllUnregisterServer”, this DLL does not export them.\r\nIt has just a regular DLL entry point. However, this file unpacks an APlib-compressed Ursnif DLL. This DLL\r\n(e3d89b564e57e6f1abba05830d93fa83004ceda1dbc32b3e5fb97f25426fbda2) is not known on VirusTotal as of\r\n2020-04-17.\r\nBefore I continue with the analysis of the DLL, let me note that the techniques that the actor utilizes in their\r\ncascade of obfuscated layers ensure very low detection rates of their tools within the first days.\r\nDissecting LOLSnif\r\nThe DLL that I unpacked in the previous section is part of a recent fork of Ursnif, which I will refer to as LOLSnif\r\nin the following. LOLSnif comprises two main components: the loader and the worker component. The first drops\r\nthe latter. Both are PE DLLs with slightly broken headers, where the DOS header magic number (“MZ”) as well\r\nas the PE header magic number (“PE”) are overwritten. While this may hinder some sandbox solutions to properly\r\ndump the payloads, this can be easily fixed. Notably both are x86 binaries. During my research I did not find any\r\nx64 binaries related to this malware.\r\nThe Loader\r\nThe unpacked DLL (e3d89b564e57e6f1abba05830d93fa83004ceda1dbc32b3e5fb97f25426fbda2) comprises two\r\nexports: the DLL entry point and DllRegisterserver that is required for DLL registration with regsvr32. It\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 2 of 6\n\nresembles an Ursnif loader and uses the same configuration mechanism (JJ structure). \r\nThe following screenshots illustrates a JJ structure right beneath the section listing of the PE header. Each\r\nconfiguration section starts off with the magic number 0x4A4A (“JJ”) and holds an offset to the data as well as a\r\nCRC32 tag to describe the data type (e.g. additional payload). A profound introduction into the configuration\r\nformat of Ursnif can be found here.\r\nJJ structure\r\nThe loader comprises two configuration sections. The first section is an “INSTALL_INI” that is required to install\r\nthe payload of the second section. The second section contains an APlib-compressed DLL that is the actual\r\nworker. Before this second DLL is unpacked the loader checks whether the operating system has a Russian or\r\nChinese localization. If so, then the loader silently stops its operation.\r\nThe Worker\r\nLOLSnif’s worker still resembles an original Ursnif worker. For instance, the general structure of the project is\r\nstill preserved. This includes peculiarities like the configuration storage using JJ structures and the encrypted\r\n“.bss” section that holds strings and other data that deserves protection. Although there are some slight changes to\r\nthe encryption algorithm. However, there are several interesting enhancements that I will detail later on.\r\nIts configuration format is the same as its ancestor. The following screenshot shows a configuration blob that is\r\nhighlighted with colors. Its first part compromises structures with offsets to strings and information on the data\r\ntype. At the end of the blob (grey area) are these strings stored. For instance, the area highlighted in blue contains\r\nthe command and control server addresses. This area is followed by a list of public DNS server. Notably this blob\r\ncontains configuration parameters for a DGA (Domain Generation Algorithm), e.g. the domain where to download\r\nkeywords for domain generation (constitution[.]org). However, LOLSnif does not comprise any functionality to\r\ngenerate domain names.   \r\nConfiguration blob\r\nAs its ancestor Ursnif, LOLSnif comes with a encrypted “.bss” section that holds, for example, strings. This\r\nsection is decrypted on startup. However, the decryption algorithm differs slightly from the original code base.\r\nThe following screenshot depicts the decryption algorithm. The decryption key is still based on the sample’s\r\ncompilation date, which is hard-coded in the binary. However, there are some modifications to this key. Also, the\r\noriginal Ursnif utilized a rolling XOR algorithm, where LOLSnif’s algorithm is based on add / sub instructions.\r\nThe full list of decrypted strings can be found in Appendix B (pdf, 121.5 KB).\r\nDecryption algorithm\r\nFurthermore, some strings do not have references. Hence, they are dead and not needed. While this may be an\r\nissue with the disassembler, this is rather an issue with the code. The strings are defined in Ursnif's code as macros\r\n(see header file “Common/cschar.h”). Therefore, the authors of the malware must keep track of them. This may\r\nsuggest that this functionality is not yet implemented, or the author forgot to clean up all unused functionality like\r\nin the DGA example.\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 3 of 6\n\nThe interaction with the registry is implemented in two ways: via native Win32 APIs (e.g. RegOpenKey,\r\nRegEnumKey, RegCloseKey) and via Windows Management Instrumentation (WMI). There are wrapper\r\nfunctions that take a Boolean argument in order to decide whether to use the Win32 API or WMI. For instance, the\r\nfollowing screenshot shows a wrapper function for setting a string value of a registry key. The first argument\r\n(annotated as “use_wmi” in the disassembly) determines the use of native API or WMI.\r\nWrapper function\r\nLOLSnif seems to be only built for x86. However, it clearly anticipates that it will run on x64 platforms as well.\r\nFor instance, it utilizes the flag “__ProviderArchitecture” to request data from a 64 bit WMI provider as an 32 bit\r\napplication.\r\nAnother interesting aspect is that LOLSnif makes extensive use of COM interfaces. It was reported that this\r\nmalware instruments the Internet Explorer via IWebBrowser in order to contact its Command and Control servers\r\n(CC). This tactic allows it to bypass any proxy configuration in a cooperate network since Internet Explorer\r\ntypically knows how to talk to the proxy. LOLSnif anticipates that there might be invalid certificate warnings\r\nsince it searches in the DOM via IHTMLElement for the string “invalidcert”. If it encounters this string, then it\r\nconfirms the warning to send the payload to the CC server. However, the current sample does not utilize https but\r\nrather plain http. Furthermore, the malware sets Internet Explorer as standard browser in order to avoid any\r\npopups during operation.\r\nThis Ursnif variant makes use of LOLBins (as also pointed out in this blog). For instance, LOLBins are utilized to\r\nstart the malware from the registry (mshta.exe + powershell.exe). Furthermore, LOLSnif is capable of download\r\nand execute further modules as well as payloads. For instance, a recent blog post mentions that the associated\r\nactor dropped a Cobalt Strike BEACON as well as a legitimate TeamViewer VNC client. \r\nZooming Out: Tracking LOLSnif’s /api1 Activity Throughout the Last Months\r\nBased on the campaign that I observed in April 2020, I pivoted to track LOLSnif activity throughout the last\r\nmonths. There are several links we can leverage to find more samples and domains. Appendix A (pdf, 93.0 KB)\r\nlists all IoCs that I found during my investigation. First, the string decryption algorithm of LOLSnif differs from\r\nthe original code base. Therefore, I hunted for more samples based on this algorithm. This yielded several samples\r\nfrom which I was able to extract the configuration. The following table shows the unique configurations that I was\r\nable to find.\r\nHash (SHA256\r\nprefix)\r\nBotnet\r\nID\r\nServer\r\nID\r\nSerpent Key Compilation Timestamp\r\n8d700ea 1000 730 W7fx3j0lFvOxT2kF\r\nThu Oct 31 14:55:25 2019\r\nUTC\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 4 of 6\n\nc206f90 2000 730 W7fx3j0lFvOxT2kF\r\nWed Dec  4 16:56:24 2019\r\nUTC\r\n7307f15 3000 730 W7fx3j0lFvOxT2kF\r\nWed Feb 19 11:18:20 2020\r\nUTC\r\nf48e634 2000 730 U7yKaYwFde7YtppY\r\nWed Feb 19 11:18:24 2020\r\nUTC\r\n8ffe59d 3000 730 W7fx3j0lFvOxT2kF\r\nWed Apr  1 17:32:33 2020\r\nUTC\r\nAll samples share the same server ID (730) and the same RSA key (not listed here). There are three botnet IDs\r\n(1000, 2000, 3000) that follow an increasing pattern with each campaign. Their compilation timestamps seem to\r\nbe legit. All but the last share the domain ”wensa[.]at” or a subdomain of it. As we later will see, the actor utilized\r\nthis domain for roughly six months. The serpent CBC key is “W7fx3j0lFvOxT2kF” in all cases but one. This\r\noutlier belongs to the botnet ID 2000, which has the key “U7yKaYwFde7YtppY”. Interestingly, there are two\r\nsamples that were compiled within four seconds on 2020-02-19, which suggests that there is some form of build\r\nautomation. \r\nAnother way is to pivot on the CC infrastructure. First, all samples use “/api1” as part of their URLs, e.g.\r\n“been.dianer[.]at/api1”. Second, all domains but one uses the “.at” TLD. There is one TOR “.onion” domain\r\n“6buzj3jmnvrak4lh.onion”. If we utilize passive DNS information regarding the already known domains / IPs,\r\nthen we find further interesting information. There are many domains that the associated actor utilized for several\r\nmonths. The domain “wensa[.]at” was probably utilized for the longest time, roughly six months.\r\nThe following timeline shows the unique configurations and some of the domains. The samples are described by\r\ntheir SHA256 prefix and their serpent CBC key prefix, e.g. 8d700ea_W7. The domains have a first seen date (FS)\r\nand some of them a last seen date (LS). The domains lamanak[.]at and kamalak[.]at that the actor probably\r\nregistered at the very beginning of their operation are still from time to time associated with IPs of their\r\ninfrastructure. Furthermore, I suppose that the aforementioned wensa[.]at domain was replaced by the pipen[.]at\r\ndomain in March 2020. \r\nTimeline\r\nThe associated actor does either not care about OpSec or is very sure of their capabilities since they are reusing\r\ndomains and IPs several times and they utilize them sometimes for very long periods of time.\r\nConclusion\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 5 of 6\n\nIn this blog, I’ve scrutinized a recent Ursnif variant to which I refer as LOLSnif and its recent activity. The\r\nassociated actor possibly conducts targeted cybercrime operations that are still ongoing. At the heart of these\r\ncampaigns is a variant of the Ursnif Trojan that was repurposed as a downloader and reconnaissance tool to meet\r\nthe actor’s special needs. \r\nThe techniques utilized by this actor such as LOLBins, heavy obfuscation, as well as COM interfaces and the\r\nTTPs observed by others in later stages of an attack such as utilization of post exploitation frameworks (Cobalt\r\nStrike) and VNC clients (TeamViewer) suggest that this actor is involved in targeted attacks. The attacks are\r\nongoing since month without much public attention. This maybe the reason why the associated actor reuses\r\ndomains and IPs over and over again.\r\nNevertheless, this actor should not be overlooked and maybe more data in the future (e.g. from Incident Response\r\nEngagements) helps to shed some light on the ultimate goal of this actor.\r\n Appendix A: IoCs (pdf, 93.0 KB)\r\n Appendix B: Full Dump of Decrypted Strings (pdf, 121.5 KB)\r\nMore informationCybersecurity: TA505’s Box of Chocolate\r\nCybersecurity: Dissecting Emotet - part one\r\nCybersecurity: Dissecting Emotet - part two\r\n \r\nSource: https://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nhttps://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://www.telekom.com/en/blog/group/article/lolsnif-tracking-another-ursnif-based-targeted-campaign-600062" ], "report_names": [ "lolsnif-tracking-another-ursnif-based-targeted-campaign-600062" ], "threat_actors": [ { "id": "5e6b31a6-80e3-4e7d-8b0a-d94897ce9b59", "created_at": "2024-06-19T02:03:08.128175Z", "updated_at": "2026-04-10T02:00:03.636663Z", "deleted_at": null, "main_name": "GOLD TAHOE", "aliases": [ "Cl0P Group Identity", "FIN11 ", "GRACEFUL SPIDER ", "SectorJ04 ", "Spandex Tempest ", "TA505 " ], "source_name": "Secureworks:GOLD TAHOE", "tools": [ "Clop", "Cobalt Strike", "FlawedAmmy", "Get2", "GraceWire", "Malichus", "SDBbot", "ServHelper", "TrueBot" ], "source_id": "Secureworks", "reports": null }, { "id": "75d4d6a9-b5d1-4087-a7a0-e4a9587c45f4", "created_at": "2022-10-25T15:50:23.5188Z", "updated_at": "2026-04-10T02:00:05.26565Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "TA505", "Hive0065", "Spandex Tempest", "CHIMBORAZO" ], "source_name": "MITRE:TA505", "tools": [ "AdFind", "Azorult", "FlawedAmmyy", "Mimikatz", "Dridex", "TrickBot", "Get2", "FlawedGrace", "Cobalt Strike", "ServHelper", "Amadey", "SDBbot", "PowerSploit" ], "source_id": "MITRE", "reports": null }, { "id": "99cb4e5b-8071-4f9e-aa1d-45bfbb6197e3", "created_at": "2023-01-06T13:46:38.860754Z", "updated_at": "2026-04-10T02:00:03.125179Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "SectorJ04", "SectorJ04 Group", "ATK103", "GRACEFUL SPIDER", "GOLD TAHOE", "Dudear", "G0092", "Hive0065", "CHIMBORAZO", "Spandex Tempest" ], "source_name": "MISPGALAXY:TA505", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e447d393-c259-46e2-9932-19be2ba67149", "created_at": "2022-10-25T16:07:24.28282Z", "updated_at": "2026-04-10T02:00:04.921616Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "ATK 103", "Chimborazo", "G0092", "Gold Evergreen", "Gold Tahoe", "Graceful Spider", "Hive0065", "Operation Tovar", "Operation Trident Breach", "SectorJ04", "Spandex Tempest", "TA505", "TEMP.Warlock" ], "source_name": "ETDA:TA505", "tools": [ "Amadey", "AmmyyRAT", "AndroMut", "Azer", "Bart", "Bugat v5", "CryptFile2", "CryptoLocker", "CryptoMix", "CryptoShield", "Dridex", "Dudear", "EmailStealer", "FRIENDSPEAK", "Fake Globe", "Fareit", "FlawedAmmyy", "FlawedGrace", "FlowerPippi", "GOZ", "GameOver Zeus", "GazGolder", "Gelup", "Get2", "GetandGo", "GlobeImposter", "Gorhax", "GraceWire", "Gussdoor", "Jaff", "Kasidet", "Kegotip", "Kneber", "LOLBAS", "LOLBins", "Living off the Land", "Locky", "MINEBRIDGE", "MINEBRIDGE RAT", "MirrorBlast", "Neutrino Bot", "Neutrino Exploit Kit", "P2P Zeus", "Peer-to-Peer Zeus", "Philadelphia", "Philadephia Ransom", "Pony Loader", "Rakhni", "ReflectiveGnome", "Remote Manipulator System", "RockLoader", "RuRAT", "SDBbot", "ServHelper", "Shifu", "Siplog", "TeslaGun", "TiniMet", "TinyMet", "Trojan.Zbot", "Wsnpoem", "Zbot", "Zeta", "ZeuS", "Zeus" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434239, "ts_updated_at": 1775792196, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/9483fd2dc653bed5ab67a5dc351f5d31691a61e5.pdf", "text": "https://archive.orkl.eu/9483fd2dc653bed5ab67a5dc351f5d31691a61e5.txt", "img": "https://archive.orkl.eu/9483fd2dc653bed5ab67a5dc351f5d31691a61e5.jpg" } }