Operation WordDrone – Drone manufacturers are being targeted in Taiwan

Authors: 

Ilia Dafchev, Security Researcher

Irina Artioli, Cyber Protection Evangelist

Alexander Ivanyuk, Senior Director

Robert Neumann, Head of Acronis Cyber Protection Operations Center

Introduction

When Microsoft shipped Office 2010 around the summer of the same year, drones were not a thing, at least until Parrot changed gear and introduced models with built-in cameras. Fast forward more than a decade, and everything is vastly different, except that Microsoft Office 2010 is still rarely used.

That was our initial expectation when we began investigating a customer escalation from Taiwan about a strangely behaving process of an ancient version of Microsoft Word. What we have discovered over the course of the investigation has put Microsoft Word and drones into a new perspective.

Summary of the attack

Attackers used a dynamic-link library (DLL) side-loading technique to install a persistent backdoor with complex functionality on the infected systems. Three files were brought to the system: a legitimate copy of Winword 2010, a signed wwlib.dll file and a file with a random name and file extension. Microsoft Word was used to side load the malicious wwlib DLL, which acts as a loader for the actual payload, the one residing inside the encrypted file with a random name.

The payload starts with the execution of a shellcode stub which decompresses and self-injects the install.dll component. This component is responsible for establishing persistence and executing the next stage: ClientEndPoint.dll. It implements the core functionality of the backdoor, has hard-coded configuration compiled into the binary and supports receiving commands from a command and control server. Depending on the received command, it may inject another payload called SessionServer.dll into a dllhost process.

Acronis
Figure 1 – Incident screen with Winword executing commands via cmd.exe

During their operation, attackers moved the above set of malicious files into different directories and also changed the name of the service used for persistence. The following tools and commands were observed being used:

  • Impacket wmicexec to spread internally to other hosts in the local network.
  • Credential dumping was attempted using the tool ProcDump and also by using “reg save” commands to save the SYSTEM and SAM registry hives.
  • Attackers attempted to use the TrueSightKiller tool.
  • SharpRDPLog, a post exploitation tool to export RDP related information like mstsc cache, cmdkey cache and RDP login logs.

Technical details

When one Word is not enough

Our investigation started with a customer complaint of Acronis Advanced Security + XDR detecting suspicious Winword activity, but it could not be determined what document was loaded. The request not only looked strange due to an unusual path and command line used with a never before seen “SvcLoad” parameter, but it was also reported that another version of Winword was already deployed on the workstation. After a quick look, it could be easily determined that we are dealing with an ancient version of Winword dating back to 2010, but more importantly it was being setup as a service for persistence.

Side loading

In the very same directory where Winword was located, we could see only two additional files, a dynamic load library (DLL) called wwlib.dll, which is normally part of a standard Microsoft Office installation package — this time having an unusually small size — and another file called “gimaqkwo.iqq” which already looked suspicious. This specific version of Winword (v14.0.4762.1000) reportedly had a side-loading vulnerability, which means an attacker could leverage Winword to load a DLL that had a name that matched the original supplied by Microsoft.

The loader — wwlib

Upon further inspection, the wwlib library turned out to be acting as a loader with the sole purpose of reading the main payload that is stored in an encrypted file (“gimaqkwo.iqq”) in the same directory. The DLL doesn’t have any exported functions, and execution starts from DllMain. A very distinctive feature of the loader is the use of fibers instead of threads. It calculates the relative virtual address (RVA) of the entry point (EP) for the Winword process hosting it, and compares it with a hard-coded value in several places in its code to ensure execution continues only if the correct Microsoft Word version is being used.

Acronis
Figure 2 – Example code of using fibers

Note that during our investigation, we collected several copies of the wwlib loaders. Some of them were digitally signed with a valid certificate and only expired during the campaign. We have no evidence of these signatures being used in earlier attacks; however, a search for the thumbprint on VirusTotal revealed no associated files. This means that not only could threat actors bypass some security solutions that fully trust signed binaries, but the malware deployed by them could leverage the valid digital certificate in previous attacks since 2021.

