Normal view

There are new articles available, click to refresh the page.
Before yesterdayAvast Threat Labs

Hitching a ride with Mustang Panda

2 December 2022 at 04:00

Avast discovered a distribution point where a malware toolset is hosted, but also serves as temporary storage for the gigabytes of data being exfiltrated on a daily basis, including documents, recordings, and webmail dumps including scans of passports from Asian, American and European citizens and diplomats applying for Burmese visas, from Burmese human rights activists and Burmese government institutions.

We recently came across a peculiar sample – a stager we believe is being used by Mustang Panda. The stager led us to the group’s distribution point, where we found malicious toolsets. We have analyzed the malware and were able to see relations between various campaigns that have been described by other cybersecurity firms over the course of the last years. Based on publicly published research and our own investigations, we can say with high confidence that the modus operandi and the malicious toolset show a strong link to a group related to Mustang Panda, which has previously been reported as a Chinese APT group. The group has been known for gathering intelligence on Mongolia, and further Asian countries, and most recently was suspected of targeting European entities.

The distribution point, an FTP server, is also used as a transition point for exfiltrated victim data, before the data is moved to an unknown location. We continue to observe new data being uploaded and moved from the point, meaning the campaign is still active, and has been going on for some time. Gigabytes of data are moved around, and the amount of data indicates severe compromise of many high-profile targets in Myanmar. The data types include various office documents and PDFs, stolen browser profiles, webmail dumps and even sound recordings. Browsing profiles were also extracted which can provide access to other infrastructures, services, and private data of the victims. Most of the stolen data seems to be in Burmese making it challenging to analyze. The sensitive data is mainly being collected from devices used by the Myanmar government, state administration, police, army, significant public organizations, or companies, and includes data related to diplomatic meetings, court hearings, military information, contracts and more.

Disclaimer: We have only seen partial snapshots of the exfiltrated data as they are deleted shortly after being moved from the distribution point, so it should be noted that the information we have on victims may be inaccurate or incomplete. Most of the documents are in Burmese, therefore, a language barrier has also to be taken into account. Finally, due to the limited scope and the sheer volume of the data, some assumptions had to be made during the research process. We have reached out to local CERTs, informing them of our findings.


Nearly all of the victims have close ties to Myanmar and it seems that both the Burmese government and opposition groups are being targeted. We have seen data originating from various departments of several Burmese ministries. Even the Office of the State Administrative Council has been targeted. The government breach is not isolated to Myanmar – we have also seen Myanmar embassies among targets, for example, the embassy in Serbia. The data also contained dumps of a mailbox used to communicate in 2016 and 2017, as well as in 2020 with visa applicants from all around the world. These messages contained scans of passports from citizens and diplomats from various countries, such as China, Australia, Czech Republic, France, Israel, Netherlands, UK, and USA.

After such an extensive list of targets, it ought to be little surprise that Myanmar Police Force is also among the targets. Even some higher profile departments, such as the Office of the Information Police Chief or the Department of Special Investigation, seem to have been breached. Tatmadaw (Myanmar Armed Forces) is also not an exception – we have seen victims from the Bureau of Air Defense, Myanmar Army Engineering, and the United Wa State Army.

Political NGOs and the government’s opposition are also on the list of victims. It is possible that the list is even more extensive as we may not be able to find a straightforward association to said organizations as we would expect more common usage of personal computers or computers that are not centrally maintained by an IT department. We have seen data from devices belonging to the Karen National Union, Center for Diversity and National Harmony, National Reconciliation and Peace Centre, Ethnic Nationalities Affairs Center, and even the Union Civil Service Board.

Exfiltrated Data 

The most common file types being exfiltrated by the group are Microsoft Office documents (.docx, .xlsx, .pptx, etc.), PDF documents, and plain text files. Other file types exfiltrated include audiovisual data in various forms, including sound recordings (.mp3), and pictures (.jpg, .png, etc.) or drawings. Emails, including entire conversations are also exfiltrated.

It appears that the attackers are also looking for and collecting data from browser profiles from various web browsers, e.g. Chrome, Firefox, Opera, and more, a serious threat to victims’ privacy. The stolen browser profiles can provide access to other infrastructures, services, and the victims’ private data of the victims. The attackers are extracting information about browsing history, stored credentials (personal and work), credit cards, used tokens, and valid cookie sessions. Consequently, poorly secured services, such as services without two-factor authentication or without a safe cookie policy, can be easily abused by attackers. Attackers can steal the identity of victims and can use their email, Facebook, Telegram, or other accounts to collect additional information about the victim and their family, friends, and activities.

Highly sensitive data is being collected from victims’ computers, and, in most cases, these are computers used by the Myanmar government, state administration, police, army, significant public organizations, or companies. This in some cases included sensitive data and information belonging to international citizens and diplomats who have interacted with targeted departments.

The documents, and audiovisual data being exfiltrated by the group is massive. The files include everything from:

  • Email dumps including visa applications and scans of passports belonging to citizens and diplomats from various countries, such as China, Australia, Czech Republic, France, Israel, Netherlands, UK, and USA
  • A seating plan for the meeting between former US Ambassador to the United Nations Bill Richardson and Myanmar’s leader, Senior Gen. Min Aung Hlaing 
  • Myanmar’s constitution with proposed changes
  • Invitations for diplomatic meetings, meeting programs, calls, and talking points
  • Reports, maps, and screenshots from the Signal messaging app related to the UWSA (United Wa State Army)
  • Data from the Office of the Chief of Myanmar Air Defense Force, including meeting minutes, full staff/rank lists, photo IDs (some with fingerprints), salaries, personal details of employees’ families
  • Peace treaty documents
  • Interrogation reports
  • Contracts
  • Court hearings
  • Town plans
  • Contact information for police officers, including their names, addresses, telephone numbers, and salaries
  • Transcripts of meetings around politics, and elections
  • Meeting minutes and audio recordings of meetings between Myanmar senior officials (Prime minister, Chairman of State Administrative Council) and the President of Tatarstan
  • Military buildings drawings, including munitions storage, oil storage and aerial photos of proposed sites 
  • International banking records and records and transfers from supporters to a refugee group

Ties to known campaigns

Since getting our hands on the distribution point, we have established links between known campaigns already publicly reported and what we have discovered. This gives us clues as to how resourceful the group may be and will also help us assess its modus operandi.

We have found files strongly resembling (or even matching) samples and their relations described in a blogpost by ESET around the Korplug variant dubbed Hodur. The campaign they described was targeting various government organizations in Mongolia, Vietnam, and Myanmar, along with politically-oriented NGOs. This is in alignment with the victimology of the stolen data we have seen on the distribution point. Hodur was attributed to the Mustang Panda group. The related part of the uncovered toolset we analyzed also contained a USB launcher written in Delphi, similar to the one seen accompanying the Hodur variant of Korplug analyzed by ESET. This installer is responsible for firing up the infection chain leading to a variant of Korplug RAT.

Similarly, we’ve found similarities to operations attributed to LuminousMoth both in structure and purpose. For instance, we have seen a very similar structure as the one described in Bitdefender’s research on the LuminousMoth group. Namely, the usage of the same binaries for sideloading, same pattern for exfiltration – using RAR for collection and a sideloaded library for exfiltration via Google Drive. Perhaps the most common pattern was the usage of a USB launcher written in Delphi that was attributed to Mustang Panda, which was also described in Bitdefender’s research.

In some cases, we have seen some unreliable links to older campaigns such as Operation NightScout, a rather old KMPlayer supply-chain attack, or Operation Harvest. Namely, binaries used for sideloading or names of encrypted payloads matched the ones used in these old campaigns. Nevertheless, the specific payloads differ significantly, so while some of these were attributed to Mustang Panda, the similarity could also be coincidental.

Toolset overview

The storage we have discovered contains many archives with various tools to be downloaded by infected victims. We will use names of these archives to impose basic structure on the data we have found. It is worth noting that these names are partially consistent in successive versions. For instance, we have found an archive KKL which was later on accompanied by another version with a slightly different configuration called KKL1.

Some archives contained complete toolsets, whereas others only had single purpose tools in them that were meant to be used in connection with other tools; for instance, one contained a keylogger that obviously lacked any exfiltration functionality. This provides a strong indication that the tools are intended to be used modularly. We will build upon that and first talk about the usual Mustang Panda theme – Korplug. Then we’ll get to the more specific tools and end with the single purpose tools. Notably, nearly all the tools, aside from Korplug, its loaders, and Delphi installers, haven’t been described before. The RAT written in Go (JSX) or the  modular backdoor (US_2) deserve an extra mention due to their complexity 

From the data we have seen, we conjecture that the main exfiltration tools are variants of tools contained in archives named GDU, which use Google Drive for the exfiltration. Since we haven’t seen any exfiltration tool that uses the distribution point directly and the path on the server of exfiltrated files contains gd, we presume that the responsible group uses some other tools to move files from various Google Drives to the distribution point we saw.

A brief look at the toolsets brings up another interesting fact: almost all the files show approximately (up to a few cases within seconds) a seven or eight hour offset between the compilation timestamp and the “last modified” timestamp of the file itself. Since the compilation timestamp is usually in UTC and the archives use the local time for the contents’ last modification date, this places us at UTC-8 and UTC-7. Therefore, we presume that the build setup operated in a time resembling Pacific Standard Time (PST) and Pacific Daylight Time (PDT), used on the West Coast of the United States. There are a few caveats – SE3 and SE4 contain files that were compiled on November 1, 2021 and still have an eight hour offset even though none of the countries using PST/PDT transitions to PST that early (both USA and Canada transition to PST a few days later).

There is also a file with an obviously spoofed compilation timestamp. HT3 contains a DLL Vender.dll whose compilation timestamp dates more than a month after the last modification date. This further weakens hypotheses that build upon timestamp offsets. Unfortunately, we have no further leads explaining this outlier. The latest version of the uploader (multiUpload.exe), whose usage was spotted at the beginning of June, has a compilation timestamp of January 3, 2020. This is also very likely spoofed as analyses of the previous versions of this tool show clear evolution and, according to their respective timestamps, they were all compiled in April 2021. Not to mention that the corresponding infrastructure was only created at the end of May 2022.

The folder /pub/god, which contained the toolset archives, was removed on June 25, 2022. On the same day, a new folder /pub/god1 was created with two files to which we didn’t have read access. Two days later, the new folder was gone and /pub/god appeared again with a subset of the original tools.

Variations on Korplug

The first group of tools that we’ll introduce are various versions of Korplug. The binaries used for side-loading were already seen before. Even though the loaders were mostly new, they were rather uninteresting. A common theme was a Delphi binary that served as a launcher to be executed from an infected USB drive. As we’ve already mentioned, a similar installer was previously seen in campaigns attributed to Mustang Panda. It just executes the Korplug loader from a folder named “Kaspersky” that is on the very same USB drive. See the diagram below (based on a toolset from an archive named BMD) for more details. 

Note the usage of the folder name “Kaspersky” and usage of “Symantec” in the names of the executables; since the launcher relies on social engineering tricks, it depends on a common strategy using seemingly legitimate file names to dispel any doubts concerning the content.

Contents of an archive called BMD. Archive YK41 follows the same structure, with ShellselDb.dat being replaced with hp_ui.xslbcdsj and without the Delphi launcher.

There were also simpler infection chains, containing just a signed clean binary, a loader to be side-loaded, and an encrypted Korplug. These were contained in archives WD, 127C, and 1260M. The latter interestingly used the OleView.exe binary which then side-loaded the ACLUI.dll that decrypted and executed ACLUI.DLL.UI. The same signed binary, which surprisingly also has the same name of the encrypted payload, was used in the KMPlayer supply-chain attack in 2013. The accompanying research was only published in Chinese, likely due to the attack being limited to a few devices.

Exfiltration toolset

The exfiltrated data on the server in /pub/gd folder showed perfect correlation to the data produced by GDU toolsets (GDU_OLD, GDU, GDU1, GDU2, GDU1_NEW, GDU3, GDUPIZ). These tools collect the files on the victim’s disk, pack them into an archive whose name is prefixed with the victim’s ID and upload that archive onto a Google Drive. We presume that the name GDU is an acronym for Google Drive Uploader. While the tools themselves were technically rather simple, the exfiltration process and their evolution piqued our interest.

The analysis of the exfiltration process brought up several interesting observations. A few days after May 24, 2022, the day we started systematically monitoring Google Drives used for the exfiltration, we started to see more frequent token changes and new features being implemented. These features mitigated possible downtime caused by the migration to a new token. Since Google Drive has extensive logging functionality and the tokens have to be present on the infected devices, it is only a reasonable expectation that access to these drives is monitored to some extent.

On the contrary, we have not seen such behavior with the distribution point. This could be attributed to the fact that the distribution point is never exposed by the toolsets, which brings us to the assessment that the group presumes the distribution point to be secret or not worth monitoring.

Timeline of GDU exfiltration toolsets

Version overview

The oldest version GDU uses RAR executable to collect the data and an encrypted rar.dat to store parameters for the RAR binary. Starting from GDU_OLD, they migrated to their own collector piz.exe (this functionality was later moved to a DLL to be side-loaded) and retained an encrypted rar.dat where they stored their configuration. These toolsets also rely on two optional configuration files that are backed up by hard-coded values: token.dat containing an encrypted token for Google Drive and time.ini that contains last execution date along with the victim’s ID. The setup and the choice of binaries for side-loading bears resemblance to the LuminousMoth campaigns and tooling.

An archive GDU that contains a version relying on RAR instead of piz.exe for data collection.

The exfiltration process is usually handled by a variant of MyUpload.dll that is supplemented by the aforementioned configuration files. Quite recently, a new version of GDU1 has appeared on the distribution point (which we’ll call GDU1_NEW)  which came with its successor multiUpload.exe. multiupload.exe eschews hard-coded tokens and makes the exfiltration process more resilient to disruptions.

Archive GDU_OLD that uses its own collector piz.exe to collect potentially interesting files before the exfiltration.

The version we are calling GDU_OLD is basically the same as GDU1 and GDUPIZ, the most significant difference being a different PE being used for side-loading. GDU1 and GDUPIZ rely on CefSub.exe and subsequently on CefBrowser.dll instead of AtlTracetool.exe. GDUPIZ also uses a slightly different approach to execute the file collection tool piz.exe – the version included in this folder is in fact a renamed clean binary spoololk.exe which in turn side-loads vntfxf32.dll. This malicious binary implements the file-collecting functionality formerly contained in piz.exe. GDU2 is basically the same as GDUPIZ.

