• Cisco Talos is actively tracking an ongoing campaign targeting users in Ukraine with malicious LNK files, which run a PowerShell downloader, since at least November 2024. 
• The file names use Russian words related to the movement of troops in Ukraine as a lure. 
• The PowerShell downloader contacts geo-fenced servers located in Russia and Germany to download the second stage Zip file containing the Remcos backdoor. 
• The second stage payload uses DLL side loading to execute the Remcos payload. 
• Talos assesses with medium confidence that this activity is associated with the Gamaredon threat actor group. 

 

Phishing campaign using the invasion of Ukraine as a theme 

The invasion of Ukraine is a common theme used by the Gamaredon group in their phishing campaigns and this campaign continues the use of this technique. The actor distributes LNK files compressed inside ZIP archives, usually disguising the file as an Office document and using names that are related to the invasion.  

Although Talos was not able to pinpoint the exact method by which these files are distributed, it is likely that Gamaredon continues to send phishing e-mails with either the ZIP file directly attached to it or containing a URL link to download the file from a remote host.  

Below are some examples of file names used in this campaign: 

Original Name	Translation
3079807576 (Шашило О.В)/ШАШИЛО Олександр Віталійович.docx.lnk	3079807576 (Shashilo O.V)/SHASHILO Oleksandr Vitaliyovich.docx.lnk
3151721177 (Рибак С.В)/РИБАК Станіслав Вікторович.docx.lnk	3151721177 (Rybak S.V)/RYBAK Stanislav Viktorovich.docx.lnk
3407607951 (Жолоб В.В)/ЖОЛОБ Владислав Вікторович.docx.lnk	3407607951 (Zholob V.V)/ZHOLOB Vladislav Viktorovich.docx.lnk
3710407173 (Гур’єв П.А)/ГУР’ЄВ Павло Андрійович.docx.lnk	3710407173 (Gur’ev P.A)/GUR’EV Pavlo Andriyovich.docx.lnk
Вероятное расположение узлов связи, установок РЭБ и расчетов БПЛА противника. ЮГ КРАСНОАРМЕЙСКА.docx.lnk	Probable location of communication nodes, electronic warfare installations and enemy UAV calculations. SOUTH OF THE RED ARMY.docx.lnk
ГУР’ЄВ Павло Андрійович.docx.lnk	GUR’EV Pavlo Andriyevich.docx.lnk
Координаты взлетов противника за 8 дней (Красноармейск).xlsx.lnk	Coordinates of enemy takeoffs for 8 days (Krasnoarmeysk).xlsx.lnk
Позиции противника запад и юго-запад.xlsx.lnk	Positions of the enemy west and southwest.xlsx.lnk
РИБАК Станіслав Вікторович.docx.lnk	RYBAK Stanislav Viktorovich.docx.lnk
ШАШИЛО Олександр Віталійович.docx.lnk	SHASHILO Oleksandr Vitaliyevich.docx.lnk

The translation for these names shows the intent of this campaign in using a war-related theme. We can see some of the files use names of Russian or Ukrainian agents, as well as names alluding to troop movements in the region of conflict. 

These files contain metadata indicating only two machines were used in creating the malicious shortcut files. As we mentioned in a previous blog Gamaredon tends to use a short list of machines when creating the LNK files for their campaigns and the ones used in this campaign were previously seen by Talos in incidents related to this threat group. 

The LNK files contain PowerShell code used to download and execute the next stage payload, as well as a decoy file which is shown to the user after the infection occurs as a way to disguise the compromise.  

The PowerShell code uses the cmdlet Get-Command to indirectly execute the functions to download and execute the payload, which could be an attempt to bypass string-based detection by antivirus solutions.  

The servers used in this campaign are based out of Germany and Russia, and at the time of our assessment, all of them return HTTP error 403 when attempting to download the payload files.  

That indicates that either the files were taken offline, or access to the file is being restricted. Gamaredon is known to restrict access to their payload servers only to victims located in Ukraine. We have found evidence in public sample databases that these servers were still hosting the files for specific regions while returning access denied errors in our tests, like this sample available in the “Any.run” public sandbox: 

• https://app.any.run/tasks/f9dc0beb-b125-478d-9091-739d2e3325be 

Network infrastructure associated with Campaign 