Encrypted payload

The file name of the payload is stored in an encrypted form in the loader. The loader then decrypts the file name, reads its contents, decrypts them with another algorithm, changes the memory protection to add “execute” rights and jumps to the payload by pushing its address onto the stack and then returning to it. The size of the encrypted payload file is used as a key for its own decryption.

Acronis
Figure 3 – Example code of using file size for decryption key

Shellcode

The shellcode has no extraordinary features besides API hashing; its main purpose is the loading of the next stage, which is yet another library called install.dll. First, it decompresses the library using the RtlDecompressBuffer API, then self-injects it into its own memory space and finally calls the “InstallSetup” export.

Acronis
Figure 4 – Example code of decompressing the install.dll

The Installer — Install.dll

The installer component has a hard-coded configuration, specifying the method of persistence to be used and any supporting information needed, such as the name and description of the service. It supports three different types of operation:

  • Installing the host process as a service, appending “/SvcLoad” to the command line, and starting the service.
  • Installing the host process as a scheduled task, appending “/TaskLoad” to the command line.
  • Injecting the next stage, but not setting up persistence.

In our specific case, install.dll was configured to install the service as the method of persistence. If the current process already has “/SvcLoad” in its arguments and is already running as a service, install.dll self-injects the next stage (ClientEndPoint.dll) and calls an export named “DrSetup” with the help of the NtCreatedThreadEx API function. When the scheduled task option is configured, it uses COM to interact with the Windows Task Scheduler and uses the “/TaskLoad” command line.

Note that depending on its configuration, instead of carrying out self-injection, install.dll is capable of injecting into the svchost process as well.

Acronis
Figure 5 – Example code of svchost being created prior to injection

The final stage — ClientEndPoint.dll

This final stage starts with carrying out two very important steps: First, it loads a fresh NTDLL library to remove any possible hooks if they were planted. Second, it silences popular anti-virus and EDR products.

NTDLL unhooking is done by starting a fresh notepad.exe in debugged state, setting a hardware breakpoint on LdrLoadDll, breaking when NTDLL gets loaded, then copying over the .TEXT section into the originally loaded NTDLL, thus removing any potentially installed hooks if they were present. This code is based on the Blindside technique.

Acronis
Figure 6 – Example code of NTDLL unhooking

EDR silencing is done by checking the current process list, looking for process names of popular EDR products. In case of any matches, a blocking rule will be added for the process in the Windows firewall. We believe this functionality was taken from a popular tool called EDRSilencer, as they share the same core-functionality — with printfs and some branches removed — and the list of EDR products is in the exact same order like in the GitHub project.

Acronis
Figure 7 - List of security processes

If the malware finishes execution, it will remove the entries from the Windows Firewall. Once NTDLL unhooking and EDR silencing is completed, the backdoor will check if Command-and-Control communication is enabled in the hard-coded configuration.

Command and Control

As stated above, the optional Command-and-Control communication is already preconfigured in the embedded configuration using a custom binary format. The configuration has a bit array representing every hour in a given week (7days * 24 hours = 168 entries). If the current hour is represented by “1” in the array, then Command-and-Control communication is allowed.

Acronis
Figure 8 – Example code of the time-based command and control check

Another part of the configuration contains the Command-and-Control domain, port and the protocol to be used for transport. The malware supports the following protocols as for transport: TCP, TLS, SMB, HTTP, HTTPS and WebSocket; however, the data transmitted over these protocols utilizes a custom format. For example, our samples were configured to use plain WebSocket as transport, but after the initial handshake, the communication continues using binary data in a custom format.

Acronis
Figure 9 – WebSocket based communication using a simulated C2

When connection with the Command and Control is established, the backdoor is capable of receiving additional payloads and commands using the custom binary format. The content of the final payload depends on an action code and whether it’s a request or a response from the client. Some action codes require no data in the payload, but headers are still sent. Additionally, the custom communication scheme has a “Target Hash” field, which is a hash calculated over the hostname and username of the infected target. Some functions require the “Target Hash” to match the currently infected target prior to their execution.