On June 8, 2022, we saw a new GDU1 toolset on the distribution point. This time MyUpload.dll has been upgraded to provide redundancy in the exfiltration process. It no longer uses token.dat but rather uses a Github repository as its source for the token. If this fails, there are two backups – one using HTTP PUT to www.watercaltropinfo[.]com with Basic HTTP Authorization (123:123). The other sends the data via HTTPS POST to m.watercaltropinfo[.]com. The collector is the same as in GDUPIZ. GDU3 uses basically the same process but uses different PE for side-loading (FwcMgmt.exe).


A special chapter is devoted to Google Account tokens that are used in these tools, partially because our research may have forced the group’s hand to refresh the tokens once they discovered that we knew of their Google Drives. The fact that after each token decommission, every client had to have the token updated and that GDU toolsets do not have any remote update functionality suggests that these toolsets have to be accompanied by other tools that provide this update functionality. We have noticed a longer delay between the decommissioning of the token from May 29, 2022 and before a replacement token was being distributed. Its distribution coincides with the time a new version of GDU1_NEW was released. It’s exactly this version that has introduced new functionality in the exfiltration tool, namely smoother token swapping and failsaves for cases when Google Drive exfiltration fails. Therefore, we presume that this delay was caused by the development of this new functionality.

Source Refresh Token Metadata
GDU/GDU_OLD 1//030YFi1XWWVY2CgYIARAAGAMSNwF-L9Ir_I6Aqhg4gn3UWyi3I5J_6q4VxHPYNkit3x9RtlpVkFCEOD4KU-E2u7NghS0hx5nPU8Y First seen: 22.4.2021Not accessible
Distribution point 1//0clbh_CVKereiCgYIARAAGAwSNwF-L9IrtPxC9zt-onaeeq2gTUwZTVa8f8ILvDYM8dyVVjmmKmNr5Pnsi27iMjLll2dxbDRxUQs First seen: 22.4.2021Not accessible
GDU1/GDU2/GDUPIZ 1//0cZLNy7GH0LknCgYIARAAGAwSNwF-L9IrV7aXKTZb-WQM1aqXkjX0ph25dTZngOYAUlAXHB1NvCorgw62XI_TXsWNrK98KBYfbpA First seen: 17.3.2022Our first access: 24.5.2022Usable until: 26.5.2022
Distribution point 1//0e29aixufumhCCgYIARAAGA4SNwF-L9IrX2w0GnjBQe4g5hQWKJlXjIQF7XZBnQ9VKArYhJVwOayZq9Ad-G8YHbsptTN5DhfXI2E First seen: 29.5.2022Our first access: 29.5.2022Usable until: 3.6.2022
Github 1//0ewRnXWCf2AunCgYIARAAGA4SNwF-L9IradANDPAvIqPOaIfReqT1fQ0GO5A9FnUhdpdI0Q0V1IRye5RbTi-hcGQbbHKgDc02xfM First seen: 8.6.2022Our first access: 8.6.2022Still usable

Temporal analysis of exfiltrated data

We can also have a look at the metadata of the exfiltrated archives. What is rather unsurprising are the upload times which closely coincide with Burmese business hours – a smaller peak in the morning and a huge peak in the afternoon. Note that Myanmar is in UTC+6:30 time zone and China, presumed land of origin of Mustang Panda, is in UTC+8.

What is more interesting are events produced by the group itself – transfers from Google Drive onto the distribution point and deletion of files from the distribution point. The huge peak is around 18:00 MM time which coincides with the end of the work day in Myanmar. The spread of starts of upload windows is negligible, leading us to the presumption that the transfer is automated. We have seen a few archives being placed in the wrong directories which could indicate that the tooling is still under development or there’s still some manual work involved… Usually, the files have accumulated during the day on Google Drive and were transferred to the distribution point in the evening MM time.

As we already mentioned in the introduction of uncovered tools, we have found quite a lot of files that were “missing” something. By that we mean that on their own, they were either lacking communication functionality or implemented some techniques that were useless without being accompanied by another payload. Interestingly, while these were also using side-loading, they were not relying on external encrypted files, making their execution flow straightforward with 2-point graphs. For the sake of brevity, we will list these in a table:

Archive Clean executable SideLoaded DLL Purpose (high-level)
MG/MG44 dabs.ex/44.ex SensorAware.dll fingerprinting/remote shell
AUD mcsync.ex mcaltlib.dll audio recording
CHR browser.ex browser_elf.dll Cookie dumping
T3YK ygfdt.exe corecrl.dll remote shell
UC melt_64.exe libmlt-6.dll UAC bypass
KKL/KKL1 mscorsvw.exe mscorsvc.dll (contains KBE.dll) clipboard stealer, keylogger
Archive KKL contained a straightforward stealer in KBE.dll that was also hard-coded (in an encrypted form) in mscorsvc.dll from which it was unpacked after side-loading. The newer KKL1 was practically the same.

There are also a few standalone files such as x.ex in archive X which composes logs of registry entries (Run), services, and scheduled tasks along with checking all signatures of executable files in %WINDIR%. Archive NB contains nb.dat which is just the nbstat utility executable. There was also a coinminer in the archive INFO along with its encrypted configuration file.

An interesting utility is DISK2 (and its variant DISKM); it is responsible for monitoring the system drive for any changes. Both are accompanied by a configuration file that defines which files are of interest and where such files should be copied to. It also notifies its C&C server about these files via an encrypted message over HTTP. There is also a version of this tool named MF20211228 that does not contain any configuration file and does not copy files anywhere, it just sends messages to the C&C server.

Contents of an archive DISK2. This toolset is responsible for monitoring the system drive for any changes in files defined by its configuration.

Oddballs in the collection


JSX archives (JSX86 and newer JSX861 for 32 bit version and JSX64 and newer JSX641 for 64 bit version) deserve a separate mention as they use a rather uncommon setup; a JavaScript file is at the beginning of the chain and instead of side-loading, the respective DLL is launched as a service. mozload.dll is a RAT written in Go that uses HTTPS and websockets for its communication. Interestingly, the RAT uses TLS Client Authentication; see Appendix A.1 and Appendix A.2 for the private key and the certificate.

The execution flow of the packages from JSX archives.


HT3 simply does not fall into any of the previous categories – it is a backdoor with external configuration accompanied with a shellcode loader and UAC bypass.

Execution flow of HT3. Note that it contains both 32 bit and 64 bit versions of an UAC bypass tool.


Now we are finally getting to a more complex setup. These archives include several versions with very similar structures and sometimes with varying payloads. Functional changes are presented below; note that these do not include changes in side-loading which will be discussed later on. All versions feature a few evasion tricks that use registry tricks to hide files and file extensions.

Version Version changes
SE1 Uses volume name for USB installer executable
SE3/SE4/SSE Uses Delphi launcher (the one attributed to Mustang Panda), persistence integrated into LPVDPOCX.OCX (equivalent of facesdk.dll from SE1)
SE5 Uses volume name for USB installer executable, rollbacks to old USB installer
SE6 No significant functional changes
SE7 No significant functional changes

SE3 and therefore also SE4 and SSE (which are mostly the same) use vivaldi.exe and vivaldi_elf.dll for its evasion module. Also, FacialFeatureDemo.exe and facesdk.dll are replaced by Symantecs.exe and LDVPOCX.OCX; the latter integrating persistence into itself instead of having it in a separate module. Interestingly, the USB installer has been replaced with one similar to the one in the archive BMK; a Delphi launcher that executes Symantec.cmd which is actually Symantecs.exe. These versions are also the only ones that have renamed 3 of 4 payload bundles (using csdkset.dat for backdoor, EdrEpmpCStorages.dat for USB installer, and PchEpmpCStorages.dat with WTSAPI32.dll). Confusingly, WTSAPI32.dll does not seem to be used anywhere and will be used for side-loading by later versions when the USB installer replacement is roll-backed.

SE6 and SE7 abuse old Avast’s proxy executable wsc_proxy.exe to side-load wsc.dll which serves as the dispatcher. Aside from this change, there are no other significant changes to the functionality.

The schema of contents and the control flow of SE1. In newer versions, the persistence module is integrated in the dispatcher.


The last complex toolset that we will present is from the archive U5_2. Most of the functional code is encrypted and bundled in With the exception of a  chain to a removable drive watcher, all the parts share similar XOR keys: user_panda_%section_name%; a rather interesting choice if the toolset really belongs to Mustang Panda.

An interesting part of the toolset is a file install_.exe that reads a file from a given path, takes the serial number of the volume where the file is located, computes MD5 hash from the serial number and changes the  first bytes of the file to the hex-encoded computed hash value.

The schema of contents and the control flow of U5_2.

Server infrastructure

The distribution point is an FTP server located in Malaysia that is accessible without a password (username anonymous, password is empty). We have also encountered a different FTP server in late 2020 containing very similar archives to the ones we now know contain exfiltrated data. Unfortunately, we did not have enough information to process the archives it contained. We presume that these two FTP servers were closely related or that even the current FTP server may be successor of the one we found previously.

We have noticed that the FTP server has stopped responding in October. Fortunately, the server itself was still alive and the distribution has migrated to using HTTP instead of FTP. They also started using HTTP Authorization; nevertheless, they have reused a weak username:password combination (123:123). This has caused a downtime of a few days in our tracking, but with a quick fix, we’ve managed to get back on track. Presumably, this might have been another attempt to foil our tracking attempts.

Our telemetry data also revealed another server in Russia. A client from Myanmar tried to download an archive XYZ from it via HTTP. Upon further inspection, the archive was found to be identical to XYZ from the aforementioned FTP server. We have tried to crawl the server for archives and files we have already seen on the FTP server and found the following toolsets:

Archive on the HTTP server Matching archive on the FTP Note
gdupiz.rar GDU Retrieved from our telemetry
xcrs.exe X Discovered by crawling
jsx861.rar JSX861 Discovered by crawling

The fact that the affected client is from Myanmar, and the fact that the server contains some parts of the described toolset strongly indicates that it is part of the same campaign. Nevertheless, since at least one archive was renamed, we were unable to fully enumerate its contents. Similarly, we were not able to verify whether the server contains exfiltrated data.

C&C infrastructure


The JSX RAT attempts to communicate with 103.169.90[.]132 using TLS client authentication. The certificate (see Appendix A.2) is hard-coded and we can try to use it to confirm related infrastructure. Looking at the server certificate data, we see that it imitates a real hosting company.

Common name:
City, country:      San Francisco, CA, US
Fingerprint (sha1): e0adf667e287b0051988dda2b85e7541d7532703

Interestingly, the C&C’s certificate had the exact same subject as the client certificate. Searching for other servers that use the same certificate yielded a couple more servers. Furthermore, we were able to confirm that the majority of these servers are running the same C&C software because they accept the RAT’s hard-coded client certificate.

A server at 118.31.166[.]5 seems to be an outlier among these servers with port 4433 being exposed. Since it is the oldest one using the same certificate and the server exhibits the same communication traits on that port, we suspect that it might be a development server.

Two of these servers were open to RDP connections with a certificate that had o9c[.]pg as its CN (Common name). We tried to go further using these certificates to uncover further candidates for C&Cs. The timeline of uncovered servers is below:

Timeline of servers using the discovered certificates. Blue ones use a certificate with blue[.]net CN, red ones use o9c[.]pg as CN, purple ones have both. The highlighted line corresponds to JSX RAT C&C.

These are servers using the same certificate:

IP Geo Notes
103.169.90[.]132 MY Original C&C Ports: 443, 22, 53, 3389
45.79.409[.]10 US Suspected RAT C&C on port 443
118.31.166[.]5 CN Suspected RAT C&C on port 443, different response codes
181.215.246[.]173 MY
39.104.52[.]188 CN Suspected RAT C&C on port 443
45.56.90[.]127 US Suspected RAT C&C on port 443
154.204.176[.]249 HK
47.244.2[.]17 HK Suspected RAT C&C on port 443, RDP
47.96.236[.]105 CN
134.122.129[.]170 HK Suspected RAT C&C on port 443
172.105.158[.]102 US Suspected RAT C&C on port 443, RDP
192.46.213[.]63 IN Suspected RAT C&C on port 443
Overview on the servers with ties to JSX RAT C&C.

These are RDP servers sharing the same certificate as the two C&Cs with open RDP port:

IP Geo Notes
47.75.123[.]100 HK
47.242.171[.]26 HK
47.57.87[.]221 HK
172.105.118[.]92 SG
172.105.159[.]130 US
47.244.2[.]17 HK Is also on the previous list.
47.242.95[.]126 HK
8.210.16[.]197 HK
172.104.92[.]7 JP
45.33.34[.]11 US
45.79.102[.]41 US
47.57.108[.]231 HK
194.195.240[.]87 DE
47.56.65[.]198 HK
8.210.128[.]37 HK
172.105.158[.]102 US Is also on the previous list.
47.57.110[.]128 HK
47.242.6[.]26 HK
23.92.26[.]127 US
47.75.183[.]119 HK

Other C&C servers:

Folder Geo C&C Notes
DISK2/DISKM/MF20211228 RU 188.127.249[.]169 Stealer
HT3 MY 45.121.147[.]172 Korplug
JSX MY 103.169.90[.]132 RAT
MG/MG44 SG 23.106.122[.]81 Remote shell
SE4/SE5/SE6/SE7 SG 91.245.253[.]72 Backdoor (ZIPDLL.dll)
SEE MY 103.91.66[.]116 Backdoor (ZIPDLL.dll)
T3YK MY 111.90.148[.]95 Remote shell
U5_2 MY 103.117.141[.]202 RAT
1260M US 45.134.83[.]4 Korplug
GDU1_NEW/GDU3 Encrypted Google Drive token


It is not very often we stumble upon such a stash of samples that is used to distribute malware to infected devices; especially when we are talking about tools that are strongly correlated with a notorious APT group. We have shown links to multiple previously published research around campaigns both using tools and TTPs, providing us with high confidence that the threat actor in question is Mustang Panda.

The exfiltrated data indicates that the toolsets that we have found were actively used around Myanmar. For instance, we have found audio recordings that corresponded to the audio recording tools we have identified in the archive named AUD. Although many tools were simplistic in their nature and sometimes also in chosen obfuscation methods, some archives contained tools which seem to deserve further analysis; be it due to their complexity or technical implementation.