The servers used in this campaign are mostly hosted in two Internet Service Providers (ISP): GTHost and HyperHosting: 

IP	ASN	ISP
146[.]185[.]233[.]96	63023	gthost
146[.]185[.]233[.]101	63023	gthost
146[.]185[.]239[.]45	63023	gthost
80[.]66[.]79[.]91	60602	hyperhosting
80[.]66[.]79[.]195	60602	hyperhosting
81[.]19[.]131[.]95	63023	ispipoceanllc
80[.]66[.]79[.]159	60602	hyperhosting
80[.]66[.]79[.]200	60602	hyperhosting
80[.]66[.]79[.]155	60602	hyperhosting
146[.]185[.]239[.]51	63023	gthost
146[.]185[.]233[.]90	63023	gthost
146[.]185[.]233[.]97	63023	gthost
146[.]185[.]233[.]98	63023	gthost
146[.]185[.]239[.]47	63023	gthost
146[.]185[.]239[.]56	63023	gthost
146[.]185[.]239[.]33	63023	gthost
146[.]185[.]239[.]60	63023	gthost

 

These servers are used to distribute the payload and the decoy document, but Talos found evidence of at least one server being used as the Command and Control (C2) server for the Remcos backdoor. 

We have also found evidence of an interesting artifact in the DNS resolution for some of these servers. Even though all the communication with these servers is done directly via the IP address, the reverse DNS record for some of these IPs show an invalid entry that is quite unique: 

Figure: Reverse DNS resolution for Gamaredon’s campaign. Modeled using Crime Mapper (by @UK_Daniel_Card) 

While this doesn’t necessarily mean the attackers manually changed these records, it did help uncover at least two additional IPs matching the characteristics of the other servers in this campaign: 

  

DLL sideloading used to load Remcos backdoor 

Gamaredon has previously been known to use custom scripts and tools in their attack chains, but Talos has observed the use of Remcos backdoor as an alternative tool in their campaigns. 

Once the ZIP payload is downloaded from the servers, it is extracted to the %TEMP% folder and executed. The binary which is executed is a clean application which in turn loads the malicious DLL via DLL sideloading method. This file is actually a malicious loader which decrypts and executes the final Remcos payload from encrypted files found within the ZIP. 

The PowerShell files we observed downloading the ZIP files contain hints of various applications being abused for DLL side loading, and they contain a mix of clean and malicious files: 

• DefenderUpdate/DPMHelper.exe 
• DefenderUpdate/DZIPR.exe 
• DefenderUpdate/IDRBackup.exe 
• DefenderUpdate/IUService.exe 
• DefenderUpdate/madHcCtrl.exe 
• DefenderUpdate/palemoon.exe 
• Drvx64/Compil32.exe 
• Drvx64/IsCabView.exe 
• Drvx64/TiVoDiag.exe 
• Drvx64/WiseTurbo.exe 
• SecurityCheck/Mp3tag.exe 
• SysDrive/AcroBroker.exe 
• SysDrive/DPMHelper.exe 
• SysDrive/IsCabView.exe 
• SysDrive/palemoon.exe 
• SysDrive/SbieSvc.exe 
• SysDrive/steamerrorreporter64.exe 
• SysDrive/TiVoDiag.exe 
• SysDrive/vmhost.exe 

We can see in the previously mentioned sample downloaded by “Any.run” that it contains the clean application TivoDiag.exe, as well as two DLLs. The file “mindclient.dll” is the malicious DLL which is loaded by “TivoDiag.exe” during execution. 

The payload binary is a typical Remcos backdoor which is injected into Explorer.exe. It communicates with the C2 server 146[.]185[.]233[.]96 on port 6856: 

Coverage 

Ways our customers can detect and block this threat are listed below. 

 

 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here. 

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here. 

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat. 

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device. 

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products. 

Cisco Secure Access is a modern cloud-delivered Security Service Edge (SSE) built on Zero Trust principles.  Secure Access provides seamless transparent and secure access to the internet, cloud services or private application no matter where your users work.  Please contact your Cisco account representative or authorized partner if you are interested in a free trial of Cisco Secure Access. 

Umbrella, Cisco’s secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network.  

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.  

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center. 

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.  

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. 

Snort SIDs for this threat:  

Snort 2: 64707, 64708 

Snort 3:  301171 

Indicators of Compromise 

