Operation WordDrone: Cyber Threats in the Drone Industry

Okay. Hello everyone. Today I'll talk about operation war drone which is a cyber threat that we discovered last year and that uh focuses on the aerospace sector in Asia-Pacific region. But first a bit about myself. My name is Ilia Davchef and I'm a security researcher at Acronis where my main responsibilities are threat research improving our detection capabilities of our EDR and antivirus product. Uh previously I worked as a security analyst where I specialized in digital phrasings and incident response. So why drone? What's uh what's the common thing between word and drones? You might when you see word maybe you think it's yet another uh malicious macro but uh you'd be wrong. The following slides I hope the

connection will become clear. So let's go to the story of discovery. Last year uh June 26th we received a ticket escalation from one of our partners and here I want to just to explain that our customers are usually service providers who provide our product to their own customers. So we don't immediately know who the end user is. They basically asked us that they had edr alert for Microsoft Word and wanted some help uh to understand what actually was happening. We agreed to help them and asked for any data screenshot or or whatever they had that could help us analyze the incident. They send us the screenshot and this is what uh the first evidence of what would later we will

call word John. Do you see anything suspicious here? Maybe you will immediately see that word is launching command command prompt and in turn it also executes uh net.exe and some other commands other indicators. Um, of course the process was stopped. It worked running as the system account, the highest count on on Windows. Uh, it had a suspicious argument. If you search for that as we see a lot on Google, you'll find that word does not support this argument. It executed from a directory where Word is not usually installed. And if you check the hash, uh, it's a legitimate Microsoft Word, but a very ancient version. And what was also suspicious here was that the client

already used a quite recent version. So it didn't it didn't make sense for them to have the two different versions on on the host. Given all all those red flags, we told them that we want to investigate uh further. Uh we started our investigation and here I want to point out that this investigation is from us as an EDR vendor not it was not an incident response customer handled that internally. So our investigation started by reviewing our telemetry around when the incident happened. What we found was that there was a double lip dl in the same folder where that windward uh uh was located. The dl was in the memory space of winward. The hash was not publicly

known. If it was a legitimate Microsoft library, there's a high chance you'll find it at least uploaded somewhere. And there were indicators that potentially a shell code was running uh inside this winward executable. Also winward was ranked as a service which explains why um it was executing with the system account. After that we collected uh telemetry for a larger period of time I think three months and we noticed that the incidents started happening more than months prior the ticket escalation. Some were closed as false positives and some executables in those that were part of the incident were added as exclusions by the customer and he confirmed that he added those for example like pros dump which

was used to dump LSS uh pro memory in order to gather credentials. Reviewing telemetry, we gathered all the paths where winward was located and all of them had this svc load argument and most of them tried to uh use directories that belong to Microsoft or office with the exclusion of the first one with pot player and the bottom one which the path belong to an ERP. P product and this update.exe is a legitimate um component of the CRP product but in this case it was just renamed winward. some of the other commands that were uh executed of course prodump that I already said and it was blocked but after the customer excluded those the the next attempts were successful and of

course most likely attackers were able to gather credentials. Attackers also tried to dump uh the system hives uh the registry hives in order again to access credentials. Some other tools that were used was uh an attempted use of true site killer which is a known edr killer that uses a vulnerable driver. Sharp RDP log which was unknown to me at that time and more that on the next slide. for um for later movement attackers use WMA exec and several commands we gathered that were were the parents of those commands were winward or do host task list task q IP config net pingest the usual uh commands you might see when the attacker tries to understand uh the

system regarding sharp RDP log. It turned out that it's just a simple um user enumeration tool that enumerates the user accounts which success either successfully or failed to login with RDP in in the past. and it had very simple options because telemetry provides just limited information uh of what happened. We asked if the customer could provide us with hostbased artifacts like files that we observed logs and disk images that we would analyze forensically in each folder where winward was located. We found of course a d lip that we already saw in telemetry winward itself and one randomly named file. Uh there were three different dls like three different hashes and three different random files. Two of the DLS were validly

signed and none were publicly known. So at this point uh we asked oursel what is known about this DIP what actually it is. uh when you search for it, we found that there was a known sideloading vulnerability in Microsoft Word. Some some versions of Microsoft Word and predominantly it was abused by threads like Valerat, Luminous Moth, Mustang Panda at least those were the most frequent articles that that came up. When we check the code of the DL and compared it to the ones in those cases, we noticed that it is something new that uh it look very different. It was something new that nobody else had written about yet. Um this meant that either this is a very