Acronis
Figure 10 – The network communication scheme

The samples we observed were configured with time[.]vmwaresync[.]com and server[.]microsoftsvc[.]com as for their embedded Command and Control server. The first domain was registered on January 31, 2024 and the second April 17, 2024. Both used “NameSilo, LLC” as Registrar and were protected by Cloudflare at the time of the investigation. Using historical passive DNS records, we were able to find the IP addresses to which those domains resolved prior to using Cloudflare. The former — time[.]vmwaresync[.]com — resolved to 45.121.50[.]185 and 103.61.139[.]60, both of which are located in Taiwan, and according to ASN and WHOIS data, they are part of “Emagine Concept” ISP and assigned to “Xiang Ao Communications” organization. We couldn’t find a date for the latter —server[.]microsoftsvc[.]com but the second-level domain microsoftsvc[.]com at some point resolved to 45.121.50[.]30, which is also located in Taiwan, is part of “Emagine Concept” ISP, and is assigned to “Xiang Ao Communications” organization.

Backdoor capabilities

ClientEndPoint first verifies if the command and control is reachable, and if it is, an HTTP request will be sent. The expected response should begin with “HTTP/1.1 101“ — otherwise, it is considered invalid. If this first response is correct, then data exchange may continue between the Command and Control and the client.

Acronis
Figure 11 – Example code of HTTP response verification

There is a total of 59 possible values for ActionCode, but not all of them led to a meaningful code path during our investigation — some just redirected to the default case or returned a predefined error code, while others might be reserved for future use. We could successfully identify at least 30 different branches; however, due to the lack of sufficient network data and the use of the custom binary format, analysis could not be completed on all of them at the time of this writing.

Some ActionCodes include:

  • 0x0002: Collect user and OS info.
  • 0x0009: Inject SessionServer.dll into dllhost.
  • 0x0007: Echo back the received data.
  • 0x0015: Execute shellcode.
  • 0x0024: Open a port locally and start listening to it. Supported protocols, depending on what was sent from command and control, include TCP, TLS, SMB, HTTP, HTTPS, UDP and WebSocket.
  • 0x0026: Connect to an address. Supported protocols, depending on what was sent from command and control, include TCP, TLS, SMB, HTTP, HTTPS, UDP and WebSocket.

We have limited understanding of codes 0x0024 and 0x0026, but based on their observed capabilities — listening and connecting over the same transport protocols supported for Command and Control communication — we suspect the backdoor can be used in a so-called proxy configuration mode. In this case, one infected host can receive data and commands from another infected host on the local network, and only one of them is in direct communication with the Command and Control. This would further reduce the chances of discovery by limiting Command-and-Control communication to only one dedicated host.

Note that if SMB is chosen as the communication protocol, the above action codes could possibly establish an SMB tunnel as it is indicated by some of the strings found during analysis.

Acronis
Figure 12 – Strings related to SMB tunnel functionality

The mysterious bit – SessionServer.dll

Some interesting functionality was revealed while we were analyzing all the possible action codes — 0x0009 in this case. The access token of the explorer process is duplicated — along with the environment variables — a new dllhost process will be created with the captured token and environment, and then SessionServer.dll gets injected into that dllhost. SessionServer creates a named pipe in the form of \\.\pipe\user-s<user_session_number>, and then ClientEndPoint sends data to that named pipe. SessionServer only supports a subset of the commands which are supported by ClientEndPoint.

The purpose of SessionServer is not completely understood yet. But based on our telemetry and behavior we have observed, we suspect it is used to proxy execution of commands such that they’re executed with dllhost in user context as parent and not winword.exe in SYSTEM context, which might be suspicious. The data exchanged over the named pipe is in the same custom binary format that is being used for normal command and control communication.

Mimicking ERP components