IOCs for this threat can be found in our GitHub repository here.    

Cisco Talos Blog – ​Read More

AirTags are a popular tracking device used by anyone from forgetful key owners to those with malicious intent, such as jealous spouses and car thieves. Using AirTags for spying is simple: a tag is discreetly placed on the target to allow their movements to be conveniently monitored using Apple Find My. We’ve even added protection from AirTag-based tracking to our products for Android.

But a recent study by security researchers has surprisingly found that remote tracking doesn’t even depend on buying an AirTag or ever being physically near the target. If you manage to sneak special malware onto someone’s Windows, Android, or Linux device (like a computer or phone), it could use the device’s Bluetooth to send out a signal that nearby Apple devices would think is coming from an AirTag. Essentially, for Apple devices, the infected phone or computer effectively becomes an oversized AirTag – trackable via the Find My network, which boasts over a billion Apple phones and tablets.

Anatomy of the attack

The attack exploits two features of the Find My technology.

Firstly, this network uses end-to-end encryption – so participants don’t know whose signals they’re relaying. To exchange information, an AirTag and its owner’s phone rely on a pair of cryptographic keys. When a lost AirTag broadcasts its “callsigns” via Bluetooth, Find My network “detectors” (that is, any Apple device with Bluetooth and internet access, regardless of who owns it) simply transmit AirTag’s geolocation data to Apple servers. The data is encrypted with the lost AirTag’s public key.

Then, any device can ask for the encrypted location data from the server. And because it’s encrypted, Apple doesn’t know who the signal belongs to, or which device asked for it. The crucial point here is that one can only decrypt the data and find out both whose AirTag it is and its exact location by having the corresponding private key. Therefore, this data is only useful to the owner of the smartphone paired with this AirTag.

Another feature of Find My is that detectors don’t verify whether the location signal indeed originated with an Apple device. Any devices that support Bluetooth Low Energy (BLE) can broadcast it.

To exploit these features, the researchers came up with the following method:

1. They install malware on a computer, phone, or some other device running Android, Windows, or Linux, and check the Bluetooth adapter address.
2. The attackers’ server receives the information and uses powerful video cards to generate a pair of encryption keys specific to the device’s Bluetooth address and compatible with Apple’s Find My
3. The public key is sent back to the infected device, and the malware then starts transmitting a Bluetooth message that mimics AirTag signals and includes this key.
4. Any nearby Apple device connected to the internet receives the Bluetooth message and relays it to the Find My
5. The attackers’ server uses the private key to request the location of the infected device from Find My and decrypt the data.

How well does the tracking work?

The more Apple devices nearby and the slower the victim’s movement, the better the accuracy and speed of the location tracking. In typical urban environments like homes or offices, the location is typically pinpointed within six to seven minutes and with an accuracy of around three meters. Even in extreme situations, such as being on an airplane, tracking can still occur because internet access is now widely available on flights. The researchers obtained 17 geolocation points throughout a 90-minute flight, allowing them to reconstruct the aircraft’s flight path quite accurately.

Naturally, the success of the attack hinges on whether the victim can be infected with malware, and the details are slightly different depending on the platform. On Linux devices, the attack only requires infecting the victim’s gadget due to the specific Bluetooth implementation. By contrast, Android and Windows employ Bluetooth address randomization, meaning the attacker needs to infect two nearby Bluetooth devices: one as the tracking target (the one that mimics an AirTag), and another to obtain its adapter address.

The malicious application needs Bluetooth access, but this isn’t hard to get. Many common app categories – like media players, file sharing tools, and even payment apps – often have legitimate reasons to request it. It’s likely that a convincing and functional bait application will be created for this type of attack, or even that an existing application will be trojanized. The attack requires neither administrative permissions nor root access.

Importantly, we’re not just talking about phones and computers: the attack is effective across a range of devices – including smart TVs, virtual-reality glasses, and other household appliances – as Android and Linux are common operating systems in many of them.

Another key part of the attack involves calculating cryptographic keys on the server. Due to the complexity of this operation – which requires leasing hardware with modern video cards – the cost of generating a key for a single  victim is estimated at around $2.2. For this reason, we find mass-tracking scenarios that target, say, visitors inside a shopping center, to be unlikely. However, targeted attacks at this price point are accessible to virtually anyone, including scammers or nosy co-workers and spouses.