What was really surprising was the sheer scale of the compromitation. We have identified many high-profile government targets, some opposition entities along with a few NGOs. It is worth noting that given the sheer volume of data and the language barrier, we have only been able to associate some of the victims with a specific organization. This means that the list of targets is likely incomplete and should be considered as approximate. Nevertheless, the daily rate of gigabytes of exfiltrated data should be enough to give a strong hint on the scale of the operation.



Folder C&C Notes
DISK2 188.127.249[.]169 Stealer
HT3 45.121.147[.]172 Korplug
JSX 103.169.90[.]132 RAT
MG/MG44 23.106.122[.]81 Remote shell
SE4/SE5/SE6/SE7 91.245.253[.]72
Backdoor (ZIPDLL.dll)
SEE 103.91.66[.]116 Backdoor (ZIPDLL.dll)
T3YK 111.90.148[.]95 Remote shell
U5_2 103.117.141[.]202 RAT
YK51LOW mod.mmgpms[.]com[.]com
1260M 45.134.83[.]4 Korplug
GDU1_NEW/GDU3 Encrypted Google Drive token

Certificates and keys

A.1 JSX private key


A.1 JSX certificate



Archive Binary DLL
BMD,YK41 Symantec.exe SHELLSEL.ocx
YK41LOW GoogleUpdate.exe SbieDll.dll
YK41LOW atkexComSvcRes.exe CefBrowser.dll
HT3 x.exe Vender.dll
GDU Samvd.exe SmadHook32.dll
GDUPIZ vsgraphics.exe vsgResources.dll
GDU1/GDU2 CefSub.exe CefBrowser.dll
GDU2/GDUPIZ/GDU1_NEW/GDU3 piz.exe vntfxf32.dll
GDU_OLD AltTraceTool.exe atltracetoolui.dll
GDU1_NEW/GDU3 NitroPro.exe CefBrowser.dll
GDU3 piz.exe FwcWsp.dll
WD  HP.exe HPD.dll
DISK2/DISKM/MF2021188 HPCustPartUI.exe HPCustPartUI.dll
127C OleView.exe ACLUI.dll
KKL/KKL1 mscorsvw.exe mscorsvc.dll
MG/MG44 dabs.ex/44.ex SensorAware.dll
AUD msync.ex mcaltib.dll
CHR browser.ex browser_elf.dll
T3YK ygfdt.exe corecrl.dll
UC melt_64.exe libmlt-6.dll
1260M upservice.exe breakpad.dll
U5_2 HPCustPartUI.exe HPCustPartUI.dll
U5_2 PlugInInstallerUtility2.exe PlugInInstallLib.exe
SE1 FacialFeatureDemo.exe facesdk.dll
SE1 %volume_drive%.exe MSFTEDIT.dll
SE1/SE7 GUP.exe libcurl.dll
SE1 spoololk.exe WNTFXF32.dll
SE3/SE4/SE5/SE6/SEE vivaldi.exe vivaldi_elf.dll
SE6/SE7 wsc_proxy.exe wsc.dll

File hashes


1ded7b4cab302bc7229c92723056d07d5bd9563e88fe082da0a396942fba5958 breaklog.dat (Korplug)
2895fdac192a4b0ffd70b6b207d49cd7c8f68945eb5c09e3d51e2fded6c6c32f breakpad.dll (Loader)
ce13248fa2da5b27773f855c2dd0c6ce276b4a10b020e4da57bc47ab0fe07eae upservice.exe


1769c7778cbcd937ae317f4982f404b0d7ae7ee5e2b2af4efb160c5233a8f476 ACLUI.dll (Korplug)
8ff84f79455b84bd73e7c0641532a60e8132599c29d3f85fb54f3d7da53e1817 ACLUI.DLL.UI (Loader)
91f6547bceddfb2f241570ac82c00de700e311e4a38dea60d8619638f1ed3520 OleView.Exe


cd6bcf240de87fe3f1b5a6a24db1b2728acad5f7bcfe124e5bc2d7bdac2f64a9 mcaltlib.dll (Audio recording)
075f9dfb6ab3379f69165c03991abf1a969ca0c21e04564543564dc536ea95dd mcsync.ex


55eacabb7c054355d2e8c3a82c075338c9ac642d86ee5d3fa1fca3f621e43cb2 SHELLSEL.ocx (Loader)
d139940023fa2c602e2a31faa807b9df074f34747511bd61db961d20155b8c84 ShellselDb.dat (Korplug)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe
491d9f6f4e754a430a29ac6842ee12c43615e33b0e720c61e3f06636559813f7 SymantecHp.exe (Launcher)


4063cf4ba2d4e12c277479399d4489e45a48b1013d8d54b5a589784fe7158978 browser_elf.dll (cookie dumping)
12b15f31f295416417f1e028904a4e10a0c8ec39dd00bac7df4887c194f2865b browser.ex


8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe (Sideload)
7ea21215968c43f9fe28f94926e3547f2f7a0e35cdf40392b0b6aea80fe11314 HPCustPartUI.dll (Stealer)
c9121c7874d2fd88ff7af35eb3f3cd18ab7162390db008043037383cdad6ff56 HPCustPartUI.log (Ecnrypted stealer config)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll


8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe (Sideload)
788fe764f6f5e0fff31b06fd8b94ee0cf51a3082c1321d8db96708c2a6abc3ee HPCustPartUI.dll (Stealer)
62d770f240cecebd6cf725df05ab1e863d83895abc9396664a6090dbcc983d6f HPCustPartUI.log (Ecnrypted stealer config)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll


d12a1750980ef3943c6d7e152948059261944b8afe06b8a280b7fbe61aba3c9b rar.dat (Config)
e64b533d60a21ca8ddbfcf8a1b154ed351383b0196d534bf229101a6cc4d1931 rar330.exe (RAR)
def8fdb95bb53514698b9df1c64e329adfca59adf2e898c3daab16f1e4760bc6 RarCon.SFX (Exfiltrator)
4f54a6555a7a3bec84e8193d2ff9ae75eb7f06110505e78337fa2f515790a562 Samvd.exe
375e88d1f38604c901f2b9fd5b9ada4c44c1f4c172f7cd58cd67e9248ff966ab SmadHook32c.dll (Loader)


197d0ad8e3f6591e4493daaee9e52e53ecf192e32f9d167c67f2ffb408c76f2c AtlTraceTool8.exe
33f631c0b561199b5feb9020faa99e50efa9f421d7484ffa640c5561494726da mfc110u.dll
45a61f4b7e5798f1389a7d6abc8a924c37db6f51552b4cafc901e7e4a50dabc6 msvcr110.dll
db75b25b69b7b6f3206226461d8bde7c05049922dc463e8932d11710fad74833 piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)
0dcaf08b7b1f8de3999af567144b13f36bea3a68f46f81f8443a81a50a86a09c atltracetoolui.dll (Loader)


2c17b68040dda192939e4b7f65b2935cb6c467b8a4b2c3d512bde6cc5a60adaf cache (Exfiltrator)
e412569c23722c469ee533efb62bbded53d1909b58c8cf7bff9897c466c9df9a CefBrowser.dll (Loader)
cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 CefSub.exe
beb44eadd141b7ae46e40e1bf888c302cb7096826e772f0b20ce6f213c69058d piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)


2c17b68040dda192939e4b7f65b2935cb6c467b8a4b2c3d512bde6cc5a60adaf cache (Exfiltrator)
e412569c23722c469ee533efb62bbded53d1909b58c8cf7bff9897c466c9df9a CefBrowser.dll (Loader)
cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 CefSub.exe
390d75e6c7fc1cf258145dc712c1fac1eb183efccee1b03c058cec1d790e46b1 piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)
869b8dd87e402049eae435de3de1e15a021d9fcbf79a20be3b030d3782599903 vntfxf32.dll


59cf961f7316656e73b269a86b04836a7a7254f021a8a3132a927b02373225d6 AUG.json (Encrypted and compressed data)
091408cdd56267bc4fb4cb54f2d91701aa8cdcede334a648566eea89f1682925 Vender.dll (Loader)
00bfbbe6e9d0c54312de906be79cc1e9f18b2957856a1215eaff1ac7bb20e66f x.exe


c617016fb8809655f9189648b9b41a727c0b49cdb79a28f13f710d23f3527a64 install.js (Executer)
21bf4631775b6c17f9e94c0901ffbb7718a0e6094582bcb1683b934aca24e18f mozload.dll (RAT)
f4a31d15cd5aa3441e5e31c1add6e0c3551a1aad5abb75f0abd76990f2824acc scx.exe (Installer)
645ee3601aea4c1af8b938f64698bf6c5978b1151aef53e183bb768791c927e2 svchost.dll


73903c2c46b5055380fc2a238c96f7f2ca2a5acf1cd1e568b2d2be0638c68fd1 install.js (Executer)
50bee35c965a99b3f8f722296e4ed6474ca62d96ea5fc4897e7d1563ed173d5e mozload.dll (RAT)
e27bfbe87c78945b1d79fc027c3f0a27a07d0dddc742783bf686c1a8133a2f48 scx.exe (Installer)
8cebfe33cd69747cc1333fe598d9b0331103e0869d6f1b1f75e28b3b8f11243d svchost.dll


c617016fb8809655f9189648b9b41a727c0b49cdb79a28f13f710d23f3527a64 install.js (Executer)
fd1ec183124d2d82dae1dd228de88440bc142cf6430c9c93518e25f1dde052fd mozload.dll (RAT)
9e3788cacb3d38e4e15da7e4887650efa6a3b17a65a314fcb4e059d9f88481a8 scx.exe (Installer)
5e8311c26091839a292e2d12f88378f8093fc739ced86aa1e9ba1b707ad516d8 svchost.dll


73903c2c46b5055380fc2a238c96f7f2ca2a5acf1cd1e568b2d2be0638c68fd1 install.js (Executer)
f9d94c1dcdbcefddb4f1d47291422c6198fd11052aea761acf8b5755802ca922 mozload.dll (RAT)
49a81878ec282c3c9d4dd72920d9283e2c86d0bb96b468e010901b3f4f9c75ed scx.exe (Installer)
79440abf29d1b56cb1c95a12f554fe052e21a865fea56a025e216f342ffbccbd svchost.dll


fae5b61723106d44de46b3ec49e80067f63f82f09501142186984a658bc99c38 KBE.dll (Clipboard stealer, keylogger)
ed6b3af0edcd3b57c0616e1b7819b5e1c1e72327300172ff2664b158f65861b2 mscorsvc.dll (Loader)
0809e3b71709f1343086eeb6c820543c1a7119e74eef8ac1aee1f81093abec66 mscorsvw.exe


4afa4582975d31144b3af692f123f87b6400a45475e41fa1822c7acdb17590f0 KBE.dll (Clipboard stealer, keylogger)
9af8336050c40105864bf9314355471494dc631fd88a0b444291b63b941b7822 mscorsvc.dll (Loader)
0809e3b71709f1343086eeb6c820543c1a7119e74eef8ac1aee1f81093abec66 mscorsvw.ex


8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe
9f1d1a94026c54396a4c0b6327d317836dc9dc67178810428302efcbf5225a42 HPCustPartUI.dll (Stealer)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll


473b4f8b8640a68d1092f6b54b521c6b0ccb1c567eca4a18a2c2da3481bc027a dabs.ex
cfe1447e7515ad831fcfedb9a5c1a721885b0542b775e4028a277a27e724ec73 SensorAware.dll (Figerpring, remote-shell)


473b4f8b8640a68d1092f6b54b521c6b0ccb1c567eca4a18a2c2da3481bc027a 44.ex
cfe1447e7515ad831fcfedb9a5c1a721885b0542b775e4028a277a27e724ec73 SensorAware.dll (Figerpring, remote-shell)


c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e nb.dat (Nbtscan)


8364bae4e2951957403cbe3a78362edb7d41c34f49c81f0336fcb28d1510d5e1 facesdk.dll (Dispatcher)
0d243cbcd1c3654ca318d2d6d08f4e9d293fc85a68d751a52c23b04314c67b99 FacialFeatureDemo.exe
e5bbbf34414426f63e6cd1354c306405e54bf31279829c7542dccfb7d85af0ec GUP.exe
92717951aae89e960b142cef3d273f104051896a3d527a78ca4a88c22b5216a5 gup.xml
7e1c49d45935fb5d20add5baf60400fb64fbf0299a3af3b0be764b2d265e368a libcurl.dll (hides malware files)
390d75e6c7fc1cf258145dc712c1fac1eb183efccee1b03c058cec1d790e46b1 spoololk.exe
abf7bb6eb92f2f358e8e57c1be03efe5a7f81e3d3eb4134257c3483e9e7782c0 VNTFXF32.dll (persistence)


1a4e92e09957578cc8d8c1fbdaba55e306e7bcbc6208ee00e33bb37e849156f9 aweu23jj46jm7dc
13cf1c57f1c143c592173b1e91ddb652d5dd1c2015289ac890a37253058b54be bjca3a0e2sfbs
12acd296a009d9e8fbd9511d3c0586f331d450b9c12f651e0554764e50cfb7e7 sf24acvywsake
4a6ed717a2d7f0953e4b25c2652c9a231146f60b35d9a5e3cf782c772727b1bc sf33kasliaeae


61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecs.exe
a8f3bc45ac0dcf351c028ecabfd68e8e551cd97f8dc0fc6e62e135668cde9277 LDVPOCX.OCX (Dispatcher)
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe


51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
6ded96d7609cc085db57764c40a38379cba50b965f959650ca8d1605ae0411e8 csdkset.dat
a8f0dff3c57621282a1262ddaa559f055f2f2cc717a7695d8bfbf7a6898b843c EdrEpmpCStorages.dat
7659be61fc1e16c4721b451225ec7c8f932e9e7357894ddea3a4ada9583996b5 PchEpmpCStorages.dat
9015378ed6d7537f07e61c78b3c35766d63465970b63d13c9b447dc8bb90e2d7 prodcltdef.dat


61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecs.exe
01cd1530b0db54c834ef275e0cc617645a23e1f250bc35c248d546c28da220fb vivaldi_elf.dll (hides malware files)
9fb4c9f1995b02ece99b62a4efc0df5c916a1858f57730225f3c419fce0de24c LDVPOCX.OCX (Dispatcher)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe


51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
01cd1530b0db54c834ef275e0cc617645a23e1f250bc35c248d546c28da220fb csdkset.dat
baaaffe80060fb89b06ff19dfb6c76835fc6639d81513e2d9e49716f1816ccc4 EdrEpmpCStorages.dat
9fb4c9f1995b02ece99b62a4efc0df5c916a1858f57730225f3c419fce0de24c LDVPOCX.OCX
f488e4e838fa447c9b08fc74d4180faeb465f9070c443625b7515aed7c282fa6 PchEpmpCStorages.dat
ab89d614923b92ce2eb7ed48357b2d1755b8a8f572ead3b32bb63a79e259186d prodcltdef.dat


5828fd07716140e5fefec1b07751378d9b76952e66b2c0fb0a860313d4030b4d LDVPOCX.OCX (Dispatcher)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecsy.exe
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe


e6fdd0d22abe3484d57715bd83143e5810b74f3f9dc8780344c66af2c0894d76 aweu23jj46jm7dc
50814a35a9d157405252c8ba52c12d1cf5adf137598173c6522cbe058e14b7ff bjca3a0e2sfbs
1d68f4afd0fd908d35db6d9710ab2fc92fb5ca739d6351e1bf513e068fbd00a0 sf24acvywsake
5427cd51f0120a27ed75d3ac27d6f8eac6f27c54d8658236a52a281d6433496b sf33kasliaeae


a67094334ae2135e50bf2074f08d3a99075a53a174da6bdf22eca54293bb8e9b vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe
bd4635d582413f84ac83adbb4b449b18bac4fc87ca000d0c7be84ad0f9caf68e wsc_proxy.exe
e0c240f5776d158da7529d8c0e3d5be4d6f007e51e4be570e05b744d0452011d wsc.dll (Dispatcher)


51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
7620acb11f0471515079a69ee2cec0cd74485fb13c779d41c2b43b87718c63ff aweu23jj46jm7dc
3fc3fb81a43b9ac155e42367769eb5c0d6dd08c06a025ba93697c6b2667bf1e7 bjca3a0e2sfbs
f2c5004450a749bef14ee779e1c8e4c08702f089248d0a282e6a679d29b0996d sf24acvywsake
10d58013b8a34e10e8548b016154963097dcff15e5673bf24e8ed18513ad4a64 sf33kasliaeae


e5bbbf34414426f63e6cd1354c306405e54bf31279829c7542dccfb7d85af0ec GUP.exe
92717951aae89e960b142cef3d273f104051896a3d527a78ca4a88c22b5216a5 gup.xml
7e1c49d45935fb5d20add5baf60400fb64fbf0299a3af3b0be764b2d265e368a libcurl.dll (hides malware files)
bd4635d582413f84ac83adbb4b449b18bac4fc87ca000d0c7be84ad0f9caf68e wsc_proxy.exe
e4ddf5af63fdfe85c5a4573d4768699ebdaa5b5b67b7cb6834840c696808a8e5 wsc.dll (Dispatcher)


b7a38292131c131d75413133f101114a1b72bd02e27cc6aea7a836ff964f961f sf24acvywsake
28aadf5b14ba0cb38a33ab53796dba12e7d59479744f0cca225b10be44730b9c sf33kasliaeae
ec56a6fa6804e47f331daee1460c3d07e01fe45edac5d6b1feb01fbbd8396f91 aweu23jj46jm7dc
e32447bd309a6941a1fff4fa559376d9c723afd1b9ce2a1c2dced4b9db6a6f6a bjca3a0e2sfbs


51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
5dafacfa147f087dd0a706cf274e20cbb58f634ba14424d3433efc2e829aa7cd csdkset.dat
b9924c66506ccad566d6c26b8db499e498a9dc840acacb2d8d3bf9d73818814a EdrEpmpCStorages.dat
180a2f3eb004f93590e4fb18cdc3dd6e18815587637ac354ca99f7513aa63633 LDVPOCX.OCX (Dispatcher)
9add5663bc846b4b7cdefcd0e09b882e2f16f755e2e6540efc6ea2072c93f3f2 PchEpmpCStorages.dat
756d1cb0e74b309d53d4f16b043514da128c8b3b89c7d5e46897b61f74bad2d7 prodcltdef.dat
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe


3c0d3783a5ccdecf3786db0053b1352d6fb5a37d9081cc32ec6d5bb611064ce3 coreclr.dll (remote shell)
f11009988b813821857c8d2db0f88e1d45b20762f62a3cf432339f352b12cefe ygfdt.exe


2a971ba79f9f7378e11a47dcafa78e9fe4b1f0c659f7f310209d3e6671d5dc31 (bundled payloads)
9cd8c5d34fd460dd0e240f5e54ade689d808469d6da5e0bd087cc71e6f851c6a core.exe (executes path from config)
caeb48fd04a5fe8b0b4bd32b538ed5f1f303b0487037cf37864f0b5665ff093a install_.exe
2f2a5e5cdb262cd62b43b88bf1e9cfb40a26eac5897616b9eacec4e25d95cbb9 PlugInInstallerUtility2.exe
a90e048c74697775bba2e4c4bfa45d369e44e9a020a83956aa44a50ab8a9a249 PlugInInstallLib.dll


f349183462f1aeac8d3afb43c723af0252c157d376637f30fb7c87fdf80ee965 libmlt-6.dll (UAC bypass)
a23dbce5bcde8ce541b8f326a951d29f6241280d944a1e921ca8658d3d4b65ac melt_64.exe


8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HP
97efd0abf726acfc1a5b4a0b460a727724f43ef9f1e788bada4942d715d4ab87 HPD (Loader)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR1
5f31d558417528b4c635afd6c17347dc393c7dfcecfb79040fe97d9f1abf3776 S (korplug)


28bed0d5bcfb2d5597af881a2be3098327f2d83f14948c6a46cde3cd0776eb1c x.ex (status checker)


edab53d39734965a7cadc2a21662d6a16c9b04b2961dfe9eb76aeda040786e25 hp_ui.xslbcdsj (encrypted Korplug)
071558464f6d067f3044b7ee3819fcb3a049b8be3535043db41123c2fde5d451 SHELLSEL.ocx (Loader)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe


cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 atkexComSvcRes.exe
9bdccd5e4617dfbcaf85228c60703369a8848ad8bb86e00e75e504a26fbe932a CefBrowser.dll
b29b38217921a6b36113049bd9cb4fb2ec52816bff7cd731621ff2fa3dbc7b01 DP45126C.lfl (Decryptor)
90a29c688ce683fb2201145faac00cb44c3d5566697279b68960c6bc3208ae84 GoogleUpdate.exe
fa56ba25861f1b5040afd04bfbfd36353004cd6b2c457971fb01db26ff002f35 GoogleUpdateOnDemand.exe
c9ed69e7bf233ba1edd18a1f91671faee9b7756aa77fe517319098706e78cde5 SbieDll.dll (Loader)

The post Hitching a ride with Mustang Panda appeared first on Avast Threat Labs.

PNG Steganography Hides Backdoor

10 November 2022 at 12:15

Our fellow researchers from ESET published an article about previously undocumented tools infiltrating high-profile companies and local governments in Asia. The tools, active since at least 2020 are designed to steal data. ESET dubbed them Worok. ESET monitored a significant break in activity from May 5, 2021 to the beginning of 2022. Nevertheless, when Worok became active again, new targeted victims – including energy companies in Central Asia and public sector entities in Southeast Asia – were infected to steal data based on the types of the attacked companies.

The researchers from ESET described two execution chains and how victims’ computers are compromised. The initial compromise is unknown, but the next stages are described in detail, including describing how the final payload is loaded and extracted via steganography from PNG files. However, the final payload has not been recovered yet. Detailed information about Worok, chains, and backdoor commands can be found in the ESET’s article Worok: The big picture.

Our analysis aims to extend the current knowledge of ESET research. We have captured additional artifacts related to Worok at the end of the execution chain. The PNG files captured by our telemetry confirm that the purpose of the final payload embedded in these is data stealing. What is noteworthy is data collection from victims’ machines using DropBox repository, as well as attackers using DropBox API for communication with the final stage.

Compromise Chain

We intend to remain consistent with the terminology set by ESET’s research. Our research also has not discovered the whole initial compromise of the malware. However, we have a few new observations that can be part of an infiltrating process.

Figure 1 illustrates the original compromise chain described by ESET. In some cases, the malware is supposedly deployed by attackers via ProxyShell vulnerabilities. In some corner cases, exploits against the ProxyShell vulnerabilities were used for persistence in the victim’s network. The attackers then used publicly available exploit tools to deploy their custom malicious kits. So, the final compromise chain is straightforward: the first stage is CLRLoader which implements a simple code that loads the next stage (PNGLoader), as reported by ESET.

Figure 1. Worok compromise chain
Initial Compromise

The specific initial attack vector is still unknown, but we found four DLLs in compromised machines containing the code of CLRLoader. Our detections captured a process tree illustrated in Figure 2.

Figure 2. Process tree running CLRLoader

This process tree was observed for WLBSCTRL.DLL, TSMSISrv.DLL, and TSVIPSrv.DLL. The mutual process that executes the DLLs is svchost -k netsvcs. Therefore, the initial process is SvcHost introducing a Windows service. The DLL files help us to identify two Windows services, namely IKE and AuthIP IPsec Keying Modules (IKEEXT) and Remote Desktop Configuration (SessionEnv). Both services are known for their DLL hijacking of DLL files missing in the System32 folder by default, SCM and DLL Hijacking Primer.

Lateral movement

The DLL hijacking in the System32 folder is not a vulnerability by itself because the attackers need administrator privileges to write into it. However, we assume the existence of an implemented reverse shell with administrator privileges as a consequence of the initial compromise. In that case, the attacker can efficiently perform the lateral movement via Service Control Manager (SVCCTL).

In short, the attackers place the hijacked DLL files into %SYSTEMROOT%\System32 and then start an appropriate service remotely. 

List of abused Windows services and their DLL files:

  • IKE and AuthIP IPsec Keying Modules
    • C:\Windows\System32\WLBSCTRL.dll
  • Remote Desktop Configuration
    • C:\Windows\System32\TSMSISrv.dll
    • C:\Windows\System32\TSVIPSrv.dll

The second observed DLL hijacked is related to VMware machines. The attackers can misuse the hijacking of vmGuestLib.dll, which is used by the WMI Performance Adapter (WmiApSrv) service to provide performance information.

On system start, WmiApSrv loads vmStatsProvider.dll, which tries to call vmGuestLib.dll from %ProgramFiles%\VMware\VMware Tools\vmStatsProvider\win32 as the first one. However, the original library is located at %SYSTEMROOT%\System32. Hence, if the attackers place vmGuestLib.dll into the %ProgramFiles% location, it also leads to DLL hijacking.

These two approaches are probable scenarios of how CLRLoader can be executed, and the compromise chain shown in Figure 1 launched. The elegance of this approach is that attackers do not have to create a new service that may reveal suspicious activities. The attackers abuse only export functions of hijacked DLLs, whose empty reimplementation does not cause an error or any other indicator of compromise. Moreover, the persistence of CLRLoader is ensured by the legitim Windows services.


CLRLoader is a DLL file written in Microsoft Visual C++. It implements the DllMain method, which is responsible for loading the next stage (.NET variant of PNGLoader). The rest of the exported functions correspond to the interfaces of the hijacked DLLs, but the implementation of the export functions is empty. So, invoking this function does not cause a crash in the calling processes. Just for completeness, the hijacked files also contain digital signatures of the original DLL files; naturally, the signature is invalid.

CLRLoader is activated by calling LoadLibraryExW from an abused process/service. LoadLibraryExW is called with zero dwFlags parameters, so the DllMain is invoked when the malicious DLL is loaded into the virtual address space. An example of the CLRLoader code can be seen in Figure 3.

Figure 3. DllMain of hijacked DLL

CLRLoader checks the presence of the .NET DLL file containing PNGLoader, creates a mutex, and finally executes PNGLoader via CorBindToRuntimeEx API.

We recognized two variants of PNGLoader with the entry points as follow:

  • Jsprofile.Jspfilter (Setfilter)
  • pngpcd.ImageCoder (PngCoder)


The second stage (PNGLoader) is loaded by CLRLoader or, as reported by ESET, by PowHeartBeat. We do not see any code deploying PNGLoader on infiltrated systems yet, but we expect to see it in a similar manner as the lateral movement.

PNGLoader is a loader that extracts bytes from PNGs files and reconstructs them into an executable code. PNGLoader is a .NET DLL file obfuscated utilizing .NET Reactor; the file description provides information that mimics legitimate software such as Jscript Profiler or Transfer Service Proxy.

The deobfuscated PNGLoader code includes the entry point (Setfilter) invoked by CLRLoader. There is a hardcoded path loader_path that is searched for all PNG files recursively. Each .png file is verified to the specific bitmap attributes (height, width) and steganographically embedded content (DecodePng). The Setfilter method is shown in Figure 4.

Figure 4. The Setfilter method of PNGLoader

The steganographic embedding relies on one of the more common steganographic techniques called least-significant bit (LSB) encoding. In general, this method embeds the data in the least-significant bits of every pixel. In this specific implementation, one pixel encodes a nibble (one bit per each alpha, red, green, and blue channel), i.e. two pixels contain a byte of hidden information, as illustrated in Figure 5. While this method is very easy to detect by a simple statistical analysis, such change in pixel value is hardly perceivable by the naked eye.

Figure 5. Byte reconstruction from 2 pixels

The steganographically embedded content is then extracted in four steps as follows.

  • The first 16 bytes (32 pixels) of the PNG file are extracted, and the first 8 bytes must match a magic number. This check is performed due to the computational complexity necessary to pull the rest of the pixels (approx. hundreds of thousands of pixels). The following 8 bytes then represent the length of the embedded payload.
  • The following extracted data is an encrypted payload in Gzip format.
  • The extracted payload is decrypted using a multiple-byte XOR hard-coded in PNGLoader.
  • The result of XORing is Gzip data that is un-gzipped.

The result of these steps is the final payload steganographically embedded in the PNG file.

Steganographically Embedded Payload

If PNGLoader successfully processes (extract → decode → unpack) the final payload, it is compiled in runtime and executed immediately. Our telemetry has picked up two variants of PNGLoader working with the magic numbers recorded in Figure 6.

Figure 6. Data structure embedded in PNG bitmap

The first payload implementation is a PowerShell script, as demonstrated by the code fragment of PNGLoader in Figure 7. Like our ESET colleagues, we have no sample of this payload yet, but we expect a similar function as the second payload implementation described below.

Figure 7. Code fragment of PNGLoader executing the PowerShell payload