new threat still not widely spread or very targeted or both new and targeted. So this made us ask ourself who was actually the victim. As I said earlier, we don't immediately know who the end user is. It turned out it is a Taiwanese manufacturer of aerospace components and drones which made things a bit uh more interesting. We continued to invest to try to determine how initial compromise happened. Unfortunately, because it happened more than a month ago, the the hostbased artifacts were not that useful. logs have rotated u registry time stamps were not uh that useful anymore etc. Telemetry gives uh a limited view of what actually happens and regarding this update.exe that we saw earlier this is the first

alert ever detected uh at the victim. So this update.exe Exe as I said was a legitimate component of the ERP product. It's responsible for regularly checking for updates. So attackers maybe managed to replace it with winward executable and on the next update check it will get executed in infection chain would start. There were recent vulnerabilities around the time when uh our investigation was running in this exact ERP product some of them with very high severity. The vulnerabilities were regarding um a component in the ERP product. I don't know if it was uh used in the ERP product but it was an interesting observation and later in August there was also an arbitrary file download in the same uh

year component of that ERP product. So we don't have enough data and our hypothesis at this time is either an exploit in the ERP product or exploit in another service probably in the system and which would allow attackers to replace update.exe component or supply chain attack. This is uh a summary of the detections. Not no not all of them are shown but first detection happened early May uh in the client with the update.exz Z some recon commands uh were ex executed attempted through site killer attempted attempted process dump. Another location was used was tried for winward and two days later process dump was excluded by the [Music] customer. On 16th um there was another detection for winward. They tried again

with theite killer. They tried twice process dump at least one was successful because of the exclusion. They tried two times for for the dumping registry hive and sharp log. The next interesting detection was on 20th of June. So on one one month passed uh they used this time for some reason the pot path. On the next day, uh there was detection on a nearp DB and backup server uh that with the detection was related to WC Wex uh two and execution under program files. 5 days later, customer raised the ticket and our investigation started. At this point I also want to say that we didn't have complete visibility in the environment because customer used two security

products. So some of them were uh some of the host probably had one product and some ours. So uh our view was partial in the environment and we were not involved in the in the incident response process. Now let's delve into the internals of word drone. As I said it starts with side loading uh in with word which sideloadads wip dl. This dl was a 32bit dl compiled maybe one week before the first detection. It didn't have any exports. All uh all functionality was in the D main function. Uh two of those were signed validly with a certificate from that belonged to a company producing industrial uh embedded systems and it was also located uh in the Asia- Pacific region

and it was valid. Those are in uh the time stamps are in uh in a US format. So they were valid at least at the beginning of the attack and after that the next iterations of WIP were no longer signed when this certificate

expired. D lip uses fibers instead of threads and has a check for the host process the process which loaded the DL. It checks the entry point for that process and compares it with this hardcoded value. the result if it if the recoil would be zero or because of the exor operation will be saved saved in edx this result will later be used in uh other calculations so if it's different than zero the program will will crash if they're not equal so by this way it makes sure it is loaded only by winward process for example here edx is used as an offset if it is anything different than zero, it will modify um a different field in the fiber

structure than what was intended and it it originally intends to modify the pointer to the function which the fiber would execute which originally is configured to execute a wrapper to message box A. But after this modification of the undocumented fiber structure, it will execute um continue with the malicious part of the of the code. The loader is fairly simple. Uh it lost the randomly named file we saw earlier from disk. Performs another check for the entry point. If all is good, it uses the size of the um encrypted file on disk, its own size as a as a key. And with a basic XR operation, the decryption, it decrypts the contents. The execution is also fairly

simple. It pushes a pointer of the decrypted buffer on stack and returns which effectively transfers execution to the next stage. The next stage is a simple shell code loader. Uh uses API hashing and decompress buffer to decompress the next stage uh which reflectively self- injects another DL and cause its export install setup. So the next stage is another DL install DL with install setup exported function which is responsible for persistence. It has a hardcoded configuration and supports three actions. It can create service, create a task or self inject. In our case, it was configured as a service. And below uh below the fact we specified which action to take, you can see the service configuration like the