Apple’s response

The company patched the Find My network vulnerability in December 2024 in iOS 18.2, visionOS 2.2, iPadOS 17.7.3 (for older devices) and 18.2 (for newer ones), watchOS 11.2, tvOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2, and macOS Sequoia 15.2. Unfortunately, as is often the case with Apple, the details of the updates have not been disclosed. The researchers emphasize that this tracking method will remain technically feasible until all Apple users update to at least the above versions, though fewer devices will be able to report a tracked device’s location. And it’s not impossible that the Apple patch could be defeated by another engineering trick.

How to protect yourself from the attack

• Turn off Bluetooth when you’re not using it if your device has the option.
• When installing apps, stick to trusted sources only. Verify that the app has been around for a long time, and has many downloads and a high rating in its latest version.
• Only grant Bluetooth and location access to apps if you’re certain you need those features.
• Regularly update your device: both the OS and main apps.
• Make sure you have comprehensive malware protection enabled on all your devices. We recommend Kaspersky Premium.

Besides this rather unusual and as-yet-unseen-in-the-wild tracking method, there are numerous other ways your location and activities can be tracked. What methods are being used to spy on you? Read these for the details:

• How smartphones build a dossier on you
• Webcam stalking: fact or fiction?
• How to protect yourself from Bluetooth stalking and more
• How millions of Kia cars could be tracked
• Run for your data: privacy settings in jogging apps
• I know how you drove last summer

… and other posts.

Kaspersky official blog – ​Read More

It’s a rare company these days that doesn’t boast about using artificial intelligence (AI). And often no explanation is forthcoming as to why AI is needed or, more importantly, how it’s implemented — just the mere presence of AI, it seems, is enough to make a product more valuable, innovative and high-tech. Kaspersky advocates a different approach: we don’t just say “we use AI”, but explain exactly how we deploy machine learning (ML) and AI technologies in our solutions. It’d take too long to list all our AI technologies in a single post given that we have an entire expertise center — Kaspersky AI Technology Research — that deals with all aspects of AI. So my sole focus here will be on those technologies that make life easier for SIEM analysts working with the Kaspersky Unified Monitoring and Analysis Platform.

SIEM AI Asset Risk Scoring

In traditional systems, one of the most resource-intensive tasks of the SIEM analyst is prioritizing alerts — especially if the system has just been installed and works out of the box with default correlation rules not yet fine-tuned to the infrastructure of a specific company. Big data analytics and AI systems can help here. Armed with SIEM AI Asset Risk Scoring, monitoring and response teams can prioritize alerts and prevent potential damage. The module assesses asset risks by analyzing historical data and prioritizing incoming alerts, allowing to speed up triage and generate hypotheses that can be used for proactive searches.

Based on information about activated correlation rule chains, SIEM AI Asset Risk Scoring lets you build patterns of normal activity on endpoints. Then, by comparing daily activity with these patterns, the module identifies anomalies (for example, sudden traffic spikes or multiple service requests) that may signal a real incident and prompt the analyst to take a deeper look into these alerts. This way, the problem is detected early, before any damage is done.

AI-Powered OSINT IoCs

Analysts working with the Kaspersky Unified Monitoring and Analysis Platform also have the option to use additional contextual information from open sources through the Kaspersky Threat Intelligence Portal. After the latest update, the portal now provides access to threat intelligence collected using a generative AI model.

It works as follows: let’s say you’ve found a suspicious file during a threat hunt. You can take this file’s hash and look it up on the site, and if someone else has already encountered it during an incident investigation and published something about it, the technology will instantly show you indicators of compromise (IoC) and key facts about the threat. Without such an automation system, it can take the analyst many hours to find and review this information — especially if there are lots of materials and they’re written in different languages. Our system, built on an internal LLM model, can automate this process: it analyzes all reports and mentions of the threat whatever the language, extracts the essence, and presents a summary: the nature of the threat, the date it was detected first, cybercriminal groups associated with it, industries most often targeted using the file, and so on. This saves the analyst an enormous amount of time on searching and researching.

What’s more, the analyst has access to other Kaspersky Threat Intelligence data, including information generated using AI technologies and big data analytics. Our threat intelligence databases are continuously updated with the results of manual APT research, live data from the darknet, information from the Kaspersky Security Network, and regular analysis of new malware. All of these technologies help users minimize the potential damage from cyber-incidents and reduce the Mean Time to Respond (MTTR) and the Mean Time to Detect (MTTD).

 