We couldn’t find definitive evidence about how attackers were gaining initial access; however, the first appearance of the malicious files was inside the folder of a popular Taiwanese ERP software called Digiwin. Upon further investigation, we found multiple components of Digiwin software solution being deployed in the target environments. Digiwin was originally established in Taiwan, but they later moved their headquarters back to China, and they are currently considered the leader of Taiwan’s ERP software industry.

We have found that Digiwin’s original Update.exe was replaced by winword.exe under the “C:\DigiwinSCP\SCP\ServiceCloudButler” folder, and besides the original parameters of “--checkForUpdate http://es-update.digiwin.com/full/ServiceCloudButler/,” an additional “/SvcLoad” was also appended. Update.exe would be executed as part of Digiwin’s auto update workflow.

It is important to highlight that some of Digiwin’s components contained known vulnerabilities like CVE-2024-40521 — with a CVSS score of 8.8. Based on all the information collected, we believe that there is high probability of exploitation or a supply chain attack being involved with the ERP software in question.

Attack chain

The following chart showcases the execution chain of the backdoor and the various components of the attack.

Acronis
Figure 13 – Execution chain of the backdoor

Attack timeline

We have observed similar cases across multiple environments between April and July 2024. The first stage of the attacks seemed to be focused on Windows Desktop machines, while in the second stage attackers were trying to move over to Windows servers. Lateral movement seemed to be achieved utilizing WMI in the following way:

“wmiprvse.exe-secured-Embedding; => cmd.exe /Q /c <command> 1> \\127.0.0.1\ADMIN$\__<random>.<random> 2>&1;”

Where command can be one from the captured list:

  • tasklist /svc
  • hostname
  • cd <folder>
  • winword.exe
  • tasklist /svc |findstr winword

Why Taiwan?

Drone manufacturing has increased significantly in Taiwan since 2022, with financial backing from the government. In August 2022, the central government opened UAV AI Innovation Application R&D Center in Chiayi County, and an NT$50 million tender for commercial-grade drones for military applications — the largest tender ever in Taiwan — was offered for 3,000 drones. There are about a dozen companies in Taiwan participating in drone manufacturing — often for OEM purposes —and even more if we look at their global aerospace industry. The country has always been a U.S. ally, and that, coupled with Taiwan’s strong technological background, makes them a prime target for adversaries interested in military espionage or supply chain attacks.

The extreme growth of the drone industry in the past decade also had an unfortunate side effect — even consumer models are used for military purposes now. They are perfectly capable of carrying smaller weapons, as footage reveals from ongoing conflicts around the world. Manufacturers targeted in campaigns we observed are not even remotely in the same league as Parrot or DJI.

Considering all the information we could gather during the investigation of this campaign — the use of a long-lasting digital certificate from a company based in Taiwan, all Command-and-Control servers being located in Taiwan and the targeted companies being based in Taiwan — we can conclude that Operation WordDrone is a highly sophisticated, targeted attack with careful planning and execution by the threat actors.

Note that we’ve reached out to TW CERT and shared all the available information we had with them.

Conclusion

The presence of a highly outdated version of Winword is not necessarily a sign of malicious activity by default; however, when its execution is coupled with an unusual command line, and there is no visible sign of any document being loaded, it raises concerns immediately. Our case reflects the fact that motivated and sophisticated threat actors are scaling down from the enterprise level to the midmarket and even to small businesses. It is not the size of the target that appeals to them, but rather the chosen victim’s profile. Small businesses should reconsider the depth of their defense, as traditional AV solutions are no longer efficient against the type of advanced threats they might face in the near future.

Protection statement

Acronis Advanced Security + Extended Detection and Response (XDR) successfully detects components used in Operation WordDrone and blocks access to the Command-and-Control servers if URL protection is enabled.

IOCs

SHA256 Hashes:

winword.exe

Microsoft Office 2010, x32, v14.0.4762.1000  - 8cfb55087fa8e4c1e7bcc580d767cf2c884c1b8c890ad240c1e7009810af6736

wwlib.dll