service name, the service display name, and the service description. But let's look at each action individually. Process injection, it supports two targets. It can inject either in itself in this case winward or inject in SBC host using the following arguments. Uh the injection is again a reflective DOM injection. Uh and the next stage uh has an export de setup that gets called. The loader shell code is being called with the undocumented ent create redex function. The service creation which was our case started by checking svc if svc load argument is in the command line. If it is it registers a service with the current path and command line and appends the svc lot to the to the end of

the command line. If registration fails for some reason it it calls inject process and just injects into itself and continues execution. If SVC load is found uh it performs validation to check if the process indeed started as a service. If all is good that it has as we saw in the argument it is running as a service then it injects the next stage to itself. By this it makes sure it is running with uh system level privileges. Task creation uh it is similar to the service creation but uses task load as an argument and common object model for the task creation. Client endpoint DL is the main the main component of war drone where its main logic is uh

used. It starts execution with NDLL on hooking using blind side technique. This technique uh it creates a new process in a debugged state and places hardware breakpoint on loader load DL function. When that breakpoint is hit in the remote process, this makes sure that only NDOL is loaded at that time. So no other user mode libraries like cooking libraries are in the process. After that the malicious process copies the text section of that clean entl effectively removing any user mode hooks. On this slide I just wanted to show that the attackers basically copy pasted the code from GitHub. Uh the steps in the code are exactly in the same order. the the same loops etc. After this

uh the NTD hooking it also used EDR silencer. It was again compiled into into the binary and again the code was basically copy pasted with minor modifications by removing prints and some other small things but basically it was the same even the order of the security products which is our targets with your silencer targets is exactly the same and if you know if anyone doesn't know silencer is a tool which blocks better communication of the hardcoded EDR product processes. So they can can't send alerts to their EDR console. Client endpoint also has hard-coded configuration which is quite large. I haven't reversed it fully only a small part of it but there it defines what uh module to run. It

supports two main modules. Client module and server module. Both can be enabled or only one could be enabled. In our case, only client module was enabled. And most of my analysis is on that one. So I'll briefly mention the the small thing I know about server module the because I haven't analyzed it that much is that as name suggests it starts working as a server listening on some port and supports accepting communications from several protocols like SMB uh HTTP TLS etc. My hypothesis for it is that it is used as a proxy. So when other infected clients are configured to communicate to the one that is configured as a server, the server one we will send the

communication to the command control. That way only communication happens only through one infected host and you don't see communication from uh every infected host uh to the outside. So client module it starts by checking the current time. It takes the current hour and compares it to an array uh with uh flags which represent each hour in the week. If the flag is one then network communication is allowed otherwise it sleeps. In this way, attackers can specify very u very precisely at what time they want to communicate to allow communication to the commotent control. In our case, uh it was allowed all the time. Regarding network communication, it supports several protocols but it uses them as

transport and above them uh it transports its own custom protocol. The supported protocols are TCPS, SMBTS, HTP, HPS and websocket which as you can see from the screenshot in our case uh websocket was used as transport. The the frame of the custom protocol starts with two random bytes uh in the header and three fields which were exor encrypted. The first field is the action code which is the action which the the content control server asks from the client to execute. Result code is the result which the client will respond. If the action was successful, it will send zero or some error code otherwise. Target hash is a custom hash that is calculated over uh the host name and the username which

allowed the attackers to specify not only at what on what host to execute uh the given command but also as what user and in the end is the payload which is as in counter encrypted and zip compressed the payload itself self had its own format which differed for each action code although it was not um it was not obuscated it was hard to understand completely all the functionality of the action codes I haven't mentioned it before but it's written in C++ so a lot of objects a lot of VF tables a lot of indirect calls happen. So which statically it's very hard to follow the logic. So we have to do it dynamically. But to do it dynamically,

you need an active C2 server. But in our case, it was not longer active or it was geofenced. So the first step was to write a C2 emulation script, start debugging and send for example command one and follow uh the execution flow to see what happens. Um and for you take for example in this case um the the error handling branch because some bite in the payload was wrong. It is a binary protocol. So it's not like you can compare strings. For example, execute command X and take that branch. Then send command one again with proper content but again take uh wrong path because somewhere there was another wrong bite in the payload. So repeat this until all until