We continue to improve the usability and performance of our SIEM system, with a focus on deploying AI to free information security employees from even more routine tasks. Follow updates of the Kaspersky Unified Monitoring and Analysis Platform on the official product page.

Kaspersky official blog – ​Read More

For a while after we wrote about hacking a bicycle, it seemed it couldn’t be beat as the most unlikely hack target ever. However, developers’ imagination seems to know no bounds — and hackers aren’t far behind in their ingenuity…

And so, here’s introducing the internet-connected mattress system — or “Pod” as it’s called — made by the company Eight Sleep, along with several ways it can be hacked as discovered by security researcher Dylan Ayrey.

Smart mattress Pod? What’s that?

Perhaps we should start by explaining what an Eight Sleep Pod is and why someone might want to buy this futuristic piece of tech. The Eight Sleep designers position their product as an “Intelligent Bed Cooling System”. The primary target audience is people with various sleep problems: insomnia, poor sleep quality, snoring, and similar issues that can significantly impact quality of life.

The Pod is made up of a sheet-like “high-tech layer” (“Cover”), and an external unit (“Hub”); optionally there’s also a motorized “Base”. It allows users to adjust the temperature of the bed — heating it up or cooling it down as instructed by the owner. It can do it automatically too — more on this later. There’s a network of tubes with water circulating through them built into it. The external unit connected to this system handles the heating and cooling. The Eight Sleep Pod is divided into two independent zones of a double-bed — each with its own settings. The temperature range is fairly broad: from 12 to 43°C.

But wait: there’s more to it! The Pod has several dozen “clinical-grade sensors” that track users’ sleep quality. It also has vibration motors to wake you up, and sensors for ambient temperature and humidity. The ultimate version — the Pod 4 Ultra — comes with a transformable, electronically-controlled bed base.

It goes without saying that the system connects to the internet. It does this via a Wi-Fi receiver in the Hub. Eight Sleep Pods are configured and controlled almost exclusively via an app. We say “almost”, because the latest (and most expensive) generation — Pod 4 — has pressure-sensitive areas on the sides that you can tap to control certain functions.

Autopilot and sleep by subscription

The main software component of an Eight Sleep Pod is the “Autopilot” system, which uses sensors built into the Cover to collect lots of statistics about the quality and quantity of users’ sleep, and generate detailed reports for them. In addition, Autopilot has a number of other interesting options. For example, the system can detect when the user starts snoring and change the geometry of the Base to fix the problem.

The Pod also has a physical alarm clock that wakes the user by changing the temperature of the bed and turning on vibration. However, the key Autopilot feature (and the one Eight Sleep touts the most) is, well, autopilot mode. What this does is continuously monitor the users’ sleep quality — automatically adjusting the temperature to ensure the deepest and most comfortable sleep possible.

In case you thought this was an Eight Sleep Pod ad, let’s look at this product’s numerous flaws…

To start with, these things are eye-wateringly expensive: retail prices start at $3000, and the top-of-the-line Pod 4 Ultra costs a whopping $4700.

But the outlay doesn’t end there: the user will almost certainly have to pay for a subscription that costs between $200 and $300 per year. In theory, you could choose not to pay it, but without the subscription most of the smart features remain inactive.

Also, like any modern tech company, Eight Sleep constantly collects data about its users. CEO Matteo Franceschetti talks quite openly about this on X:

Smart mattress hack No. 1: developer backdoor

Now let’s shift the focus to why this post was written: hacking this smart-mattress system. Dylan Ayrey, a security researcher, decided to look into Eight Sleep’s security — simply out of curiosity, he said, as Dylan is the happy owner of an Eight Sleep Pod, which helps him with his insomnia.

You might remember Dylan for his other notable investigations, such as the possibility of using phantom corporate accounts uncontrollable by workspace admins, or attacking Google OAuth via abandoned domains.

To begin analyzing the Pod’s security, Ayrey needed a copy of its firmware. Security-conscious vendors don’t just give their firmware away, so trying to find a copy often becomes a quest unto itself. Not so with Eight Sleep. The update server lets anyone who follows the link download the firmware for any of the company’s Pod models, no questions asked.