The second payload implementation is .NET C# compiled and executed via the CompileAssemblyFromSource method of the CSharpCodeProvider class, see Figure 8.

Figure 8. Execution of C# payload embedded in PNG bitmap

The .NET C# payload has a namespace Mydropbox, class Program, and method Main. The namespace indicates that the payload operates with DropBox. Our telemetry captured a few PNG files, including the steganographically embedded C# payload.

PNG Files

At first glance, the PNG pictures look innocent, like a fluffy cloud; see Figure 9. Our telemetry has captured three PNG pictures with the following attributes: 

  • Size: 1213 x 270 (px)
  • Bit Depth: 8, Color Type: 6 (RGB + Alpha)
Figure 9. Malicious PNG file with steganographically embedded C# payload

As we mentioned before, malware authors rely on LSB encoding to hide malicious payload in the PNG pixel data, more specifically in LSB of each color channel (Red, Green, Blue, and Alpha). Let us have a look at their bit-planes. Figure 10 shows one of the higher bit planes for each color channel; notice that each of these images looks far from random noise. If we had a look at an image without data embedded in its LSB, we would usually see similar patterns.

Figure 10. One of the RGB bit-planes without hidden data

Now, to put it into contrast, let us have a look at LSB bit-planes. Figure 11 shows LSB bit-planes for every channel of the PNG image with the embedded encrypted (and compressed) payload. Recall that both encryption and compression should usually increase the entropy of the image. Therefore, it should be no surprise that LSB bit-planes of such an image look like random noise. It is evident that the whole canvas of LSB bit-planes is not used.

Figure 11. Zero (LSB) bit-plains channels with embedded data

The payload occupies only pixels representing the payload size, and the rest are untouched; see the algorithm below.

In this specific case, the PNG files are located in C:\Program Files\Internet Explorer, so the picture does not attract attention because Internet Explorer has a similar theme as Figure 12 shows.

Figure 12. Example of graphic Internet Explorer theme


At this time, we can extend the ESET compromise chain by the .NET C# payload that we call DropBoxControl – the third stage, see Figure 13.

Figure 13. Extended compromise chain

DropBoxControl is a backdoor that communicates with the attackers via the DropBox service. Noteworthy, the C&C server is a DropBox account, and whole communications, such as commands, uploads, and downloads, are performed using regular files in specific folders. Therefore, the backdoor commands are represented as files with a defined extension. DropBoxControl periodically checks the DropBox folder and executes commands based on the request files. The response for each command is also uploaded to the DropBox folder as the result file.

The text below describes the individual DropBoxControl components and the whole backdoor workflow.

DropBox API

DropBoxControl implements the DropBox communication by applying the standard API via HTTP/POST. There is a dedicated class, DropBoxOperation, wrapping the API with the method summarized in Table 1. A DropBox API key, sent in the HTTP header, is hard-coded in the DropBoxControl sample but can be remotely changed.

DropBoxControl Method API
Table 1. DropBox API implemented by DropBoxControl

The attackers control the backdoor through ten commands recorded in Table 2.

Command Description
cmd Run cmd /c <param> & exit, the param is sent by the attackers.
exe Execute a defined executable with specific parameters.
FileUpload Download data from the DropBox to a victim’s machine.
FileDownload Upload data from a victim’s machine to the DropBox.
FileDelete Delete data from a victim’s machine.
FileRename Rename data from a victim’s machine.
FileView Sent file information (name, size, attributes, access time) about all victim’s files in a defined directory
ChangeDir Set a current directory for the backdoor
Info Send information about a victim’s machine to the DropBox
Config Update a backdoor configuration file; see Configuration
Table 2. Backdoor commands