the meaning of u all byes and their meaning is figured out in the payload. then proceed with command two again error because it expects a different format. So you repeat repeat this process for the rest of the 50 commands and you can see that even though it's not offiscated it's very time consuming without without having a recording of the C2 traffic as you have to uh understand uh the meaning of each bite in the payload which is not immediately clear in the code. Some of the action codes that I was able to figure figure out were number two in hex which just collects basic user and operating system information and send to the commanding control injecting another DL into DOL

host. If you remember previously DL host was the parent of uh some of the commands seven just is just just basically ping the C2 server ping as a client. it will send back the exact same data that the the C2 uh sent. 15 executes shell code 24 changes the operation to uh server mode. So it starts listening on some port and supports uh almost the same protocols. The difference that here it supports UDP and previously it's uh the server module in the beginning didn't support UDP. 26 uh makes the the client to connect to to another infected host that is configured as a server. Link manager is a module which which implements this functionality. Uh at the top you can see action code

and then a switch statement which uh handle handles uh where uh which branch to to take depending on the action code. Left function says the operation to server mode. The right function uh makes it connect to some some others. the server function had some string that indicated that when SMB is used maybe it uses some local SMB tunnel I haven't analyzed the full functionality otherwise if another protocol is used it just tells that it's listening on on some port and above are just some of the supported protocols session manager is another uh module which when executed it enumerates each session on the host, each user session on the host. For each session, it enumerates processes in that session.

um finds explorer.exe in that user session and copies the user token uh of that explorer exe. Then creates the host process in suspended state with that user token. basically uh prepares for inject in injection and again reflectively injects this session server DL into DL host and calls DSS start export exported function. Communication between client endpoint and session server happens through named pipes and the name of the pipe has the session ID of the of the user. So this session server is injected into each user session on the host and it supports subset of the commands of client endpoint. So when a command uh command is sent from the command control to be executed a specific user it gets sent to

the session server and it executes it as the as the said user in its own session. This is summary of the infection chain. So winward sideloadads d lip d lip um loads the encrypted payload from disk calls the next hell code which then self- injects installed dl which then starts service and if it's uh uh and if it starts successfully as service in our case it injects client endpoint which starts communicating with the comet and control if certain command is sent then it also injects session server into each user session and communicates through named pipes. While the investigation took place, we also hunted for new samples uh uh in our telemetry but also set up

hunting rules in virus. In virus, you can set y rules. So when someone uploads a sample that matches your rule, you get notified. Uh and this is the timeline of from where we saw samples being uploaded. The country of origin from where the sample is uploaded does not mean uh that there uh it there was a victim there. It could have been maybe a security company that worked with someone in that region and they uploaded it uh from their own country. So in April there was an upload in Taiwan uh from Taiwan. This was a sample that uh we haven't seen our case. Then in July there was an upload from Canada. Uh that's one of the samples we

had in this case. Then in again in July an upload from US. This was a new sample and they basically differed the new samples here differed mainly their configuration uh in August. There's an upload again from Taiwan. Um this was was one that we already seen in our case. In September we published uh a blog with our findings. There was an upload from China with test.txt txt probably testing detection. I don't know. Then in October there's an upload again in Taiwan. In November it was from South Korea but this was interesting that it was the next stage payload. It was installed and it looked like it was dumped from memory. So someone was probably investigating another incident.

Dump dumped it from memory and upload it to virus total. And this sample was different than what we had. It had some new new functionality in it. January this year there is an from Singapore. And just last month there was another port from South Korea uh which is almost the same with the one from November. It was again installed DL again dumped from memory and had some new functionality. So regarding those was new in those two two samples they didn't had EDR silencer no more the target hash was changed to now also includes the goid path of the C drive and the server module used now used wind divert driver. Wind divert is a network driver, open source network

driver with which you can capture packets, sniff network packets, drop, inject, modify, whatever you want. I didn't have time to fully understand how it is used, but it is used in the yeah in the server module. Or maybe somehow it aids the the C2 communication or maybe hides the the port on which it listens. I don't really know. Some additional investigation was for the C2 servers. they were behind Cloudflare. But using historical DNS records, we were we were able to find uh the actual IP behind uh Cloudflare Cloudflare. All of them were hosted in the target

conting running running with an opensh port. The window driver was signed again by a company that Asia Pacific region uh and interestingly it was a security company uh just it was an interesting observation and that was it from me. Thank you. If you want to make sure your clothes are