While examining the code, Dylan found a number of noteworthy things, including an API for remote connection via SSH. Given that an Eight Sleep Pod is essentially a computer running Linux (as many other modern devices are), a connection like this allows running arbitrary code remotely on the mattress pad Hub.

Judging by the email address associated with the SSH public key found in the firmware code, all (or at least many) Eight Sleep engineers could have remote access to any Pod.

One could use an SSH connection like this to spy on the Pod’s owner — to find out when they’re sleeping or when they spend the night away from home. It would even be possible to check if there’s one person in bed or two. Having this type of control could also let someone play pranks on the owner by changing the temperature of the Pod, turning the alarm clock on or off, adjusting the geometry of the bed base, and so on.

Nothing like that seems to have happened to Eight Sleep Pod owners yet, but something like it could; theoretical possibilities like this sometimes do materialize. This is what recently happened with Ecovacs robot vacuums: pranksters used vulnerabilities in these devices to harass their owners.

Smart mattress hack No. 2: an AWS key in the firmware

While still looking at the Eight Sleep Pod firmware, Dylan discovered a valid AWS (Amazon Web Services) key in its code — used to continuously upload telemetry to the cloud. Again this is only theoretical, but if the key fell into the wrong hands it could lead to serious violations of user privacy.

For better or for worse, the full truth about the presence of an Amazon key won’t come out. Dylan notified Eight Sleep, and by the time his research was published the key had already been revoked. However, the mere presence of the key within the firmware, where it was accessible to anyone, was clear evidence that user security and privacy were taken lightly.

Dylan further adds that the key could have, at the very least, been used to cause financial damage to the company by sending a large number of meaningless requests to the AWS cloud.

Smart mattress hack No. 3: jailbreaking with the help of an aquarium chiller

Clearly inspired by his earlier findings, Dylan decided to attempt jailbreaking the Pod — that is, detaching it from Eight Sleep’s cloud services. Dylan took a drastic approach: he disconnected the external unit (with all its smart electronics and internet connectivity).

Dylan replaced the Eight Sleep Hub with… a common aquarium chiller. This system, in contrast, doesn’t require an app or a subscription fee, collects no user data, comes without any backdoors, and runs perfectly well without an internet connection. What it does do is effectively adjust the temperature of your bed, and, just as importantly, it costs only $150.

For those who prefer a less radical approach to the issue of Eight Sleep products being tied to the vendor cloud, Free Sleep offers a solution. This is an open-source software suite that allows you to take control of your smart mattress.

Want to know what other unexpected devices have been successfully hacked? Here you go!…

• Hacking a train
• Hacking a capsule hotel
• Hole in the bowl: smart pet feeder springs a leak
• Vulnerabilities in a toy robot permitting snooping. Seriously
• Hacking our boss’s smart home
• Vibrators hacked
• IP camera security: the bad, the ugly, and the evil
• …and many others!

Kaspersky official blog – ​Read More

Editor’s note: The current article is authored by Mohamed Talaat, a cybersecurity researcher and malware analyst. You can find Mohamed on X and LinkedIn. 

In this article, we’re diving into GorillaBot, a newly discovered botnet built on Mirai’s code. It’s been spotted launching hundreds of thousands of attacks across the globe, and it’s got some interesting tricks up its sleeve.  

We’ll walk through how it talks to its command-and-control (C2) servers, how it receives instructions, and the methods it uses to carry out attacks.  

Overview 

“GorillaBot” is a newly discovered Mirai-based botnet that has been actively targeting systems in over 100 countries. According to the NSFOCUS Global Threat Hunting team, the botnet issued more than 300,000 attack commands between September 4 and September 27. 

This malware variant poses a serious cyber threat, affecting a wide range of industries — including telecommunications, financial institutions, and even the education sector — prompting an urgent need for response and mitigation. 

Key Takeaways 

• GorillaBot is a Mirai-based botnet that reuses core logic while adding custom encryption and evasion techniques. 

• It targets a wide range of industries and has launched over 300,000 attacks across more than 100 countries. 

• The botnet uses raw TCP sockets and a custom XTEA-like cipher for secure C2 communication. 

• GorillaBot includes anti-debugging and anti-analysis checks, exiting immediately in containerized or honeypot environments. 