The Info command sends basic information about an infiltrated system as follows:

  • ClientId hard-coded in each DropBoxControl sample
  • Version of DropBoxControl sample (seen
  • Hostname of a victim’s machine
  • List of all victim’s IPs
  • Version and file size of explorer.exe
  • Windows architecture
  • List of hard drivers, including total size, available free space, and drive type
  • The current time of victim’s machine

DropBoxControl, the object of this study, uses three files located on C:\Program Files\Internet Explorer. The file names try to look legitimate from the perspective of the Internet Explorer folder.


This file contains the DropBoxControl configuration that is encrypted. It configures four variables as follows:

  • DropboxId: API key used for authorization
  • Interval: how often the DropBox disk is checked
  • UpTime/DownTime: defines the time interval when the backdoor is active (seen 7 – 23)

See the example of the configuration file content:
Bearer WGG0iGT****AAGkOdrimId9***QfzuwM-nJm***R8nNhy,300,7,23


The iexplore.log file is a log file of DropBoxControl which records most actions like contacting the DropBox, downloading/uploading files, configuration loading, etc. Log entities are logged only if a sqmapi.dat file exists. The login engine is curiously implemented since the log file is not encrypted and contains decrypted data of the ieproxy.dat file.


DropBoxControl encrypts the configuration file (actually without effect), and the DropBox communication. The config file is encrypted using multi-byte XOR with a hard-coded key (owe01zU4). Although the API communication is encrypted via HTTPS, data stored on the DropBox is encrypted by its own algorithm.

The data is encrypted using another hard-coded byte array (hexEnc), TaskId, and ClientId. Moreover, TaskId is used as an index to the hexEnc array, and the index is salted with ClientId in each iteration; see Figure 14. It is similar to the algorithm used by PowHeartBeat, as described in the ESET report.

Figure 14. Encryption algorithm used for DropBox files
DropBox Files

As we mentioned above, the communication between the backdoors and the attackers is performed using the DropBox files. In general, DropBox files that contain valuable information are encrypted. Each file, in addition to the data itself, also includes flags, the task type (command), and other metadata, as seen in Figures 15 and Table 3.

Figure 15. The file structure of DropBox files
Item Length Description
EncType 1 Flag – data in the file is encrypted
GzipType 1 Flag – data in the file is gzipped
TaskType 2 Command type
DataLen 4 Data length
Table 3. DropBox file header

Returning to the DropBox files, we explore a DropBox file structure of the DropBox account. A root folder includes folders named according to the ClientId that is hard-coded in the DropBoxControl sample; more precisely, in the PNG file.

Each client folder holds a time.txt file which includes a number that is a count of the backdoor iteration. One iteration means contacting and processing an appropriate client folder in the DropBox repository.

The attackers specify the task type and eventual parameters. The task type and parameters are then packed using the file header and uploaded into the appropriate client folder as a request file (.req). Further analysis found that the backdoor processes its .req files and creates a result file (.res) as a response for each request file. The result file has the same file structure shown in Figure 15, but data, data length, and task type have different values, since returned data contains requested (stolen) information.

Comparing all DropBox folders (Figure 16), we determined the name of the request and result files in this form: [0-9]+-[0-9]+. The filename is used for request/response identification and also for data encrypting.

For example, let’s use the request file name 31-1233.req. The IDMessage is 31-1233 and TaskId is 1233. So, the data is encrypted using the ClientId and TaskId, plus hard-coded hexEnc; see Encryption.

Figure 16. List of DropBox files
DropBoxControl Workflow

We defined and described the basic functionality of DropBoxControl in the sections above. Therefore, we can summarize all this knowledge into a backdoor workflow and outline the whole process of data collecting, uploading, downloading, and communicating with the DropBox repository.

In the beginning, PNGLoader extracts the stenographically embedded DropBoxControl and invokes the Main method of the C# Mydropbox.Program class. DropBoxControl then decrypts and loads the configuration file containing the DropBox API key. Most of the actions are recorded in the log file.

If the current time is between UpTime and DownTime interval, DropBoxControl is active and starts the main functionality. It contacts the DropBox repository and uploads the time.txt file into the client folder. If the time.txt upload is successful, the backdoor downloads a list of all files stored in the client folder. The file list is iterated, and each request (.req) file is downloaded and processed based on the tasks type (command). DropBoxControl executes the command and creates the result file (.res) with the requested information. The resulting encrypted file is uploaded back into the client folder. Finally, the processed request (.req) file is deleted.


The victims we saw targeted in this campaign are similar to those that ESET saw. The victims of this campaign were companies and government institutions in Asia and North America, namely Mexico. Vietnam and Cambodia are the other countries affected by DropBoxControl. One of the DropBoxControl connections was monitored from an IP associated with the Ministry of Economic Development of Russia.


The third stage of the compromise chain is represented by the C# implementation of DropBoxControl. The DropBoxControl functionality allows attackers to control and spy on victims’ machines. Moreover, the backdoor has access to the Program Files folder, so we expect it to run under administrator privileges. The most common command observed in log files is obtaining information about victims’ files, followed by data collecting.

The typical command for the data collecting is via the cmd command; see the example below:

rar.exe a -m5 -r -y -ta20210204000000 -hp1qazxcde32ws -v2560k Asia1Dpt-PC-c.rar c:\\*.doc c:\\*.docx c:\\*.xls c:\\*.xlsx c:\\*.pdf c:\\*.ppt c:\\*.pptx c:\\*.jpg c:\\*.txt >nul

The attacks focus on collecting all files of interest, such as Word, Excel, PowerPoint, PDF, etc. They recursively search the files in the C:\ drive and pack them into an encrypted rar archive, split into multiple files.

Another command decrypted from the request file executes Ettercap, which sniffs live network connections using man-in-the-middle attacks; see the command below:

ettercap.exe -Tq -w a.cap -M ARP / //

The attackers can sniff network communications and intercept user credentials sent via, e.g., web pages.

In short, DropBoxControl is malware with backdoor and spy functionality.

DropBox Account

Our telemetry has captured these three DropBox APIs:

Bearer gg706X***************Ru_43QAg**********1JU1DL***********ej1_xH7e
Bearer ARmUaL***************Qg02vynP**********ASEyQa***********deRLu9Gx
Bearer WGG0iG***************kOdrimId**********ZQfzuw***********6RR8nNhy

Two keys are registered to “Veronika Shabelyanova” ([email protected][.]com) with Chinese localization. The email is still active, as well as the DropBox repository. The user of the email is a Slavic transcription of “Вероника Шабелянова”.

The third DropBox repository is connected with a Hong Kong user “Hartshorne Yaeko” ([email protected][l].com)

DropBox Files

We are monitoring the DropBox repositories and have already derived some remarkable information. The DropBox accounts were created on 11 July 2019 based on README files created on account’s creation.

At this time, there is only one DropBox repository that seems to be active. It contains seven folders with seven time.txt files, so there are seven active DropBoxControl instances, since the time.txt files have integers that are periodically incremented; see DropBox Files. Moreover, the integer values indicate that the backdoors run continuously for tens of days. Regarding the backdoor commands, we guess the last activity that sent request files was on 1 June 2022, also for seven backdoors. Finally, the total count of folders representing infiltrated machines equals twenty-one victims.

In April 2022, the attackers uploaded a Lua script implementing the nmap Library shortport searching for Telnet services using s3270 to control IBM mainframes; see the script below.

Code Quality of DropBoxControl

While we usually refrain from commenting on the code quality, in this case it deserves mentioning as the code quality is debatable at best and not every objection can be blamed on obfuscation.

The code contains a lot of redundant code; both duplicate code and code that serves no function. An indication of unfamiliarity with C# is usage of one’s own implementation of serialization/deserialization methods instead of using C# build-in functions. The threading code does not rely on usual synchronization primitives such semaphores, mutexes, etc. but rather uses bool flags with periodic checks of thread states. The code also contains parts that are presumably copied from API documentation. For instance, the implementation of DropBox_FileDownload contains the same comment as in the DropBox documentation; see the illustration below.

Another weird quirk is the encryption method for the configuration file. The DropBoxControl author has attempted to obfuscate the configuration in the ieproxy.dat file because the API key is sensitive information. However, when the config file is decrypted and applied, the configuration content is logged into the iexplore.log file in plain text.

In other words, the whole DropBoxControl project looks like a school project. Authors do not adhere to usual coding practices, rely on their own implementation of common primitives, and reuse code from documentation examples. This leads us to an assessment that DropBoxControl authors are different from authors of CLRLoader and PNGLoader due to significantly different code quality of these payloads.


The purpose of this study has been to confirm the assumptions of our fellow researchers from ESET published in the article about the Worok cyberespionage group. Our research managed to extend their compromise chain, as we have managed to find artifacts that fit the chain accompanying the samples in question.

We have described probable scenarios of how the initial compromise can be started by abusing DLL hijacking of Windows services, including lateral movement. The rest of the compromise chain is very similar to the ESET description.

The key finding of this research is the interception of the PNG files, as predicted by ESET. The stenographically embedded C# payload (DropBoxControl) confirms Worok as the cyberespionage group. They steal data via the DropBox account registered on active Google emails.

The prevalence of Worok’s tools in the wild is low, so it can indicate that the toolset is an APT project focusing on high-profile entities in private and public sectors in Asia, Africa, and North America.


DropBoxControl Log

[02:00:50]:[+]Main starts.
[02:00:50]:[+]Config exists.
[02:00:50]:[__]DecryptContent is 1,Bearer gg706Xqxhy4*****************gQ8L4OmOLdI1JU1DL**********1ej1_xH7e#,300,7,23
[10:39:40]:[+]In work time.
[10:39:42]:[UPD] UploadData /data/2019/time.txt Starts!
[10:40:08]:[UPD] UploadData /data/2019/time.txt Success!
[10:40:10]:[UPD] UploadData Ends!
[10:40:10]:[+]Get Time.txt success.
[10:40:11]:[+] DropBox_GetFileList Success!
[10:40:11]:[DOWN] DownloadData /data/2019/31-3.req Starts!
[10:40:13]:[DOWN] DownloadData /data/2019/31-3.req Success!
[10:40:13]:[DOWN] DownloadData Ends!
[10:40:26]:[UPD] UploadData /data/2019/31-3.res Starts!
[10:40:27]:[UPD] UploadData /data/2019/31-3.res Success!
[10:40:27]:[UPD] UploadData Ends!
[10:40:27]:[DEL] Delete /data/2019/31-3.req  Starts!
[10:40:28]:[DEL] Delete /data/2019/31-3.req Success!
[10:40:28]:[DEL] Delete Ends!
[10:40:28]:[DOWN] DownloadData /data/2019/31-4.req Starts!
[10:40:29]:[DOWN] DownloadData /data/2019/31-4.req Success!
[10:40:29]:[DOWN] DownloadData Ends!
[10:40:34]:[UPD] UploadData /data/2019/31-4.res Starts!
[10:40:36]:[UPD] UploadData /data/2019/31-4.res Success!
[10:40:36]:[UPD] UploadData Ends!
[10:40:36]:[DEL] Delete /data/2019/31-4.req  Starts!
[10:40:36]:[DEL] Delete /data/2019/31-4.req Success!
[10:40:36]:[DEL] Delete Ends!
[10:40:36]:[DOWN] DownloadData /data/2019/31-5.req Starts!
[10:40:37]:[DOWN] DownloadData /data/2019/31-5.req Success!
[10:40:37]:[DOWN] DownloadData Ends!
[10:40:42]:[UPD] UploadData /data/2019/31-5.res Starts!
[10:40:43]:[UPD] UploadData /data/2019/31-5.res Success!
[10:40:43]:[UPD] UploadData Ends!
[10:40:43]:[DEL] Delete /data/2019/31-5.req  Starts!
[10:40:44]:[DEL] Delete /data/2019/31-5.req Success!
[10:40:44]:[DEL] Delete Ends!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Starts!
[10:40:44]:[DOWN] DownloadData /data/2019/31-7.req Success!
[10:40:44]:[DOWN] DownloadData Ends!
[10:40:49]:[UPD] UploadData /data/2019/31-7.res Starts!
[10:40:50]:[UPD] UploadData /data/2019/31-7.res Success!
[10:40:50]:[UPD] UploadData Ends!
[10:40:50]:[DEL] Delete /data/2019/31-7.req  Starts!
[10:40:52]:[DEL] Delete /data/2019/31-7.req Success!
[10:40:52]:[DEL] Delete Ends!

Task Type Values
Command Task Type
Cmd_Request 0x01
Cmd_Response 0x02
Exe_Request 0x03
Exe_Response 0x04
FileUpload_Request 0x05
FileUpload_Response 0x06
FileDownload_Request 0x07
FileDownload_Response 0x08
FileView_Request 0x09
FileView_Response 0x0A
FileDelete_Request 0x0B
FileDelete_Response 0x0C
FileRename_Request 0x0D
FileRename_Response 0x0E
ChangeDir_Request 0x0F
ChangeDir_Response 0x10
Info_Request 0x11
Info_Response 0x12
Config_Request 0x13
Config_Response 0x14

PNG file with steganographically embedded C# payload





[1] Worok: The big picture
[2] Lateral Movement — SCM and DLL Hijacking Primer
[3] Dropbox for HTTP Developers

The post PNG Steganography Hides Backdoor appeared first on Avast Threat Labs.

Outbreak of Follina in Australia

Our threat hunters have been busy searching for abuse of the recently-released zero-day remote code execution bug in Microsoft Office (CVE-2022-30190). As part of their investigations, they found evidence of a threat actor hosting malicious payloads on what appears to be an Australian VOIP telecommunications provider with a presence in the South Pacific nation of Palau.

Further analysis indicated that targets in Palau were sent malicious documents that, when opened, exploited this vulnerability, causing victim computers to contact the provider’s website, download and execute the malware, and subsequently become infected.

Key Observations

This threat was a complex multi-stage operation utilizing LOLBAS (Living off the Land Binaries And Scripts), which allowed the attacker to initialize the attack using the CVE-2022-30190 vulnerability within the Microsoft Support Diagnostic Tool. This vulnerability enables threat actors to run malicious code without the user downloading an executable to their machine which might be detected by endpoint detection.

Multiple stages of this malware were signed with a legitimate company certificate to add additional legitimacy and minimize the chance of detection.

First stage

The compromised website, as pictured in the screenshot below, was used to host robots.txt which is an executable which was disguised as “robots.txt”. We believe the name was used to conceal itself from detection if found in network logs. Using the Diagnostics Troubleshooting Wizard (msdt.exe), this file “robots.txt” was downloaded and saved as the file (Sihost.exe) and then executed.

Second Stage, Sihost.exe

When the renamed “robots.txt” – “Sihost.exe” – was executed by msdt.exe it downloaded the second stage of the attack which was a loader with the hash b63fbf80351b3480c62a6a5158334ec8e91fecd057f6c19e4b4dd3febaa9d447. This executable was then used to download and decrypt the third stage of the attack, an encrypted file stored as ‘favicon.svg’ on the same web server.

Third stage, favicon.svg

After this file has been decrypted, it is used to download the fourth stage of the attack from[.]au. These files are named Sevntx64.exe and Sevntx.lnk, which are then executed on the victims’ machine.

Fourth Stage, Sevntx64.exe and Sevntx64.lnk

When the file is executed, it loads a 66kb shellcode from the AsyncRat malware family; Sevntx64.exe is signed with the same compromised certificate as seen previously in “robots.txt”.

The screenshot below shows the executable loading the shellcode.

Final Stage, AsyncRat

When the executable is loaded, the machine has been fully compromised with AsyncRat; the trojan is configured to communicate with the server palau[.]voipstelecom[.]com[.]au on port 443

AsyncRat SHA256:


Screenshot below with AsyncRat configuration:


We highly recommend Avast Software to protect against the latest threats, and Microsoft patches to protect your Windows systems from the latest CVE-2022-30190 vulnerability.


item sha256
main webpage 0af202af06aef4d36ea151c5a304414a67aee18c3675286275bd01d11a760c04 
robots.txt b63fbf80351b3480c62a6a5158334ec8e91fecd057f6c19e4b4dd3febaa9d447 
favicon.svg ed4091700374e007ae478c048734c4bc0b7fe0f41e6d5c611351bf301659eee0
decrypted favicon.svg 9651e604f972e36333b14a4095d1758b50decda893e8ff8ab52c95ea89bb9f74
Sevntx64.exe f3ccf22db2c1060251096fe99464002318baccf598b626f8dbdd5e7fd71fd23f 
Sevntx64.lnk 33297dc67c12c7876b8052a5f490cc6a4c50a22712ccf36f4f92962463eb744d 
shellcode from Sevntx64.exe (66814 bytes) 7d6d317616d237ba8301707230abbbae64b2f8adb48b878c528a5e42f419133a
asyncrat aba9b566dc23169414cb6927ab5368b590529202df41bfd5dded9f7e62b91479


We managed to find an earlier version of this malware.

file hash first seen country
Grievance Against Lawyers, Judge or Justice.doc.exe (signed) 87BD2DDFF6A90601F67499384290533701F5A5E6CB43DE185A8EA858A0604974  26.05.2022 NL, proxy
Grievance Against Lawyers, Judge or Justice (1).zip\Grievance Against Lawyers, Judge or Justice.doc.exe 0477CAC3443BB6E46DE9B904CBA478B778A5C9F82EA411D44A29961F5CC5C842 18.05.2022 Palau, previous victim

Forensic information from the lnk file:

field value
Application Sevntx64.exe
Accessed time 2022-05-19 09:34:26
Birth droid MAC address 00:0C:29:59:3C:CC
Birth droid file ID 0e711e902ecfec11954f000c29593ccc
Birth droid volume ID b097e82425d6c944b33e40f61c831eaf
Creation time 2022-05-19 10:29:34
Drive serial number 0xd4e21f4f
Drive type DRIVE_FIXED
Droid file ID 0e711e902ecfec11954f000c29593ccc
Droid volume ID b097e82425d6c944b33e40f61c831eaf
Known folder ID af2448ede4dca84581e2fc7965083634
Link flags EnableTargetMetadata, HasLinkInfo, HasRelativePath, HasTargetIDList, HasWorkingDir, IsUnicodeLocal
base path C:\Users\Public\Documents\Sevntx64.exe
Location Local
MAC address 00:0C:29:59:3C:CC
Machine identifier desktop-eev1hc3
Modified time 2020-08-19 04:13:44
Relative path .\Sevntx64.exe
Size 1543
Target file size 376368
Working directory C:\Users\Public\Documents

The post Outbreak of Follina in Australia appeared first on Avast Threat Labs.

Avast Finds Compromised Philippine Navy Certificate Used in Remote Access Tool

28 March 2022 at 11:25

Avast Threat Intelligence Team has found a remote access tool (RAT) actively being used in the wild in the Philippines that uses what appears to be a compromised digital certificate belonging to the Philippine Navy. This certificate is now expired but we see evidence it was in use with this malware in June 2020.  

Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.

We got in touch with CERT-PH, the National Computer Emergency Response Team for the Philippines to help us contact the navy. We have shared with them our findings. The navy security team later let us know that the incident has been resolved and no further assistance was necessary from our side.

Because this is being used in active attacks now, we are releasing our findings immediately so organizations can take steps to better protect themselves. We have found that this sample is now available on VirusTotal.

Compromised Expired Philippine Navy Digital Certificate

In our analysis we found the sample connects to dost[.]igov-service[.]net:8443 using TLS in a statically linked OpenSSL library.

A WHOIS lookup on the C&C domain gave us the following:

The digital certificate was pinned so that the malware requires the certificate to communicate.

When we checked the digital certificate used for the TLS channel we found the following information:

Some important things to note:

Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.

While the digital certificate is now expired we see evidence it was in use with this malware in June 2020. 

The malicious PE file was found with filename: C:\Windows\System32\wlbsctrl.dll and its hash is: 85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB.

In analyzing that malicious PE file itself, we found that the compilation timestamp is wrong or was edited. Specifically, the TimeDateStamp of the PE file was modified and set to the year 2004 in both the PE header and Debug Directory as shown below:

However, we found that the author used OpenSSL 1.1.1g and compiled it on April 21, 2020 as shown below:

The username of the author was probably udste. This can be seen in the debug information left inside the used OpenSSL library.

We found that the malware supported the following commands:

  • run shellcode
  • read file
  • write file
  • cancel data transfer
  • list drives
  • rename a file
  • delete a file
  • list directory content

Some additional items of note regarding the malicious PE file:

  • All configuration strings in the malware are encrypted using AES-CBC with the exception of the mutex it uses.That mutex is used as-is without decryption: t7As7y9I6EGwJOQkJz1oRvPUFx1CJTsjzgDlm0CxIa4=.
  • When this string is decrypted using the hard-coded key it decrypts to QSR_MUTEX_zGKwWAejTD9sDitYcK. We suspect that this is a failed attempt to disguise this malware as the infamous Quasar RAT malware. But this cannot be the case because this sample is written in C++ and the Quasar RAT is written in C#.

Avast customers are protected against this malware.

Indicators of Compromise (IoC)

SHA256 File name
85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB C:\Windows\System32\wlbsctrl.dll
C&C server

The post Avast Finds Compromised Philippine Navy Certificate Used in Remote Access Tool appeared first on Avast Threat Labs.

Avast Finds Backdoor on US Government Commission Network

16 December 2021 at 17:01

We have found a new targeted attack against a small, lesser-known U.S. federal government commission associated with international rights. Despite repeated attempts through multiple channels over the course of months to make them aware of and resolve this issue they would not engage.

After initial communication directly to the affected organization, they would not respond, return communications or provide any information.

The attempts to resolve this issue included repeated direct follow up outreach attempts to the organization. We also used other standard channels for reporting security issues directly to affected organizations and standard channels the United States Government has in place to receive reports like this.

In these conversations and outreach we have received no follow up or information on whether the issues we reported have been resolved and no further information was shared with us.

Because of the lack of discernible action or response, we are now releasing our findings to the community so they can be aware of this threat and take measures to protect their customers and the community. We are not naming the entity affected beyond this description.

Because they would not engage with us, we have limited information about the attack. We are unable to attribute the attack, its impact, or duration. We are only able to describe two files we observed in the attack. In this blog, we are providing our analysis of these two files.

While we have no information on the impact of this attack or the actions taken by the attackers, based on our analysis of the files in question, we believe it’s reasonable to conclude that the attackers were able to intercept and possibly exfiltrate all local network traffic in this organization. This could include information exchanged with other US government agencies and other international governmental and nongovernmental organizations (NGOs) focused on international rights. We also have indications that the attackers could run code of their choosing in the operating system’s context on infected systems, giving them complete control.

Taken altogether, this attack could have given total visibility of the network and complete control of a system and thus could be used as the first step in a multi-stage attack to penetrate this, or other networks more deeply.

Overview of the Two Files Found

The first file masquerades as oci.dll and abuses WinDivert, a legitimate packet capturing utility, to listen to all internet communication. It allows the attacker to download and run any malicious code on the infected system. The main scope of this downloader may be to use priviliged local rights to overcome firewalls and network monitoring.

The second file also masquerades as oci.dll, replacing the first file at a later stage of the attack and is a decryptor very similar to the one described by Trend Labs from Operation red signature. In the following text we present analysis of both of these files, describe the internet protocol used and demonstrate the running of any code on an infected machine.

First file – Downloader

We found this first file disguised as oci.dll (“C:\Windows\System32\oci.dll”) (Oracle Call Interface). It contains a compressed library (let us call it NTlib). This oci.dll exports only one function DllRegisterService. This function checks the MD5 of the hostname and stops if it doesn’t match the one it stores. This gives us two possibilities. Either the attacker knew the hostname of the targeted device in advance or the file was edited as part of the installation to run only on an infected machine to make dynamic analysis harder.

We found two samples of this file:

SHA256 Description
E964E5C8A9DD307EBB5735406E471E89B0AAA760BA13C4DF1DF8939B2C07CB90 has no hash stored and it can run on every PC
C1177C33195863339A17EBD61BA5A009343EDB3F3BDDFC00B45C5464E738E0A1 is exactly the same file but it contains the hash of hostname

Oci.dll then decompresses and loads NTlib and waits for the attacker to send a PE file, which is then executed.

NTlib works as a layer between oci.dll and WinDivert.

The documentation for WinDivert describes it as “a powerful user-mode capture/sniffing/modification/blocking/re-injection package for Windows 7, Windows 8 and Windows 10. WinDivert can be used to implement user-mode packet filters, packet sniffers, firewalls, NAT, VPNs, tunneling applications, etc., without the need to write kernel-mode code.”

NTlib creates a higher level interface for TCP communication by using low-level IP packets oriented functions of WinDivert. The NTLib checks if the input has magic bytes 0x20160303 in a specific position of the structure given as the first argument as some sort of authentication.

Exported functions of NTLib are:

  • NTAccept
  • NTAcceptPWD
  • NTSend
  • NTReceive
  • NTIsClosed
  • NTClose
  • NTGetSrcAddr
  • NTGetDscAddr
  • NTGetPwdPacket

The names of the exported functions are self-explanatory. The only interesting function is  NTAcceptPWD, which gets an activation secret as an argument and sniffs all the incoming TCP communication, searching for communication with that activation secret. It means that the malware itself does not open any port on its own, it uses the ports open by the system or other applications for its communication. The malicious communication is not reinjected to the Windows network stack, therefore the application listening on that port does not receive it and doesn’t even know some traffic to its port is being intercepted.

The oci.dll uses NTlib to find communications with the activation secret CB 57 66 F7 43 6E 22 50 93 81 CA 60 5B 98 68 5C 89 66 F1 6B. While NTlib captures the activation secret, oci.dll responds with Locale (Windows GUID, OEM code page identifier and Thread Locale) and then waits for the encrypted PE file that exports SetNtApiFunctions. If the PE file is correctly decrypted, decompressed and loaded, it calls the newly obtained function SetNtApiFunctions.

The Protocol

As we mentioned before, the communication starts with the attacker sending CB 57 66 F7 43 6E 22 50 93 81 CA 60 5B 98 68 5C 89 66 F1 6B (the activation secret) over TCP to any open port of the infected machine.

The response of the infected machine:

  • Size of the of the message – 24 (value: 28) [4 B]
  • Random encryption key 1 [4 B]
  • Encrypted with Random encryption key 1 and precomputed key:
    • 0 [4 B]
    • ThreadLocale [4 B]
    • OEMCP or 0 [4 B]
    • 0x20160814 (to test correctness of decryption) [4 B] 
    • 0,2,0,64,0,0,0 [each 4 B]

The encryption is xor cipher with precomputed 256 B key:


That is xored with another 4 B key.

After sending the above message the infected machine awaits for a following message with the encrypted PE file mentioned above:

  • Size of the of the message – 24 [4 B]
  • Random Encryption key 2 [4 B]
  • Encrypted  with Random encryption key 2 and precomputed key:
    • 6 (LZO level?) [4 B]
    • 0 [8 B]
    • 0x20160814 [4 B] 
    • 0x20160814 [4 B]
    • Size of the whole message [4 B]
    • Offset (0) [4 B]
    • Length (Size of the whole message) [4 B]
    • Encrypted with key 0x1415CCE and precomputed key:
      • 0 [16 B]
      • Length of decompressed PE file [4 B]
      • 0 [16 B]
      • Length of decompressed PE file [4 B]
      • 0 [16 B]
      • LZO level 6 compressed PE file

With the same encryption as the previous message.

In our research we were unable to obtain the PE file that is part of this attack. In our analysis, we demonstrated the code execution capabilities by using a library with the following function:

In a controlled lab setting, we were able to start the calculator on an infected machine over the network with the following python script (link to GitHub).

Second File – Decryptor

The second file we found also masquerages as oci.dll. This file replaced the first downloader oci.dll and likely represents another, later stage of the same attack. The purpose of this file is to decrypt and run in memory the file “SecurityHealthServer.dll”.

SHA256: 6C6B40A0B03011EEF925B5EB2725E0717CA04738A302935EAA6882A240C2229A

We found that this file is similar to the rcview40u.dll that was involved in Operation Red Signature. rcview40u.dll (bcfacc1ad5686aee3a9d8940e46d32af62f8e1cd1631653795778736b67b6d6e) was signed by a stolen certificate and distributed to specific targets from a hacked update server. It decrypted a file named rcview40.log, that contained 9002 RAT and executed it in memory.

This oci.dll exports same functions as rcview40u.dll:

The new oci.dll decrypts SecurityHealthServer.dll with RC4 and used the string TSMSISRV.dll as the encryption key. This is similar to what we’ve seen with rcview40u.dll which also uses RC4 to decrypt rcview.log with the string kernel32.dll as the encryption key.

Because of the similarities between this oci.dll and rcview40u.dll, we believe it is likely that the attacker had access to the source code of the three year-old rcview40u.dll.  The newer oci.dll has minor changes like starting the decrypted file in a new thread instead of in a function call which is what  rcview40u.dll does. oci.dll was also compiled for x86-64 architecture while rcview40u.dll was only compiled for x86 architecture.


While we only have parts of the attack puzzle, we can see that the attackers against these systems were able to compromise systems on the network in a way that enabled them to run code as the operating system and capture any network traffic travelling to and from the infected system.

We also see evidence that this attack was carried out in at least two stages, as shown by the two different versions of oci.dll we found and analyzed.

The second version of the oci.dll shows several markers in common with rcview40u.dll that was used in Operation Red Signature such that we believe these attackers had access to the source code of the malware used in that attack.

Because the affected organization would not engage we do not have any more factual information about this attack. It is reasonable to presume that some form of data gathering and exfiltration of network traffic happened, but that is informed speculation. Further because this could have given total visibility of the network and complete control of an infected system it is further reasonable speculation that this could be the first step in a multi-stage attack to penetrate this, or other networks more deeply in a classic APT-type operation.

That said, we have no way to know for sure the size and scope of this attack beyond what we’ve seen. The lack of responsiveness is unprecedented and cause for concern. Other government and non-government agencies focused on international rights should use the IoCs we are providing to check their networks to see if they may be impacted by this attack as well.

The post Avast Finds Backdoor on US Government Commission Network appeared first on Avast Threat Labs.

Avast releases decryptor for AtomSilo and LockFile ransomware

27 October 2021 at 15:59

On Oct 17, 2021, Jiří Vinopal published information about a weakness in the AtomSilo ransomware and that it is possible to decrypt files without paying the ransom. Slightly later, he also analyzed another ransomware strain, LockFile. We prepared our very own free Avast decryptor for both the AtomSilo and LockFile strains.

Limitation of the decryptor

During the decryption process, the Avast AtomSilo decryptor relies on a known file format in order to verify that the file was successfully decrypted. For that reason, some files may not be decrypted. This can  include files with proprietary or unknown format, or with no format at all, such as text files.

How AtomSilo and LockFile Work

Both the AtomSilo and LockFile ransomware strains are very similar to each other and except for minor differences, this description covers both of them. 

AtomSilo ransomware searches local drives using a fixed drive list, whilst LockFile calls GetLogicalDriveStringsA() and processes all drives that are fixed drives.

A separate thread is created for each drive in the list. This thread recursively searches the given logical drive and encrypts files found on it. To prevent paralyzing the compromised PC entirely, AtomSilo has a list of folders, file names and file types that are left unencrypted which are listed here:

Excluded folders
Boot Windows Windows.old Tor Browser
Internet Explorer Google Opera Opera Software
Mozilla Mozilla Firefox $Recycle.Bin ProgramData
All Users
Excluded files
autorun.inf index.html  boot.ini bootfont.bin
bootsect.bak bootmgr bootmgr.efi bootmgfw.efi
desktop.ini iconcache.db ntldr ntuser.dat
ntuser.dat.log ntuser.ini thumbs.db #recycle
Excluded extensions
.hta .html .exe .dll .cpl .ini
.cab .cur .cpl .drv .hlp .icl
.icns .ico .idx .sys .spl .ocx

LockFile avoids files and folders, containing those sub-strings:

Excluded sub-strings
Windows NTUSER LOCKFILE .lockfile

In addition to that, there is a list of 788 file types (extensions), which won’t be encrypted. Those include .exe, but also .jpg, .bmp and .gif. You may noticed that some of them are included repeatedly.

The ransomware generates RSA-4096 session keypair for each victim. Its private part is then stored in the ransom note file, encrypted by the master RSA key (hardcoded in the binary). A new AES-256 file key is generated for each file. This key is then encrypted by the session RSA key and stored at the end of the encrypted file, together with original file size. 

Each encrypted file contains a ransom note file with one of the names:

  • README-FILE-%ComputerName%-%TimeStamp%.hta
  • LOCKFILE-FILE-%ComputerName%-%TimeStamp%.hta

Encrypted files can be recognized by the .ATOMSILO or .lockfile extension: 

When the encryption process is complete, the ransom note is shown to the user. Each strain’s ransom note has its own look:

AtomSilo Ransom Message
LockFile Ransom Message

How to use the Decryptor

To decrypt your files, please, follow these steps:

  1. Download the free decryptor. The single EXE file covers both ransomware strains.
  2. Simply run the EXE. It starts in form of wizard, which leads you through configuration of the decryption process.
  3. On the initial page, you can see a list of credits. Simply click “Next”
  1. On the next page, select the list of locations which you want to be decrypted. By default, it contains a list of all local drives.
  1. On the third page, you can select whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins.
  1. Let the decryptor work and wait until it finishes.


We would like to thank Jiří Vinopal for sharing analysis of both ransomware strains.


SHA filename
d9f7bb98ad01c4775ec71ec66f5546de131735e6dba8122474cc6eb62320e47b .ATOMSILO
bf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce .lockfile

The post Avast releases decryptor for AtomSilo and LockFile ransomware appeared first on Avast Threat Labs.

Decoding Cobalt Strike: Understanding Payloads


Cobalt Strike threat emulation software is the de facto standard closed-source/paid tool used by infosec teams in many governments, organizations and companies. It is also very popular in many cybercrime groups which usually abuse cracked or leaked versions of Cobalt Strike. 

Cobalt Strike has multiple unique features, secure communication and it is fully modular and customizable so proper detection and attribution can be problematic. It is the main reason why we have seen use of Cobalt Strike in almost every major cyber security incident or big breach for the past several years.

There are many great articles about reverse engineering Cobalt Strike software, especially beacon modules as the most important part of the whole chain. Other modules and payloads are very often overlooked, but these parts also contain valuable information for malware researchers and forensic analysts or investigators.

The first part of this series is dedicated to proper identification of all raw payload types and how to decode and parse them. We also share our useful parsers, scripts and yara rules based on these findings back to the community

Raw payloads

Cobalt Strike’s payloads are based on Meterpreter shellcodes and include many similarities like API hashing (x86 and x64 versions) or url query checksum8 algo used in http/https payloads, which makes identification harder. This particular checksum8 algorithm is also used in other frameworks like Empire.

Let’s describe interesting parts of each payload separately.

Payload header x86 variant

Default 32bit raw payload’s entry points start with typical instruction CLD (0xFC) followed by CALL instruction and PUSHA (0x60) as the first instruction from API hash algorithm.

x86 payload
Payload header x64 variant

Standard 64bit variants start also with CLD instruction followed by AND RSP,-10h and CALL instruction.

x64 payload

We can use these patterns for locating payloads’ entry points and count other fixed offsets from this position.

Default API hashes

Raw payloads have a predefined structure and binary format with particular placeholders for each customizable value such as DNS queries, HTTP headers or C2 IP address. Placeholder offsets are on fixed positions the same as hard coded API hash values. The hash algorithm is ROR13 and the final hash is calculated from the API function name and DLL name. The whole algorithm is nicely commented inside assembly code on the Metasploit repository.

Python implementation of API hashing algorithm

We can use the following regex patterns for searching hardcoded API hashes:

We can use a known API hashes list for proper payload type identification and known fixed positions of API hashes for more accurate detection via Yara rules.

Payload identification via known API hashes

Complete Cobalt Strike API hash list:

API hash DLL and API name
0xc99cc96a dnsapi.dll_DnsQuery_A
0x528796c6 kernel32.dll_CloseHandle
0xe27d6f28 kernel32.dll_ConnectNamedPipe
0xd4df7045 kernel32.dll_CreateNamedPipeA
0xfcddfac0 kernel32.dll_DisconnectNamedPipe
0x56a2b5f0 kernel32.dll_ExitProcess
0x5de2c5aa kernel32.dll_GetLastError
0x0726774c kernel32.dll_LoadLibraryA
0xcc8e00f4 kernel32.dll_lstrlenA
0xe035f044 kernel32.dll_Sleep
0xbb5f9ead kernel32.dll_ReadFile
0xe553a458 kernel32.dll_VirtualAlloc
0x315e2145 user32.dll_GetDesktopWindow
0x3b2e55eb wininet.dll_HttpOpenRequestA
0x7b18062d wininet.dll_HttpSendRequestA
0xc69f8957 wininet.dll_InternetConnectA
0x0be057b7 wininet.dll_InternetErrorDlg
0xa779563a wininet.dll_InternetOpenA
0xe2899612 wininet.dll_InternetReadFile
0x869e4675 wininet.dll_InternetSetOptionA
0xe13bec74 ws2_32.dll_accept
0x6737dbc2 ws2_32.dll_bind
0x614d6e75 ws2_32.dll_closesocket
0x6174a599 ws2_32.dll_connect
0xff38e9b7 ws2_32.dll_listen
0x5fc8d902 ws2_32.dll_recv
0xe0df0fea ws2_32.dll_WSASocketA
0x006b8029 ws2_32.dll_WSAStartup

Complete API hash list for Windows 10 system DLLs is available here.

Customer ID / Watermark

Based on information provided on official web pages, Customer ID is a 4-byte number associated with the Cobalt Strike licence key and since v3.9 is embedded into the payloads and beacon configs. This number is located at the end of the payload if it is present. Customer ID could be used for specific threat authors identification or attribution, but a lot of Customer IDs are from cracked or leaked versions, so please consider this while looking at these for possible attribution.

DNS stager x86

Typical payload size is 515 bytes or 519 bytes with included Customer ID value. The DNS query name string starts on offset 0x0140 (calculated from payload entry point) and the null byte and max string size is 63 bytes. If the DNS query name string is shorter, then is terminated with a null byte and the rest of the string space is filled with junk bytes.

DnsQuery_A API function is called with two default parameters:

Parameter Value Constant
DNS Record Type (wType) 0x0010 DNS_TYPE_TEXT
DNS Query Options (Options) 0x0248 DNS_QUERY_BYPASS_CACHE

Anything other than the default values are suspicious and could indicate custom payload.

Python parsing:

Default DNS payload API hashes:

Offset Hash value API name
0x00a3 0xe553a458 kernel32.dll_VirtualAlloc
0x00bd 0x0726774c kernel32.dll_LoadLibraryA
0x012f 0xc99cc96a dnsapi.dll_DnsQuery_A
0x0198 0x56a2b5f0 kernel32.dll_ExitProcess
0x01a4 0xe035f044 kernel32.dll_Sleep
0x01e4 0xcc8e00f4 kernel32.dll_lstrlenA

Yara rule for DNS stagers:

SMB stager x86

The default payload size is 346 bytes plus the length of the pipe name string terminated by a null byte and the length of the Customer ID if present. The pipe name string is located right after the payload code on offset 0x015A in plaintext format.

CreateNamedPipeA API function is called with 3 default parameters:

Parameter Value Constant
Open Mode (dwOpenMode) 0x0003 PIPE_ACCESS_DUPLEX
Max Instances (nMaxInstances) 0x0001

Python parsing:

Default SMB payload API hashes:

Offset Hash value API name
0x00a1 0xe553a458 kernel32.dll_VirtualAlloc
0x00c4 0xd4df7045 kernel32.dll_CreateNamedPipeA
0x00d2 0xe27d6f28 kernel32.dll_ConnectNamedPipe
0x00f8 0xbb5f9ead kernel32.dll_ReadFile
0x010d 0xbb5f9ead kernel32.dll_ReadFile
0x0131 0xfcddfac0 kernel32.dll_DisconnectNamedPipe
0x0139 0x528796c6 kernel32.dll_CloseHandle
0x014b 0x56a2b5f0 kernel32.dll_ExitProcess

Yara rule for SMB stagers:

TCP Bind stager x86

The payload size is 332 bytes plus the length of the Customer ID if present. Parameters for the bind API function are stored inside the SOCKADDR_IN structure hardcoded as two dword pushes. The first PUSH with the sin_addr value is located on offset 0x00C4. The second PUSH contains sin_port and sin_family values and is located on offset 0x00C9 The default sin_family value is AF_INET (0x02).

Python parsing:

Default TCP Bind x86 payload API hashes:

Offset Hash value API name
0x009c 0x0726774c kernel32.dll_LoadLibraryA
0x00ac 0x006b8029 ws2_32.dll_WSAStartup
0x00bb 0xe0df0fea ws2_32.dll_WSASocketA
0x00d5 0x6737dbc2 ws2_32.dll_bind
0x00de 0xff38e9b7 ws2_32.dll_listen
0x00e8 0xe13bec74 ws2_32.dll_accept
0x00f1 0x614d6e75 ws2_32.dll_closesocket
0x00fa 0x56a2b5f0 kernel32.dll_ExitProcess
0x0107 0x5fc8d902 ws2_32.dll_recv
0x011a 0xe553a458 kernel32.dll_VirtualAlloc
0x0128 0x5fc8d902 ws2_32.dll_recv
0x013d 0x614d6e75 ws2_32.dll_closesocket

Yara rule for TCP Bind x86 stagers:

TCP Bind stager x64

The payload size is 510 bytes plus the length of the Customer ID if present. The SOCKADDR_IN structure is hard coded inside the MOV instruction as a qword and contains the whole structure. The offset for the MOV instruction is 0x00EC.

Python parsing:

Default TCP Bind x64 payload API hashes:

Offset Hash value API name
0x0100 0x0726774c kernel32.dll_LoadLibraryA
0x0111 0x006b8029 ws2_32.dll_WSAStartup
0x012d 0xe0df0fea ws2_32.dll_WSASocketA
0x0142 0x6737dbc2 ws2_32.dll_bind
0x0150 0xff38e9b7 ws2_32.dll_listen
0x0161 0xe13bec74 ws2_32.dll_accept
0x016f 0x614d6e75 ws2_32.dll_closesocket
0x0198 0x5fc8d902 ws2_32.dll_recv
0x01b8 0xe553a458 kernel32.dll_VirtualAlloc
0x01d2 0x5fc8d902 ws2_32.dll_recv
0x01ee 0x614d6e75 ws2_32.dll_closesocket

Yara rule for TCP Bind x64 stagers:

TCP Reverse stager x86

The payload size is 290 bytes plus the length of the Customer ID if present. This payload is very similar to TCP Bind x86 and SOCKADDR_IN structure is hardcoded on the same offset with the same double push instructions so we can reuse python parsing code from TCP Bind x86 payload.

Default TCP Reverse x86 payload API hashes:

Offset Hash value API name
0x009c 0x0726774c kernel32.dll_LoadLibraryA
0x00ac 0x006b8029 ws2_32.dll_WSAStartup
0x00bb 0xe0df0fea ws2_32.dll_WSASocketA
0x00d5 0x6174a599 ws2_32.dll_connect
0x00e5 0x56a2b5f0 kernel32.dll_ExitProcess
0x00f2 0x5fc8d902 ws2_32.dll_recv
0x0105 0xe553a458 kernel32.dll_VirtualAlloc
0x0113 0x5fc8d902 ws2_32.dll_recv

Yara rule for TCP Reverse x86 stagers:

TCP Reverse stager x64

Default payload size is 465 bytes plus length of Customer ID if present. Payload has the same position as the SOCKADDR_IN structure such as TCP Bind x64 payload so we can reuse parsing code again.

Default TCP Reverse x64 payload API hashes:

Offset Hash value API name
0x0100 0x0726774c kernel32.dll_LoadLibraryA
0x0111 0x006b8029 ws2_32.dll_WSAStartup
0x012d 0xe0df0fea ws2_32.dll_WSASocketA
0x0142 0x6174a599 ws2_32.dll_connect
0x016b 0x5fc8d902 ws2_32.dll_recv
0x018b 0xe553a458 kernel32.dll_VirtualAlloc
0x01a5 0x5fc8d902 ws2_32.dll_recv
0x01c1 0x614d6e75 ws2_32.dll_closesocket

Yara rule for TCP Reverse x64 stagers:

HTTP stagers x86 and x64

Default x86 payload size fits 780 bytes and the x64 version is 874 bytes long plus size of request address string and size of Customer ID if present. The payloads include full request information stored inside multiple placeholders.

Request address

The request address is a plaintext string terminated by null byte located right after the last payload instruction without any padding. The offset for the x86 version is 0x030C and 0x036A for the x64 payload version. Typical format is IPv4.

Request port

For the x86 version the request port value is hardcoded inside a PUSH instruction as a  dword. The offset for the PUSH instruction is 0x00BE. The port value for the x64 version is stored inside MOV r8d, dword instruction on offset 0x010D.

Request query

The placeholder for the request query has a max size of 80 bytes and the value is a plaintext string terminated by a null byte. If the request query string is shorter, then the rest of the string space is filled with junk bytes. The placeholder offset for the x86 version is 0x0143 and 0x0186 for the x64 version.

Cobalt Strike and other tools such as Metasploit use a trivial checksum8 algorithm for the request query to distinguish between x86 and x64 payload or beacon. 

According to leaked Java web server source code,  Cobalt Strike uses only two checksum values, 0x5C (92) for x86 payloads and 0x5D for x64 versions. There are also implementations of Strict stager variants where the request query string must be 5 characters long (including slash). The request query checksum feature isn’t mandatory.

Python implementation of checksum8 algorithm:

Metasploit server uses similar values:

You can find a complete list of Cobalt Strike’s x86 and x64 strict request queries here.

Request header

The size of the request header placeholder is 304 bytes and the value is also represented as a plaintext string terminated by a null byte. The request header placeholder is located immediately after the Request query placeholder. The offset for the x86 version is 0x0193 and 0x01D6 for the x64 version.

The typical request header value for HTTP/HTTPS stagers is User-Agent. The Cobalt Strike web server has banned user-agents which start with lynx, curl or wget and return a response code 404 if any of these strings are found.

API function HttpOpenRequestA is called with following dwFlags (0x84600200):

Python parsing:

Default HTTP x86 payload API hashes:

Offset Hash value API name
0x009c 0x0726774c kernel32.dll_LoadLibraryA
0x00aa 0xa779563a wininet.dll_InternetOpenA
0x00c6 0xc69f8957 wininet.dll_InternetConnectA
0x00de 0x3b2e55eb wininet.dll_HttpOpenRequestA
0x00f2 0x7b18062d wininet.dll_HttpSendRequestA
0x010b 0x5de2c5aa kernel32.dll_GetLastError
0x0114 0x315e2145 user32.dll_GetDesktopWindow
0x0123 0x0be057b7 wininet.dll_InternetErrorDlg
0x02c4 0x56a2b5f0 kernel32.dll_ExitProcess
0x02d8 0xe553a458 kernel32.dll_VirtualAlloc
0x02f3 0xe2899612 wininet.dll_InternetReadFile

Default HTTP x64 payload API hashes:

Offset Hash value API name
0x00e9 0x0726774c kernel32.dll_LoadLibraryA
0x0101 0xa779563a wininet.dll_InternetOpenA
0x0120 0xc69f8957 wininet.dll_InternetConnectA
0x013f 0x3b2e55eb wininet.dll_HttpOpenRequestA
0x0163 0x7b18062d wininet.dll_HttpSendRequestA
0x0308 0x56a2b5f0 kernel32.dll_ExitProcess
0x0324 0xe553a458 kernel32.dll_VirtualAlloc
0x0342 0xe2899612 wininet.dll_InternetReadFile

Yara rules for HTTP x86 and x64 stagers:

HTTPS stagers x86 and x64

The payload structure and placeholders are almost the same as the HTTP stagers. The differences are only in payload sizes, placeholder offsets, usage of InternetSetOptionA API function (API hash 0x869e4675) and different dwFlags for calling the HttpOpenRequestA API function.

The default x86 payload size fits 817 bytes and the default for the x64 version is 909 bytes long plus size of request address string and size of the Customer ID if present.

Request address

The placeholder offset for the x86 version is 0x0331 and 0x038D for the x64 payload version. The typical format is IPv4.

Request port

The hardcoded request port format is the same as HTTP.  The PUSH offset for the x86 version is 0x00C3. The MOV instruction for x64 version is on offset 0x0110.

Request query

The placeholder for the request query has the same format and length as the HTTP version. The placeholder offset for the x86 version is 0x0168 and 0x01A9 for the x64 version.

Request header

The size and length of the request header placeholder is the same as the HTTP version. Offset for the x86 version is 0x01B8 and 0x01F9 for the x64 version.

API function HttpOpenRequestA is called with following dwFlags (0x84A03200):

InternetSetOptionA API function is called with following parameters:

Python parsing:

Default HTTPS x86 payload API hashes:

Offset Hash value API name
0x009c 0x0726774c kernel32.dll_LoadLibraryA
0x00af 0xa779563a wininet.dll_InternetOpenA
0x00cb 0xc69f8957 wininet.dll_InternetConnectA
0x00e7 0x3b2e55eb wininet.dll_HttpOpenRequestA
0x0100 0x869e4675 wininet.dll_InternetSetOptionA
0x0110 0x7b18062d wininet.dll_HttpSendRequestA
0x0129 0x5de2c5aa kernel32.dll_GetLastError
0x0132 0x315e2145 user32.dll_GetDesktopWindow
0x0141 0x0be057b7 wininet.dll_InternetErrorDlg
0x02e9 0x56a2b5f0 kernel32.dll_ExitProcess
0x02fd 0xe553a458 kernel32.dll_VirtualAlloc
0x0318 0xe2899612 wininet.dll_InternetReadFile

Default HTTPS x64 payload API hashes:

Offset Hash value API name
0x00e9 0x0726774c kernel32.dll_LoadLibraryA
0x0101 0xa779563a wininet.dll_InternetOpenA
0x0123 0xc69f8957 wininet.dll_InternetConnectA
0x0142 0x3b2e55eb wininet.dll_HttpOpenRequestA
0x016c 0x869e4675 wininet.dll_InternetSetOptionA
0x0186 0x7b18062d wininet.dll_HttpSendRequestA
0x032b 0x56a2b5f0 kernel32.dll_ExitProcess
0x0347 0xe553a458 kernel32.dll_VirtualAlloc
0x0365 0xe2899612 wininet.dll_InternetReadFile

Yara rule for HTTPS x86 and x64 stagers:

The next stage or beacon could be easily downloaded via curl or wget tool:

You can find our parser for Raw Payloads and all according yara rules in our IoC repository.

Raw Payloads encoding

Cobalt Strike also includes a payload generator for exporting raw stagers and payload in multiple encoded formats. Encoded formats support UTF-8 and UTF-16le. 

Table of the most common encoding with usage and examples:

Encoding Usage Example
Hex VBS, HTA 4d5a9000..
Hex Array PS1 0x4d, 0x5a, 0x90, 0x00..
Hex Veil PY \x4d\x5a\x90\x00..
Decimal Array VBA -4,-24,-119,0..
Char Array VBS, HTA Chr(-4)&”H”&Chr(-125)..
Base64 PS1 38uqIyMjQ6..
gzip / deflate compression PS1
Xor PS1, Raw payloads, Beacons

Decoding most of the formats are pretty straightforward, but there are few things to consider. 

  • Values inside Decimal and Char Array are splitted via “new lines” represented by “\s_\n” (\x20\x5F\x0A). 
  • Common compression algorithms used inside PowerShell scripts are GzipStream and raw DeflateStream.

Python decompress implementation:

XOR encoding

The XOR algorithm is used in three different cases. The first case is one byte XOR inside PS1 scripts, default value is 35 (0x23).

The second usage is XOR with dword key for encoding raw payloads or beacons inside PE stagers binaries. Specific header for xored data is 16 bytes long and includes start offset, xored data size, XOR key and four 0x61 junk/padding bytes.

Python header parsing:

We can create Yara rule based on XOR key from header and first dword of encoded data to verify supposed values there:

The third case is XOR encoding with a rolling dword key, used only for decoding downloaded beacons. The encoded data blob is located right after the XOR algorithm code without any padding. The encoded data starts with an initial XOR key (dword) and the data size (dword xored with init key).

There are x86 and x64 implementations of the XOR algorithm. Cobalt Strike resource includes xor.bin and xor64.bin files with precompiled XOR algorithm code. 

Default lengths of compiled x86 code are 52 and 56 bytes (depending on used registers) plus the length of the junk bytes. The x86 implementation allows using different register sets, so the xor.bin file includes more than 800 different precompiled code variants.

Yara rule for covering all x86 variants with XOR verification:

The precompiled x64 code is 63 bytes long with no junk bytes. There is also only one precompiled code variant.

Yara rule for x64 variant with XOR verification:

You can find our Raw Payload decoder and extractor for the most common encodings here. It uses a parser from the previous chapter and it could save your time and manual work. We also provide an IDAPython script for easy raw payload analysis.


As we see more and more abuse of Cobalt Strike by threat actors, understanding how to decode its use is important for malware analysis.

In this blog, we’ve focused on understanding how threat actors use Cobalt Strike payloads and how you can analyze them.

The next part of this series will be dedicated to Cobalt Strike beacons and parsing its configuration structure.

The post Decoding Cobalt Strike: Understanding Payloads appeared first on Avast Threat Labs.