Loader.dll gets side-loaded by Winword. 19bbc2daa05a0e932d72ecfa4e08282aa4a27becaabad03b8fc18bb85d37743a 74096848382ffb86a5ff0c7811b9867ad97f83d3f406b2c5aa9f357e1619fe21 f13869390dda83d40960d4f8a6b438c5c4cd31b4d25def7726c2809ddc573dc7

install.dll

Responsible for persistence. 21e6a198f98ba960e073bab6c9a4f0384a938d0ac7535d7f16b5935b5bbdfa61 d6bedad375c34999966c84dd56350961c5a99cfa89b0cd5e10aaba737d3b451f 35bd7839a815d65604f3ca85a3c473266c31779946728b9a14dc6020f0b707ac

ClientEndPoint.dll

Main payload. Implements the core backdoor functionality. d9531e53036c5d04fbe7d1aeae2988c3bf0fdec63774690c5df70cc121af8de4 d8d6dcb17ea0be642c2aef7ee7164a69cd0da1824c138fdb9e931f54cbe5c121 dbed5812f7dbf8ff2276f896ba2ad6b1c206c2cf2569667348c7f47048032e65

SessionServer.dll

The complete purpose is not fully understood yet, but possibly used for proxy execution. 7401e1fd539a219ef3708c9b4a9dac17efe42052b5032986c6d8dfd5a6836e14

gimaqkwo.iqq

Encrypted payload

a8cc9a58e0ce2be1b238867043ba846da75c4279ea201956e0ad70914b3d9f43

knqfqvm.ursr

Encrypted payload

517522c3ad24f48ed54094df2a800f2dab3270f2b026febec9eb9728c45dee5c

povqvk.en

Encrypted payload

f3897381b9a4723b5f1f621632b1d83d889721535f544a6c0f5b83f6ea3e50b3

wwlib certificate

  • Thumbprint: 6da5a78f57fcc9e00e76d6c6ae0461a291653cc0
  • Valid from: 07.05.2021
  • Valid until: 07.05.2024
  • CN: PORTWELL INC.

Service names used:

  • CertProSvcsec
  • SearchIndexHost

Paths used by attackers to deploy the backdoor:

  • C:\DigiwinSCP\SCP\ServiceCloudButler
  • C:\Program Files\Microsoft Office 15\ClientX64\
  • C:\Program Files\Microsoft Office\root\Office15
  • C:\Program Files\Microsoft\
  • C:\Program Files (x86)\Microsoft\
  • C:\Program Files\DAUM\PotPlayer\Skins\

Post-exploitation commands:

  • C:\Windows\Temp\procdump.exe  -accepteula -ma lsass.exe lsass.dmp;
  • C:\Users\<user>\procdump.exe  -accepteula -ma lsass.exe 1.tr;
  • reg  save HKLM\SAM ./Sam.hiv
  • reg  save HKLM\SYSTEM ./Sys.hiv;
  • C:\Windows\Temp\TrueSightKiller.exe
  • C:\Windows\Temp\SharpRDPLog.exe

C2 domains:

server[.]microsoftsvc[.]com

- Registered: 2024-04-17 

- Registrar: NameSilo, LLC.

- Protected by Cloudflare

time[.]vmwaresync[.]com.

- Registered: 2024-01-31

- Registrar: NameSilo, LLC.

- Protected by Cloudflare

C2 IPs:

45.121.50[.]30

- ISP. Emagine Concept, Inc.

- Org: Xiang Ao Communications

- Taiwan Historical

- DNS record for: microsoftsvc[.]com

45.121.50[.]185

- ISP: Emagine Concept, Inc. .

- Org: Xiang Ao Communications

- Taiwan

- Historical DNS record for: time[.]vmwaresync[.]com

103.61.139[.]60

- ISP Emagine Concept, Inc.

- Org: Xiang Ao Communications

- Taiwan

- Historical DNS record for: time[.]vmwaresync[.]com

Possible parent processes for post-exploitation commands:

  • winword.exe
  • dllhost.exe
  • svchost.exe