• The malware authenticates to its C2 server using a SHA-256-based token generated from a hardcoded array and server-provided value. 

• Attack commands are encoded and hashed, then passed to a Mirai-style attack_parse function for execution. 

Technical Analysis  

In this section, we will examine the technical details of GorillaBot, focusing on its C2 communication protocol and how it receives information about its targets and the attack methods it’s instructed to use. 

Anti-Debugging  

Before proceeding with its main activity, GorillaBot performs checks to detect the presence of debugging tools. One of its first actions is to read the /proc/self/status file and inspect the TracerPid field. This field indicates whether the process is being traced – a value of 0 means it’s not, while a non-zero value suggests a debugger is attached. 

Learn more about evasion in malware

Another technique that “GorillaBot” uses to detect debuggers is to register a callback function that will pause and then exit upon receiving a SIGTRAP signal. 

Environment check  

GorillaBot is highly selective about the environment it runs in. It first ensures that it is operating on a legitimate target machine rather than inside a honeypot or container. To do this, it performs several checks for system-level artifacts that may not be present in those scenarios. 

The code shows that it initially checks for access to the “/proc” file system – a virtual file system that provides user-space processes with information about the kernel and running processes.  

In a typical Linux environment, the presence of the “/proc” file system is expected. If it’s missing, GorillaBot assumes it is being analyzed in a honeypot and exits immediately. 

GorillaBot uses another check to detect Kubernetes containerization by examining a specific file in the “/proc” directory, namely “/proc/1/cgroup.” It looks for the string “kubepods.” If this string is found, GorillaBot recognizes that it is running in a container and terminates its execution to avoid detection. 

Encryption & Decryption Algorithms  

One of the more intriguing features of this Mirai-based botnet is its use of encryption and decryption techniques to obscure key strings and hide internal configuration data.

Researchers observed that GorillaBot uses a simple Caesar cipher with a shift of 3 to decrypt specific strings. In addition, it employs a custom block cipher – which we’ll examine later in this article – to decrypt more complex internal configurations. These methods help the malware avoid static detection and make reverse engineering more difficult. 

Network Communication  

Initial C2 Communication  

Like many other Mirai-based botnets, GorillaBot uses raw TCP sockets for command-and-control (C2) communication, rather than higher-level protocols like HTTP or HTTPS.  

Learn to analyze malware’s network traffic

The process begins with the malware establishing a connection to its C2 server – the server’s IP address is decrypted at runtime using what appears to be a custom implementation of the XTEA (Extended Tiny Encryption Algorithm).  

The cipher closely resembles TEA or XTEA, employing a 128-bit (16-byte) hardcoded key for both encryption and decryption. 

During each iteration of the algorithm, a delta value is subtracted from the sum. 

The function begins by calculating the length of the provided data. It does this by iterating until it encounters the first NULL character.  

Once the length is known, it proceeds to pack the key. Since the key is given as a serialized sequence of bytes, it must be organized into an array of four 32-bit words before the function can perform either encryption or decryption. 

After the key is prepared and the data length calculated, the function checks a mode parameter to decide whether to encrypt or decrypt. It then enters a loop to iterate over the data for either process.

GorillaBot authentication mechanism with the C2 server   

After successfully connecting to the C2 server, the malware initiates the authentication process to identify itself to the server.  

This process begins with the malware sending a 1-byte TCP probe packet to the C2 server. In response, the server replies with a 4-byte TCP packet that includes a “magic” 4-byte value. This value is then used to generate the bot ID for the authentication process. 

View analysis in ANY.RUN’s Interactive Sandbox

The process begins with a returned 4-byte magic value, which is combined with a 32-byte encrypted array to generate the bot ID or authentication token.  

A key aspect of this process is the method used to combine the 32-byte array with the 4-byte magic value to create the token.  

The same cipher previously described is applied to decrypt the 32-byte hardcoded array. Once decrypted, the data is copied into a separate buffer and concatenated with the 4-byte magic value. 

The combined data is then hashed using SHA-256 before being sent back to the command and control (C2) server as the identification token. 

In the screenshot below, you can see the generated SHA-256 token, which is created by combining the 4-byte magic value received from the C2 server with the decrypted 32-byte hardcoded array. 

The C2 (Command and Control) communication process continues after the C2 server authenticates the botnet.  

In response, the server sends a packet that appears to be a flag, labeled “01,” to confirm the bot’s authenticity. On the C2 server side, most likely a list of hashes representing botnet IDs, such as SHA-256, is maintained. This list is used to verify the received ID, ensuring that the connection is from a legitimate bot instance rather than an unauthorized source attempting to interact with the C2 infrastructure. 

In the screenshot above, after successfully sending the SHA-256 hash (bot ID), the bot receives a 1-byte response. This response is checked against “01,” which indicates successful authentication. Following this, the bot replies with a 4-byte packet containing the bytes “00 00 00 01.” This is likely the bot acknowledging receipt of the flag packet. 

After, GorillaBot exhibits behavior similar to the original Mirai bot. The malware calculates the length of a provided 32-byte ID buffer and sends this length to the command and control (C2) server. Once the length is successfully sent, the malware transmits the actual ID buffer to the server. 

The code snippet above is taken from the leaked Mirai source and includes a check for the number of arguments. If a second argument is provided, it is copied to “id_buf,” which has a length of exactly 32 bytes.  

This behavior is consistent with that observed in the Mirai-based variant “GorillaBot.” During its initial communication with the command-and-control (C2) server, GorillaBot first sends the length of the buffer, followed by the buffer itself – mirroring the original Mirai implementation. 

The screenshot below summarizes the initial C2 communication, validating the connection to ensure it comes from the intended source. This is crucial so that only authenticated connections receive attack commands. 

Processing Attack Commands  

Once the bot has been authenticated, the next stage in the C2 communication process involves receiving a packet containing attack target information – essentially, instructions to initiate an attack. 

In the example screenshot below, we can see that the first step taken is to read the length of the packet. This confirms the malware’s ability to retrieve data over the socket from the command and control (C2) server.  

After successfully reading the length, the malware proceeds with execution. It reads the expected length of the attack packet, then uses that length to read the corresponding number of bytes from the C2 server, which constitutes the attack packet. 

Attack Command packet structure  

Below is the structure of the received attack packet along with the corresponding packet capture bytes. The time gap in receiving the length of the entire packet (highlighted in red in the capture) and the actual attack packet is minimal. As a result, it may seem as if they were concatenated into one packet and received simultaneously; however, they were actually received separately. 

The packet structure is quite simple. First, there is a 32-byte hash of the entire received packet, referred to as SHA-256 (highlighted in yellow). Following this, the encoded bytes represent the attack command (highlighted in blue), which will be decoded using the same Caesar shift cipher mentioned earlier before being parsed. 

Struct attack_pkt { 

uint16_t expected_pkt_length; 

char encoded_cmd_sha256_hash[SHA256_BLOCK_SIZE]; 

char encoded_cmd[ENCODED_CMD_LENGTH]; 

};

Once the integrity of the encoded attack command is verified, it is decoded and passed to “attack_parse.” This function is responsible for extracting target information, determining the specific attack method, and then handing off control to the appropriate attack function for execution.

The “attack_parse” function closely resembles the original Mirai code, as it processes the provided buffer containing the attack command in a similar manner. Notably, it supports attack commands both with and without options, just like the original Mirai. 

Conclusion 

GorillaBot may not reinvent the wheel, but it’s a strong reminder that old code can still pack a punch when reused in clever ways. By building on Mirai’s foundation and adding its own tweaks to communication, encryption, and evasion techniques, GorillaBot proves that legacy malware lives on and evolves. 

To better understand threats like GorillaBot, the use of malware analysis tools like ANY.RUN’s Interactive Sandbox is important. It lets you dive into live malware behavior: from unpacking encrypted payloads to monitoring C2 communication in real time. 

Curious to see it in action? Try ANY.RUN now to explore malware samples like GorillaBot hands-on and uncover the tactics they use during attacks to strengthen your defenses. 

About ANY.RUN

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search, and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.

Request free trial of ANY.RUN’s services → 

Indicators Of Compromise  

Hashes 

b482c95223df33f43b7cfd6a0d95a44cc25698bf752c4e716acbc1ac54195b55 (View sandbox analysis)  

IP Addresses and Domains  

http://193[.]143[.]1[.]70 (C2 server) 

193[.]143[.]1[.]59 (C2 server) 

The post GorillaBot: Technical Analysis and Code Similarities with Mirai appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More