Welcome back, my aspiring cyberwarriors!

In our eventful time, the ability to communicate off-grid has become more valuable than ever. Whether you’re preparing for emergencies, exploring remote locations, or simply want a decentralized communication network that doesn’t rely on cellular towers or internet infrastructure, Meshtastic offers a powerful solution.

In this article, we will explore what Meshtastic is and what it has to offer.

What is Meshtastic?

Meshtastic is an open-source mesh networking platform that leverages LoRa (Long Range) radio technology to create decentralized communication networks. Unlike traditional communications that depend on cellular networks or WiFi, Meshtastic enables devices to communicate directly with each other over long distances, creating a self-healing network where messages hop from node to node until they reach their destination.

The platform is built around the concept of decentralization, meaning no central server or infrastructure is required. Each node operates independently while contributing to the network’s overall reach. With LoRa technology you can communicate over several kilometers. Some configurations have achieved ranges of 10-20km in open terrain.

The low power consumption design makes it excellent for battery-operated devices and for portable and remote deployments. Meshtastic works across various hardware platforms, including ESP32, Raspberry Pi, and dedicated LoRa boards, and the cost-effectiveness of the required hardware components means basic nodes can be built for under $50.

Key Purposes and Use Cases

The primary purposes and use cases of these communication systems include supporting outdoor activities like hiking, camping, backpacking, and off-roading, allowing groups to stay in touch over long distances without relying on cellular towers. They are also essential in emergency and disaster response situations, providing communication during natural disasters, power outages, or other scenarios where cellular networks fail. These systems play a crucial role in search and rescue operations as well.

Additionally, they facilitate messaging in remote or restricted areas where connectivity is poor or internet access is limited. Community members and hobbyists use these systems to create local mesh networks for experimentation, conduct large-scale testing at events such as DEF CON, or establish backup communication systems for urban areas.

Ultimately, these universal communication systems enhance safety, build community connections, and ensure reliable communication in various challenging environments.

How Does Mashtastic Work?

Meshtastic operates on hardware such as ESP32-based boards (e.g., Heltec, LilyGO T-Beam) or pre-built nodes equipped with LoRa modules. These devices are programmed with Meshtastic firmware and function on unlicensed ISM radio bands, making them legal in most regions without the need for a ham radio license, although using higher power may require one in certain areas.

Communication Process

Sending a Message: To send a message, connect a Meshtastic device (referred to as a “node”) to your phone via Bluetooth (or sometimes Wi-Fi/serial) using companion apps available for Android, iOS, web, or desktop. Type your message in the app, and it will be sent to your node.

Broadcasting: The node then broadcasts the encrypted message packet over the LoRa radio. It is important to note that LoRa is designed for low-bandwidth communication, making it suitable for short text messages but not for voice or video.

Meshing and Relaying: Nearby nodes that receive the packet check if it is new (nodes track received packets to avoid duplicates). If it is new, they will rebroadcast it after decrementing a “hop limit” (the default is around 3 hops to prevent infinite looping). This creates a flooding mesh that relays the message from node to node until it reaches the intended recipient(s) or the hop limit is exhausted.

Receiving: The destination node receives the packet, decrypts it using AES256 encryption with shared channel keys, and forwards it to the connected app or phone for display. Additionally, nodes can share location data to map group positions.

Differences Between LTE, 5G, and Meshtastic

Many of us depend on LTE and 5G networks daily, so it’s important to compare them with Meshtastic.

Aspect	Meshtastic (LoRa Mesh)	LTE (4G)	5G
Technology	LoRa radio (915 MHz ISM band in US, license-free)	Cellular (various bands, e.g., 700–2600 MHz)	Cellular (sub-6 GHz + mmWave high bands)
Infrastructure	Decentralized mesh: User-deployed nodes relay messages	Centralized: Carrier-owned cell towers	Centralized: Dense cell towers + small cells
Coverage/Range	5–20+ km per hop (line-of-sight, terrain-dependent); extends via mesh	Nationwide/global where towers exist; indoor/outdoor	Similar to LTE but denser for high speeds; mmWave short-range
Data Speed	Very low: ~0.5–20 kbps (text-only, short messages)	5–100 Mbps typical (up to 300 Mbps peak)	100 Mbps–1+ Gbps typical (up to 10–20 Gbps theoretical)
Latency	Seconds to minutes (mesh hopping)	20–50 ms	1–10 ms (ultra-low for real-time apps)
Data Types	Text messages, GPS positions, basic telemetry	Voice, video, high-speed internet, apps	All LTE + AR/VR, IoT, autonomous vehicles
Power Consumption	Very low: Weeks/months on battery/solar	Moderate: Drains phone battery quickly	Higher (especially mmWave); improved efficiency in newer devices
Cost	Low one-time (devices + optional solar); no subscriptions	Monthly plan + device	Higher plans; premium for full speeds
Reliability in Outages	Excellent: Works off-grid, no single point of failure	Fails without power/towers (e.g., disasters)	Same as LTE; more vulnerable to congestion
Limitations	Text-only, slow, needs multiple nodes for range	Requires signal/subscription	Limited high-speed coverage; higher battery drain

These technologies serve different purposes: Meshtastic for resilient, infrastructure-independent communication in remote or emergency scenarios, versus LTE/5G for high-speed, everyday mobile internet and voice.

Summary

Meshtastic is a free and user-friendly tool that enables you to send messages without relying on the internet or mobile networks. It connects small, specialized devices to form a network, allowing communication over long distances. This makes it ideal for outdoor adventures, emergencies, or communication in remote areas.

Stay tuned as we continue to explore off-grid communication and simulate the mesh network using minimal hardware equipment in future articles.

Welcome back, aspiring digital investigators.

Many of you found our previous WhatsApp forensics article interesting, where we explained how to pull data from a rooted Android device. That method works well in difficult situations, but it is not always practical. Not everyone has the technical skills required to root a phone, and in many cases it is simply not possible. On the iOS side, things can be easier if you have an iTunes backup saved on a computer. Some users even leave their backups unprotected because they worry about forgetting the password, which means you may be able to access everything quickly.

But what happens when you do not have those ideal conditions? What if you need to extract messages and media fast, without doing anything advanced to the device? Today, we want to show you simple and reliable ways to gather data from WhatsApp, Signal, and Telegram with almost no technical experience. Even though these apps use strong encryption, it does not matter much once you have the unlocked device in front of you. Capturing network traffic will not help because everything is encrypted during transit. The smarter approach is to work directly with the phone, where the app already decrypts information for the user.

For this you will need Belkasoft X, one of the professional forensic tools we use at Hackers-Arise. The software is paid, but they offer a thirty-day free trial that you can obtain simply by signing up with your email. After a short time you will receive a link from Belkasoft’s team that allows you to install the tool.

Method 1: Using Belkasoft X Screen Capturer with Top Messengers

One of the easiest ways to collect content from mobile messengers is through automated screen capturing. Screenshots are far more valuable than many people think because they show exactly what the user saw, including messages, contact lists, calls, and media previews. Belkasoft X includes an Android screen-capturer feature that automates this entire process. It scrolls through apps such as Signal, Telegram, and WhatsApp, takes screenshots for you, and then uses text-recognition techniques to rebuild readable, searchable chat logs.

Screen capturing is especially helpful because basic Android acquisition methods such as ADB backup often miss large portions of app data. Many apps encrypt their local files, and even if you manage to back them up, decrypting them afterward can be extremely difficult. More advanced approaches, like downgrading APK versions to extract unencrypted data, do work but come with their own risks. Screen capturing, on the other hand, is safe, fast, and based entirely on normal ADB commands. Following well-known digital forensics handling guidelines, such as the SANS “Six Steps,” it is always better to start with the least intrusive method, and screenshots fit perfectly into that philosophy. The Android screen capturer in Belkasoft X is quick because it moves through screens automatically and faster than any human could. It is also flexible because you can limit how much the tool captures, which helps avoid long sessions. For example, you can choose to capture only the most recent messages or specific screens within an app.

Using the tool is straightforward. You connect the Android device to a computer running Belkasoft X, enable USB debugging under the Developer Options menu, and usually switch the phone to Airplane Mode so new notifications do not interfere. If the app depends on loading older messages from the cloud, you can preload everything before activating Airplane Mode. After that you launch Belkasoft X, create a case, select the mobile acquisition option, and choose the Screen Capturer method. 

Once you select either a supported messenger or a generic app, the tool guides you step by step until the capture starts.

During acquisition you should not touch the device until the process finishes. 

When Belkasoft X completes the capture, it offers to analyze the screenshots immediately and convert them into readable text.

For supported messengers like Signal, Telegram, and WhatsApp, the software organizes the results into familiar chat views, complete with names, contacts, timestamps, and messages. You can search, filter, and review everything, and if something looks suspicious, you can always return to the original screenshots for verification.

Method 2: Acquiring WhatsApp Cloud Backups

The second approach is useful when you do not have physical access to the device. If a WhatsApp user has configured their app to back up messages to their Google account, the backup files will appear in the user’s Google Drive storage. By default, end-to-end encrypted backups are turned off, and many people also choose to include videos in their backup, giving you more material to investigate. Google Drive itself does not allow direct downloading of WhatsApp’s backup files, so you will need Belkasoft X to retrieve them.

To acquire the backup, you start a case, add a new cloud data source, and select the WhatsApp option.

You then enter the user’s Google account credentials and follow the tool’s instructions.

The resulting data typically includes the encrypted msgstore database in its .crypt14 format, stored inside a folder named after the phone number registered with that WhatsApp account. While the messages themselves are encrypted, the media files are usually stored unencrypted and can be examined right away.

Method 3: WhatsApp QR Linking

The third method imitates the process of linking a new device to a WhatsApp account using a QR code. This is the same mechanism used when you open WhatsApp Web on your computer. The tool uses this linking process to obtain recent conversations and media from the account. Because of how WhatsApp handles synchronization, the data you receive will not be as complete as a full device extraction, but it is often enough to capture recent chats and shared files.

To use this method, the phone must be online and its camera must be functioning, because the user will need to scan a QR code presented on your screen. After creating a new case and selecting the WhatsApp QR acquisition option, the tool guides you through the linking process until the transfer is complete. The recovered messages are stored in an XML-based file along with a folder containing downloaded media.

Summary

You learned about simple and practical ways to extract messages and media from popular messaging apps such as WhatsApp, Signal, and Telegram without relying on advanced techniques like rooting an Android device. The key idea is that strong encryption protects data while it is being transmitted, but once you have access to the unlocked phone or its backups, much of that data becomes accessible through careful forensic methods. Belkasoft X is capable of doing this and a lot more. Screen capturing was shown as a safe and effective method that allows investigators to collect visible app content exactly as the user saw it. We also looked at acquiring WhatsApp cloud backups from Google Drive when physical access to the device is not available, and finally at using WhatsApp QR linking to retrieve recent conversations and media through account synchronization. Mobile forensics does not always require deep technical skills to produce valuable results. With the right tools and a thoughtful approach, investigators can quickly and reliably extract meaningful evidence from modern messaging applications.

Welcome back, aspiring cyberwarriors!

In our previous article on anti-drone warfare, we discussed the topic of jamming. Based on observations from the Russian-Ukrainian war, jamming is not only a legitimate electronic warfare technique but also a highly effective one. One notable incident involved Ursula von der Leyen’s plane, which was reportedly affected by suspected Russian GPS jamming. Furthermore, there have been numerous instances where weapons made by either Russia or the U.S. missed their targets due to GPS jamming. To further explore this issue, I would like to introduce a tool that visualizes GPS/GNSS disruptions affecting aircraft worldwide – GPSJam.

What Is GPSJam?

GPSJam.org is a website that offers information about GPS interference experienced by aircraft around the world. It utilizes data from ADS-B Exchange, a crowd-sourced flight tracking platform, to create daily maps that show areas likely to experience GPS interference. These maps are based on aircraft reports regarding the accuracy of their navigation systems.

It’s worth mentioning that GPSJam focuses not solely on GPS but also on GNSS in general. GNSS, or Global Navigation Satellite System, is a broad term that refers to any satellite navigation system capable of providing global coverage. This category includes various satellite-based positioning systems. Examples of GNSS include GPS (Global Positioning System) from the United States, GLONASS from Russia, Galileo from the European Union, and BeiDou from China.

How Does It Work?

Most aircraft are typically equipped with a device known as ADS-B Out, which stands for “Automatic Dependent Surveillance-Broadcast.” This system allows a plane to share its location, speed, and altitude with air traffic control and other aircraft in the vicinity. Additionally, it serves as a vital navigation tool that assists planes in approaching for landing.

Flight professionals and enthusiasts use specialized equipment to receive this information and relay it to flight-tracking websites like ADS-B Exchange. These platforms then visualize the flight data on interactive maps.

When aircraft utilize ADS-B Out, they not only transmit their position but also indicate the accuracy of that position. According to the tool provider, “when there is interference with their GPS, the uncertainty goes up.” Therefore, greater interference leads to decreased accuracy. Conversely, when there is little or no interference, the accuracy improves. Essentially, ADS-B Exchange collects data on the accuracy of an aircraft’s position. The tool provider aggregates this information over a 24-hour period and organizes it into hexagon sections, assigning different colors to represent varying levels of accuracy.

Get Started with GPSJam

To begin investigating where Russians or others conduct jamming, we should simply open https://gpsjam.org/ in our browser.

One of the most valuable functions is filtering by a date. But keep in mind that historical data only goes back to 14 February 2022.

Additionally, there are further settings that enable filtering by location and traffic threshold.

GPSJam clearly demonstrates GPS/GNSS interference; however, it’s important to note that some output data on this website may not be solely due to jamming. GNSS interference could also result from hardware issues in aircraft, as well as from weather conditions.

Summary

Jamming represents the forefront of cyber warfare. Tools like GPSJam can help identify areas experiencing jamming without the need for additional hardware or security clearance.

If you are a dedicated OSINT investigator, consider exploring this tool, as it may enhance your work. Furthermore, if you’re new to the field of Open Source Intelligence, check out our OSINT training.

Welcome back, aspiring cyberwarriors!

According to StatCounter, in 2025 Android powers over 3.3 billion users worldwide, dominating the global mobile OS market with a 71.85% share. But beyond phones, Android also powers a wide range of devices, including tablets, TVs, automotive systems, XR devices, and more.

Today, I’d like to show you how all of these devices can be hacked in seconds due to the negligence of their owners.

Android Debug Bridge (ADB)

Android Debug Bridge (ADB) is a versatile command-line tool that allows you to communicate with an Android device or emulator. The ADB command enables various device actions, such as installing and debugging apps. It also provides access to a Unix shell, letting you run a wide range of commands directly on the device.

ADB is a client-server program composed of three main components:

• Client: Runs on your development machine and sends commands. You invoke the client by issuing ADB commands from a terminal.
• Server: Also runs on your development machine as a background process. It manages communication between the client and the device daemon, handling multiple device connections.
• Daemon (adbd): Runs as a background process on each connected Android device or emulator. It executes commands sent from the server.

ADB can be accessed via both USB and Wi-Fi. When ADB is enabled over Wi-Fi (also known as ADB over TCP/IP), it listens on port 5555 and can accept connections from any device that can reach it — not just those on the same Wi-Fi network, but potentially from other networks via the internet if the device’s port is exposed, effectively opening a door for hackers.

Recon

To find systems with exposed ADB, we can use the well-known service Shodan — for example, by using the search query: “Android Debug Bridge port:5555”.

You can use nmap to check if there’s an ADB server on a target host like this:

kali> nmap <IP> -p 5555 -sV

If the service is running and allows unauthorized access, you might be able to see some valuable information, such as the system name, model, and available features.

Attack Via ADB Shell

First of all, we need to install the ADB shell, we can do so with the command:

kali> sudo apt install adb

You can check if the installation succeeded by viewing the help screen:

kali> adb –help

After that, we can try to connect:

kali> adb connect <ip>:<port>

We can check the connected devices, with command:
kali> adb devices

And move directly to the shell:

kali> adb shell

And we’re immediately granted root access to the system. We can do anything we want.

Post-Exploitation

Once ADB shell access is obtained, a single session can be useful but remains limited. Real offensive operations demand persistent access, remote control, and covert data channels. This is where Command and Control (C2) becomes essential. I won’t cover it here, as it’s a broad topic, but you can learn more in our Infrastructure Basics for Hackers course.

Conclusion

ADB is not inherently insecure, but when misconfigured, it becomes one of the fastest ways to compromise an Android-based system. The attacker does not need a CVE or an exploit chain. All they need is port 5555 and silence on the defender’s side.

Thousands of devices remain exposed today—mostly smart TVs, Android TV boxes, routers, IoT appliances, and older smartphones. These devices are often unpatched, unmanaged, and forgotten.

Find out if your phone has been hacked and how to investigate it by attending our Mobile Forensics class.

Welcome back, aspiring cyberwarriors!

John the Ripper (often called “John”) is a tool that earned a reputation as one of the most powerful and versatile in the field. Originally developed by Openwall, John has become an essential tool for penetration testers, security auditors, and anyone else who needs to assess password strength.

In this tutorial, you’ll learn how to use John the Ripper from the ground up. We’ll start with installation and basic concepts, then move through the three main password cracking modes with hands-on exercises for each. Let’s get rolling!

What Makes John the Ripper Powerful?

John the Ripper works by comparing password hashes against potential passwords. It generates candidate passwords, hashes them using the same algorithm as the target, and checks for matches. This approach is effective against various hash types, including MD5, SHA-1, SHA-256, bcrypt, and more.

In addition, the tool supports multiple platforms, including Linux, Windows, and macOS. It features multiple cracking modes, including Single, Wordlist, and Incremental approaches. John supports extensive hash formats, allowing you to crack dozens of different hash types. Besides that, you can create customizable rules to generate password variations, and the Jumbo version even includes GPU acceleration for significantly faster cracking.

Installation

John the Ripper is pre-installed on Kali Linux. Verify the installation:

kali> john

For Ubuntu/Debian, you can install John from the apt repository:

kali> sudo apt install john

Once you have installed John, try the help command to make sure your installation is working.

kali> john -h

Understanding Password Cracking Modes

John the Ripper offers three primary cracking modes, each suited for different scenarios.

1. Single Crack Mode

Single Crack Mode uses information from the username to generate password variations. This mode is surprisingly effective because users often create passwords based on their usernames.

You should use Single Crack Mode as a quick first attempt, especially when you have username information available. The syntax is straightforward:

kali> john –single –format=FORMAT hashfile.txt

The mode works by taking patterns from the username and generating variations. If the username is “hacker”, John will try variations like Hacker2025, HACKER2025, hacker2025!, 2025hacker, and many more permutations based on capitalization changes, number additions, and common character substitutions.

The command for cracking will be the following:

kali> john –single –format=raw-sha256 hash.txt

And immediately, we got an output with the password.

2. Wordlist Mode (Dictionary Attack)

Wordlist Mode compares hashes against a list of potential passwords from a dictionary file. This is the most commonly used mode for password cracking because it balances speed with effectiveness.

You should use Wordlist Mode when you have a good wordlist, which covers most real-world scenarios. The syntax requires specifying both the wordlist file and the hash format:

kali> john –wordlist=WORDLIST_FILE –format=FORMAT hashfile.txt

The RockYou wordlist is the most famous collection, containing over 14 million passwords leaked from the RockYou.com breach. But your cracking process should not be focused on this list. Consider creating your own wordlist, specific to your target. We’ve covered previously how to do so with tools like crunch and cupp.

But for demonstration purposes, I created a hash file with the password from a RockYou list.
The command for cracking will be the following:

kali> john –wordlist=/usr/share/wordlists/rockyou.txt –format=raw-sha256 hash.txt

3. Incremental Mode (Brute Force)

Incremental Mode tries all possible character combinations. This is the most thorough but slowest method, making it suitable only for specific scenarios.

You should use Incremental Mode as a last resort, particularly for short passwords when other methods have failed. The basic syntax is:

kali> john –incremental –format=FORMAT hashfile.txt

This mode exhaustively tries every possible combination of characters, starting with single characters and working up to longer passwords. This process can take days, weeks, or even years for moderately long passwords.

The command for cracking will be the following:

kali> john –incremental –format=raw-sha256 hash.txt

Cracking Windows NTLM Hashes

In Windows, password hashes are stored in the SAM database. The SAM uses the LM/NTLM hash format for passwords, and we can use John the Ripper to crack one of these hashes. Retrieving passwords from the SAM database is beyond the scope of this article, but let’s assume you have obtained a password hash for a Windows user. Here is the command to crack it:

kali> john –format=NT ntlm_hash.txt

This command will use a Single mode for cracking by default.

Cracking a Linux Password

In Linux, two important files are stored in the /etc directory: passwd and shadow. The passwd file contains information such as the username, user ID, and login shell, while the shadow file holds the password hash, expiration details, and other related data.

Besides the main “john” command, John the Ripper includes several additional utilities, one of which is called unshadow. This tool merges the passwd and shadow files into a single combined file that John can process when cracking passwords.

Here is how you use the unshadow command:

kali> unshadow passwd shadow > hash.txt

This command will combine the files and create a hash.txt file. Now, we can crack the hash using John. But here is a thing: Kali Linux’s John the Ripper doesn’t readily detect the hash type of Linux (crypt). If you omit the — format flag below, John won’t crack anything at all. So the command will be as follows:

kali> john –format=crypt hash.txt

Summary

John the Ripper is a robust tool for cracking passwords. It compares password hashes against potential passwords using various algorithms and is compatible with many types of hashes.

This tool works on a bunch of different platforms and is made to use energy wisely, which is why it’s a favorite among security experts and aspiring hackers. With security needs on the rise, John the Ripper is still a strong and valuable tool in the world of cybersecurity.

Welcome to the first part of our Windows Forensics series!

Today we start a guide designed especially for beginners getting started with registry analysis. In digital forensics, few artifacts are as rich, subtle, and revealing as the Windows Registry. It is a sprawling, hierarchical database where Windows quietly stores its configuration details, such as system settings, user preferences, hardware and software information. But more than that, the Registry is a historical logbook, it records traces of what has happened on a machine, which applications were installed, devices were plugged in, and network connections occurred. Even after files are deleted, or an attacker attempts to erase evidence, residual entries often remain in registry hives, transaction logs, or backups. They can provide a trail that can be reconstructed. By learning how to read, interpret, and extract data from these structures, you gain access to a powerful source of truth about past system activity.

To illustrate just how powerful registry forensics can be, here is a real case described by Italian investigators. An employee was accused of leaking sensitive company data using a corporate workstation. When forensic investigators seized the machine and analyzed its system registry, they didn’t just stop at installed software or user activity. They homed in on power and standby settings to determine how the computer behaved when it was left idle and whether it asked for a password on reactivation. Through registry analysis, they discovered that the screen reactivated without requiring a login, which supported their theory that someone else might have used the computer under the guise of the employee.

Today we will start by unpacking the basic building blocks, such as the hives, the logs, and how to acquire them safely without altering critical metadata. With that foundation, you will be ready to move forward into more advanced analysis in later parts of the series.

Hives

When you first step into the world of the Windows Registry, it helps to imagine it as a branching structure that starts broad and becomes more detailed the deeper you go. At the top of this structure are the hives, which act as major containers for everything stored in the Registry. Inside these hives are keys, which behave like folders, and values, which contain the actual pieces of data.

The most important hives for forensic work are:

1. HKEY_LOCAL_MACHINE (HKLM), which contains system-wide settings 
2. HKEY_USERS (HU), which holds profile information for every user on the system 
3. HKEY_CURRENT_USER (HKCU), which shows the active user’s settings and is really just a shortcut to that user’s section inside HKEY_USERS
4. You may also encounter HKEY_CLASSES_ROOT and HKEY_CURRENT_CONFIG, but these are built from other hives and are usually less important when you are first learning registry forensics.

How you access these hives depends on whether you are analyzing a live machine or working with a disk image. On a live system, regedit.exe loads and mounts everything for you automatically, making navigation straightforward. On an image, nothing is mounted, so you must know where the actual hive files are located. Most system hives are stored in C:\Windows\System32\Config as DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM, each corresponding to a specific Registry root.

User-specific hives are stored separately. On Windows 7 and newer, each user’s profile folder at C:\Users\<username>\ contains two important files: NTUSER.DAT and USRCLASS.DAT. When a user logs in, NTUSER.DAT becomes HKEY_CURRENT_USER and reflects personal settings, activity traces, and behavior, while USRCLASS.DAT loads under HKEY_CURRENT_USER\Software\CLASSES. Together, these hives give investigators an extremely detailed view of both system-level and user-level activity.

Another hive worth learning early on is the Amcache hive, located at C:\Windows\AppCompat\Programs\Amcache.hve. Windows uses it to record details about programs that were recently executed. Even if an attacker deletes an executable or removes its traces from other locations, Amcache often preserves enough information to connect it back to the system.

Now let’s take a closer look at the main hives and what makes each of them valuable in an investigation.

SAM Hive

The SAM hive stores local user accounts, groups, and password hashes. Investigators use it to identify accounts, check for unauthorized creations, and extract password hashes for deeper analysis. It often reveals privilege escalation attempts.

SYSTEM Hive

The SYSTEM hive contains configuration data for hardware, services, drivers, and network interfaces. It plays a major role in building system timelines because it stores time zone settings, device history, and information about previous network connections.

SOFTWARE Hive

The SOFTWARE hive contains records about installed software, both from Windows and third-party vendors. It can reveal when a program was installed, how it was configured, or whether malware established persistence on the system.

SECURITY Hive

The SECURITY hive contains local security policies and audit settings. Investigators look here to see whether someone changed security rules, weakened protections, or modified privilege rights.

NTUSER.DAT Hive

NTUSER.DAT gives the most detailed view of a specific user’s actions. It logs things like recently opened files, commands, application usage, and settings that reflect day-to-day behavior. It is one of the most valuable hives in user-focused investigations.

USRCLASS.DAT

USRCLASS.DAT holds additional user-level data related to the Windows interface, including recent items, folder views, and file associations. These small details often help reconstruct how a user navigated the system.

Amcache Hive

The Amcache hive records program execution history, even for deleted or moved executables. Because of this, it is extremely useful during malware investigations and incident response.

Transaction Logs and Backups

Beyond the hives, transaction logs and backups offer additional layers of evidence. Transaction logs act as journals that record Registry changes before they are written into the main hive files. If a system crashes or an attacker interrupts a process, the logs may still contain the most recent modifications. Each hive has a .LOG file stored in the same directory, and some hives have .LOG1 and .LOG2 as well. These files often reveal changes that are invisible in the main hives.

Registry backups work in the opposite direction by preserving older versions of the hives. Windows automatically copies the hives into C:\Windows\System32\Config\RegBack every ten days. When you suspect that keys were deleted or modified to cover tracks, comparing the current hives with their backups can reveal exactly what changed.

Before you can analyze any of this information, you must acquire the Registry hives safely. Registry acquisition is about collecting the hive files without altering them and preserving their metadata. Whether you are working on a live system or a disk image, your goal is always the same. You need to extract the files in a forensically sound manner so you can examine them later. Three common tools used for this are Autopsy, KAPE, and FTK Imager.

Autopsy

Autopsy is an open-source forensic tool that lets investigators examine disk images easily. When handling Registry hives, Autopsy makes it simple to navigate to the correct directories and export the hive files without touching the original evidence. It is widely used in training and lab environments because of its clear interface and reliability.

Kape

KAPE (Kroll Artifact Parser and Extractor) is designed for quick collection of important forensic artifacts. Instead of manually browsing through directories, KAPE uses modules that automatically identify and extract the correct Registry hives. This makes it ideal for triage situations or tight time windows.

FTK Imager

FTK Imager is a well-known imaging and preview tool used to extract files from both live systems and images. You can browse the file system, locate hives such as SAM, SYSTEM, SOFTWARE, NTUSER.DAT, or Amcache, and export them with all metadata preserved. FTK Imager is popular because it allows clean, safe copying without altering the evidence.

Summary

The Windows Registry acts like a digital diary of a computer’s life, recording system settings and the actions of users over time. It stores details about installed applications, devices that connected to the machine, and which programs were run. Even when attackers or users try to cover their tracks, the Registry often retains enough evidence. Logs and backup copies can reveal changes that would otherwise be hidden. And because all of this data is stored in structured “hives,” each part of the Registry tells a different story, from user behavior to security settings to executed programs. To preserve this evidence, investigators must collect Registry data carefully, using tools that maintain the integrity and metadata of the files. When done right, examining the Registry gives a clear, reliable view into past activity.

Welcome back, my aspiring digital investigators!

Many of you enjoyed our earlier lessons on Volatility, so today we will continue that journey with another practical case. It is always great to see your curiosity growing stronger. This time we will walk through the memory analysis of a Windows machine that was infected with a stealer, which posed as a VPN app. The system communicated quietly with a Command and Control server operated by a hacker, and it managed to bypass the network intrusion detection system by sending its traffic through a SOCKS proxy. This trick allowed it to speak to a malicious server without raising alarms. You are about to learn exactly how we uncovered it.

What Is a NIDS ?

Before we jump into memory analysis, let’s briefly talk about NIDS, which stands for Network Intrusion Detection System. A NIDS watches the network traffic that flows through your environment and looks for patterns that match known attacks or suspicious behavior. If a user suddenly connects to a dangerous IP address or sends strange data, the NIDS can raise an alert. However, attackers often try to hide their communication. One common method is to use a SOCKS proxy, which allows the malware to make its malicious connection indirectly. Because the traffic appears to come from a trusted or unknown third party instead of the real attacker’s server, the NIDS may fail to flag it.

Memory Analysis

Now that we understand the background, we can begin our memory investigation.

Evidence

In this case we received a memory dump that was captured with FTK Imager. This is the only piece of evidence available to us, so everything we discover must come from this single snapshot of system memory.

Volatility Setup

If you followed the first part of our Volatility guide, you already know how to install Volatility in its own Python 3 environment. Whenever you need it, simply activate it:

bash$ > source ~/venvs/vol3/bin/activate

Malfind

Volatility includes a helpful plugin called malfind. In Volatility 3, malfind examines memory regions inside processes and highlights areas that look suspicious. Attackers often inject malicious code into legitimate processes, and malfind is designed to catch these injected sections. Volatility has already announced that this module will be replaced in 2026 by a new version called windows.malware.malfind, but for now it still works the same way.

To begin looking for suspicious activity, we run:

bash$ > vol -f MemoryDump.mem windows.malware.malfind

The output shows references to a VPN, and several processes stand out as malicious. One in particular catches our attention: oneetx.exe. To understand its role, we need to explore the related processes. We can do that with pslist:

bash$ > vol -f MemoryDump.mem windows.pslist | grep -E "5896|7540|5704"

We see that oneetx.exe launched rundll32.exe. This is a classic behavior in malware. Rundll32.exe is a legitimate Windows utility that loads and executes DLL files. Hackers love using it because it allows their malicious code to blend in with normal system behavior. If the malware hides inside a DLL, rundll32.exe can be used to run it without attracting much attention.

We have confirmed the malicious process, so now we will extract it from memory.

Analyzing the Malware

To analyze the malware more deeply, we need the actual executable. We use dumpfile and provide the process ID:

bash$ > vol -f MemoryDump.mem windows.dumpfile --pid 5896

Volatility will extract all files tied to the process. To quickly locate the executable, we search for files ending in .exe:

bash$ > ls *exe*

Once we find the file, we calculate its hash so that we can look it up on VirusTotal:

bash$ > md5sum file.0x….oneetx.exe.img

The malware is small, only 865 KB. This tells us it is a lightweight implant with limited features. A full-featured, multi-purpose implant such as a Sliver payload is usually much larger, sometimes around sixteen megabytes. Our sample steals information and sends it back to the hacker.

Viewing its behavior reveals several MITRE ATT&CK techniques, and from that we understand it is a stealer focused on capturing user input and collecting stolen browser cookies.

Next, we want to know which user launched this malware. We can use filescan for that:

bash$ > vol -f MemoryDump.mem windows.filescan | grep "oneetx.exe"

It turns out the user was Tammam, who accidentally downloaded and executed the malware.

Memory Protection

Before we continue, it is worth discussing memory protection. Operating systems apply different permissions to memory regions, such as read, write, or execute. Malware often marks its injected code regions as PAGE_EXECUTE_READWRITE, meaning the memory is readable, writable, and executable at the same time. This combination is suspicious because normal applications usually do not need this level of freedom. In our malfind results, we saw that the malicious code was stored in memory regions with these unsafe permissions.

Process Tree

Next, we review the complete process tree to understand what else was happening when the malware ran:

bash$ > vol -f MemoryDump.mem windows.pstree

Two processes draw our attention: Outline.exe and tun2socks.exe. From their PIDs and PPIDs, we see that Outline.exe is the parent process.

Tun2socks.exe is commonly used to forward traffic from a VPN or proxy through a SOCKS interface. In normal security tools it is used to route traffic securely. However, attackers sometimes take advantage of it because it allows them to hide communication inside what looks like normal proxy traffic.

To understand how Outline.exe started, we trace its PID and PPID back to the original parent. In this case, explorer.exe launched multiple applications, including this one.

Normally we would extract these executables and check their hashes as well, but since we have already demonstrated this process earlier, we can skip repeating it here.

Network Connections

Malware usually communicates with a Command and Control server so the hacker can control the infected system, steal data, or run remote commands. Some malware families, such as ransomware, do not rely heavily on network communication, but stealers typically do.

We check the network connections from our suspicious processes:

bash$ > vol -f MemoryDump.mem windows.netscan | grep -iE "outline|tun2socks|oneetx"

Tun2socks connected to 38.121.43.65, while oneetx.exe communicated with 77.91.124.20. After checking their reputations, we see that one of the IPs is malicious and the other is clean. This strongly suggests that the attacker used a proxy chain to hide their real C2 address behind an innocent-looking server.

The malicious IP is listed on tracker.viriback.com, which identifies the malware family as Amadey. Amadey is known for stealing data and providing remote access to infected machines. It usually spreads through phishing and fake downloads, and it often hides behind ordinary-looking websites to avoid suspicion.

The tracker even captured an HTTP login page for the C2 panel. The interface is entirely in Russian, so it is reasonable to assume a Russian-speaking origin.

Strings Analysis

Now that we understand the basic nature of the infection, we search for strings in the memory dump that mention the word “stealer”:

bash$ > strings MemoryDump.mem | grep -ai stealer

We find references to RedLine Stealer, a well-known and widely sold malware. RedLine is commonly bought on underground markets. It comes either as a one-time purchase or as a monthly subscription. This malware collects browser passwords, auto-fill data, credit card information, and sometimes even cryptocurrency wallets. It also takes an inventory of the system, gathering information about hardware, software, security tools, and user details. More advanced versions can upload or download files, run commands, and report regularly to the attacker.

We can also use strings to search for URLs where the malware may have uploaded stolen data.

Several directories appear, and these could be the locations where the stolen credentials were being stored.

Timeline

Tammam wanted to download a VPN tool and came across what looked like an installer. When he launched it, the application behaved strangely, but by then the infection had already begun. The malware injected malicious code, and used rundll32.exe to run parts of its payload. Tun2socks.exe and Outline.exe helped the malware hide its communication by routing traffic through a SOCKS proxy, which allowed it to connect safely to the attacker’s C2 server at 77.91.124.20. From there, the stealer collected browser data, captured user inputs, and prepared to upload stolen credentials to remote directories. The entire activity was visible inside the memory dump we analyzed.

Summary

Stealers are small but very dangerous pieces of malware designed to quietly collect passwords, cookies, autofill data, and other personal information. Instead of causing loud damage, they focus on moving fast and staying hidden. Many rely on trusted Windows processes or proxy tools to disguise their activity, and they often store most of their traces only in memory, which is why memory forensics is so important when investigating them. Most popular stealers, like RedLine or Amadey, are sold on underground markets as ready-made kits, complete with simple dashboards and subscription models. Their goal is always the same.

Welcome back, my aspiring cyberwarriors!

New technological developments in recent years has made it possible to build a private cellular network at very low cost. This can be useful to many organizations who place their privacy at a premium such as firms engaged in research and development of intellectual property (IP) or law firms, to name but a few.. You can read here how the Mexican drug cartels built their own private cellular network to evade both law enforcement and competitors snooping.

This article was written by one of our most advanced students, Astra. Astra is an ardent supporter of Ukraine’s freedom and an advanced student of low cost cellular networks.

If you want to learn more about setting up a private 4G LTE network, enroll in our SDR for Hackers: Building a Private 4G Network!

In this article, he will demonstrate how to build your own 4G LTE network!

LTE Networks

The concept of private LTE itself is not new. There are ready-made solutions that allow you to lease frequencies and deploy such network at your enterprise. But, of course, all this equipment is not suitable for a one-time testing experience, so we will launch a network based on SDR.

If in the world of open-source stacks GSM is ruled by Osmocom, then here in 4G LTE the undoubted leader is  srsRAN. This is a completely open-source software that with minimum configuration, allows us to launch this kind of network.

srsRAN can be built from source, but I recommend using DragonOS, which has already been mentioned many times by OTW, where this software is already included in the distribution.

There is also another similar project which is LibreCellular that uses slightly different hardware, but the key concept is the same of srsRAN.

How LTE works

Let’s understand how this network (RAN, Radio Access Network) works.

It is a network that utilizes frequencies more efficiently and provides much faster performance compared to GSM and 3G.

It consists of three key components:

EPC (Evolved Packet Core)

This the operator’s core network. Its main component is the MME (Mobility Management Unit), through which all signaling traffic from UEs (User Equipment) passes. This node is responsible for service transfer, calling, authentication and many other operations. Its other parts are the billing service and gateways (service and packet), which provide data exchange between parts of the network and other networks. Connected to the core network is the HSS (Home Subscriber Server), a secure database where encryption keys and subscriber information are stored. In a GSM network, the role of this node is played by the home register (HLR).

eNBs (eNodeB).

These are the base stations. LTE operates in a wide range of frequencies, from 450 to 2600 MHz. Their use varies from country to country, as some of these frequencies are already reserved for something else. Like GSM, there are channel numbers here too – the E-UTRA Absolute Radio Frequency Channel Number (EARFCN).

The whole spectrum of frequencies is divided into broad sections (LTE bands), the choice of which differs from country to country.

UE (User Equipment).

These are the devices that connect to the network such as phones and modems.

What does it take to get your own LTE network up and running?

In order to reproduce everything that I will be describing below, you will require some specific hardware and specific configuration.

For this test you will need:

1)      A Linux and a Windows machine.

2)      A full duplex SDR with proper antennas. B210, BladeRF, and LimeSDR are suitable.

3)      A sim card reader

4)      Programmable LTE USIM cards

5)      An android smartphone

Let’s start 

Boot into DragonOS and plug in the SDR.

Navigate to the /etc/srsran folder.

dragonos> cd /etc/srsan

You’ll find the configuration files there.

dragonos > ls -l

In the enb.conf file we will modify two parameters: MCC and MNC

These parameters are identical to those used in GSM networks – they are country code and network code. Normally, we should use some arbitrary values, but the problem is that most phones refuse to work when they see strange values for network. That’s why we need to specify the MCC of the country you live in or use the 999, which is the value for private enterprise networks. With regards the network code (MNC) make sure to set one that doesn’t belong to any operator working in your country.

[enb]

enb_id = 0x19B

mcc = 999

mnc = 01

mme_addr = 127.0.1.100

gtp_bind_addr = 127.0.1.1

s1c_bind_addr = 127.0.1.1

s1c_bind_port = 0

n_prb = 50

#tm = 4

#nof_ports = 2

 

Then, modify the epc.conf file in the same way:

 

[mme]

mme_code = 0x1a

mme_group = 0x0001

tac = 0x0007

mcc = 999

mnc = 01

mme_bind_addr = 127.0.1.100

apn = srsapn

dns_addr = 8.8.8.8

encryption_algo = EEA0

integrity_algo = EIA1

paging_timer = 2

request_imeisv = false

lac = 0x0006

full_net_name = astra00011

short_net_name = astra00011

 

Now in two separate terminals, run first sudo srsepc and then sudo srsenb.

Next, take your phone and go to search for networks manually. If we are lucky we’ll see a network, depending on which values you set, starting with 99913. If we try to connect to this network, we will surely fail – the phone will connect a bit and then give a sad “No service”.

It’s all about authentication. That is what we are going to deal with now.

Fire up a windows machine and plug in the sim card reader. Insert a blank sim into the reader.

I am using a non open source software to read/write on sims. There are other options such as pysim.

Once the sim card is read, we can proceed writing the required parameters.

The key parameters required by srsRAN are the IMSI, KI and OPC.

The first field to fill in is to write value for ICCID. The ICCID number should be a unique 19 digit identifier for the SIM card itself. It should composed by the following:

 

Field	Description	Example
Major Industry Identifier	Always set 89 for telecommunication purposes	89
Country Code	2 or 3 digit country code as defined by by ITU-T recommendation E.164.	01
Issuer Identifier	1 to 4 digits. Usually the MNC code.	23
Individual Account Identifier	Variable account identification number.	000000000001

Next we need to generate an IMSI (international mobile subscriber identity) number. This 15 digit number is used to uniquely identifier each user of a cellular network.

Field	Description	Example
MCC	Mobile Country Code	999
MNC	Mobile Network Code	23
Individual Account Identifier	Account identifier (usually the same as the one in the ICCID but chopped here to stay in the 15 digit limit)	0000000001

Next step is to generate the KI value (subscriber key), which is known only by the subscriber and network and used to authenticate the device on the network. We also need to generate a OPC (operator code derived) value.

I used the following script to generate 128-bit values for both Ki and OPC:

Then fill in the last parameters which consists of:

PLMNwAct: A user-managed list of preferred Public Land Mobile Networks (PLMNs) ranked by priority, along with the corresponding access technologies (2G/3G/4G/5G, etc.).

OPLMNwAct: An operator-controlled version of the user-preferred PLMN list mentioned above.

HPLMNwAct: The Home PLMN, including the specified access technology, identifies the network associated with the subscriber’s identity, represented as a combination of Mobile Country Code (MCC) and Mobile Network Code (MNC) with the access technology included.

 EHPLMN: A list of Equivalent Home PLMNs. Networks in this list are treated as equivalent to the home network, meaning the device won’t consider itself roaming when connected to them. This field can be useful, for example, when operators merge, allowing each to include the other’s

PLMN in this list (though the original source for this suggestion could not be verified).

FPLMN: A list of forbidden PLMNs that the device should not automatically attempt to register with. This can be used to avoid all specified local public mobile networks.

If everything was correctly set up, once you insert your programmed sim card in your smartphone, you should be able to see something like this in the network parameters:

Notice that we still don’t have any mobile connection (top right corner icon)

Lastly, we need to choose the radio frequency for transmission and reception, which is conveniently represented by an EARFCN (Evolved-UTRA Absolute Radio Frequency Number). srsRAN supports exclusively FDD (Frequency Division Duplexing), where the mobile device’s downlink and uplink operate on separate frequencies. By specifying the downlink EARFCN, srsRAN can determine the corresponding downlink frequency. This can be done in the /etc/srsran configuration folder in the rr.conf file.

The final step to complete the whole configuration is to edit the user_data.csv file. This file includes the SIM card identity that we previously configured. This file is utilized by the Home Subscriber Service (HSS). The information programmed into the SIM cards is now necessary for operation.

Keep in mind that srsRAN does not support calls and SMS, only internet connectivity. Calls are possible with VoLTE, but this involves additional components such as the IP Multimedia Subsystem (IMS) that srsRAN does not natively include.

Now’s the time to raise our 4G LTE network:

In two separate terminals type:

>sudo srsepc

followed by

sudo srsenb

Success! We have our own private 4G LTE network!

Summary

It is now possible to create your own 4G LTE network with low cost components and a bit of expertise! These networks can be invaluable to those who place a high priority upon privacy and confidentiality. This is key in a era where competitors or nation state actors may be inside your mobile carrier’s system.

To learn more about SDR (Signals Intelligence), join our SDR (Signals Intelligence) program or our Subscriber Pro training package. Look for our SDR (Signals Intelligence) for Hackers for Mobile Systems, June 9-11.

Welcome back, aspiring forensic investigators. 

Linux is everywhere today. It runs web servers, powers many smartphones, and can even be found inside the infotainment systems of cars. A few reasons for its wide use are that Linux is open source, available in many different distributions, and can be tailored to run on both powerful servers and tiny embedded devices. It is lightweight, modular, and allows administrators to install only the pieces they need. Those qualities make Linux a core part of many organizations and of our daily digital lives. Attackers favour Linux as well. Besides being a common platform for their tools, many Linux hosts suffer from weak monitoring. Compromised machines are frequently used for reverse proxies, persistence, reconnaissance and other tasks, which increases the need for forensic attention. Linux itself is not inherently complex, but it can hide activity in many small places. In later articles we will dive deeper into what you can find on a Linux host during an investigation. Our goal across the series is to build a compact, reliable cheat sheet you can return to while handling an incident. The same approach applies to Windows investigations as well.

Today we will cover the basics of Linux forensics. For many incidents this level of detail will be enough to begin an investigation and perform initial response actions. Let’s start.

OS & Accounts

OS Release Information

The first thing to check is the distribution and release information. Different Linux distributions use different defaults, package managers and filesystem layouts. Knowing which one you are examining helps you predict where evidence or configuration will live. 

bash> cat /etc/os-release

Common distributions and their typical uses include Debian and Ubuntu, which are widely used on servers and desktops. They are stable and well documented. RHEL and CentOS are mainly in enterprise environments with long-term support. Fedora offers cutting-edge features, Arch is rolling releases for experienced users, Alpine is very small and popular in containers. Security builds such as Kali or Parrot have pentesting toolsets. Kali contains many offensive tools that hackers use and is also useful for incident response in some cases.

Hostname

Record the system’s hostname early and keep a running list of hostnames you encounter. Hostnames help you map an asset to network records, correlate logs across systems, identify which machine was involved in an event, and reduce ambiguity when combining evidence from several sources.

bash> cat /etc/hostname

bash> hostname

Timezone

Timezone information gives a useful hint about the likely operating hours of the device and can help align timestamps with other systems. You can read the configured timezone with:

bash> cat /etc/timezone

User List

User accounts are central to persistence and lateral movement. Local accounts are recorded in /etc/passwd (account metadata and login shell) and /etc/shadow (hashed passwords and aging information). A malicious actor who wants persistent access may add an account or modify these files. To inspect the user list in a readable form, use:

bash> cat /etc/passwd | column -t -s :

You can also list users who are allowed interactive shells by filtering the shell field:

bash> cat /etc/passwd | grep -i 'ash'

Groups

Groups control access to shared resources. Group membership can reveal privilege escalation or lateral access. Group definitions are stored in /etc/group. View them with:

bash> cat /etc/group

Sudoers List

Users who can use sudo can escalate privileges. The main configuration file is /etc/sudoers, but configuration snippets may also exist under /etc/sudoers.d. Review both locations: 

bash> ls -l /etc/sudoers.d/

bash> sudo cat /etc/sudoers

Login Information

The /var/log directory holds login-related records. Two important binary files are wtmp and btmp. The first one records successful logins and logouts over time, while btmp records failed login attempts. These are binary files and must be inspected with tools such as last (for wtmp) and lastb (for btmp), for example:

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

bash> sudo lastb -f /var/log/btmp

System Configuration

Network Configuration

Network interface configuration can be stored in different places depending on the distribution and the network manager in use. On Debian-based systems you may see /etc/network/interfaces. For a quick look at configured interfaces, examine:

bash> cat /etc/network/interfaces

bash> ip a show

Active Network Connections

On a live system, active connections reveal current communications and can suggest where an attacker is connecting to or from. Traditional tools include netstat:

bash> netstat -natp

A modern alternative is ss -tulnp, which provides similar details and is usually available on newer systems.

Running Processes

Enumerating processes shows what is currently executing on the host and helps spot unexpected or malicious processes. Use ps for a snapshot or interactive tools for live inspection:

bash> ps aux

If available, top or htop give interactive views of CPU/memory and process trees.

DNS Information

DNS configuration is important because attackers sometimes alter name resolution to intercept or redirect traffic. Simple local overrides live in /etc/hosts. DNS server configuration is usually in /etc/resolv.conf. Often attackers might perform DNS poisoning or tampering to redirect victims to malicious services. Check the relevant files:

bash> cat /etc/hosts

bash> cat /etc/resolv.conf

Persistence Methods

There are many common persistence techniques on Linux. Examine scheduled tasks, services, user startup files and systemd units carefully.

Cron Jobs

Cron is often used for legitimate scheduled tasks, but attackers commonly use it for persistence because it’s simple and reliable. System-wide cron entries live in /etc/crontab, and individual service-style cron jobs can be placed under /etc/cron.d/. User crontabs are stored under /var/spool/cron/crontabs on many distributions. Listing system cron entries might look like:

bash> cat /etc/crontab

bash> ls /etc/cron.d/

bash> ls /var/spool/cron/crontabs

Many malicious actors prefer cron because it does not require deep system knowledge. A simple entry that runs a script periodically is often enough.

Services

Services or daemons start automatically and run in the background. Modern distributions use systemd units which are typically found under /etc/systemd/system or /lib/systemd/system, while older SysV-style scripts live in /etc/init.d/. A quick check of service scripts and unit files can reveal backdoors or unexpected startup items:

bash> ls /etc/init.d/

bash> systemctl list-unit-files --type=service

bash> ls /etc/systemd/system

.Bashrc and Shell Startup Files

Per-user shell startup files such as ~/.bashrc, ~/.profile, or ~/.bash_profile can be modified to execute commands when an interactive shell starts. Attackers sometimes add small one-liners that re-establish connections or drop a backdoor when a user logs in. The downside for attackers is that these files only execute for interactive shells. Services and non-interactive processes will not source them, so they are not a universal persistence method. Still, review each user’s shell startup files:

bash> cat ~/.bashrc

bash> cat ~/.profile

Evidence of Execution

Linux can offer attackers a lot of stealth, as logging can be disabled, rotated, or manipulated. When the system’s logging is intact, many useful artifacts remain. When it is not, you must rely on other sources such as filesystem timestamps, process state, and memory captures.

Bash History

Most shells record commands to a history file such as ~/.bash_history. This file can show what commands were used interactively by a user, but it is not a guaranteed record, as users or attackers can clear it, change HISTFILE, or disable history entirely. Collect each user’s history (including root) where available:

bash> cat ~/.bash_history

Tmux and other terminal multiplexers themselves normally don’t provide a persistent command log. Commands executed in a tmux session run in normal shell processes. Whether those commands are saved depends on the tmux configurations. 

Commands Executed With Sudo

When a user runs commands with sudo, those events are typically logged in the authentication logs. You can grep for recorded COMMAND entries to see what privileged commands were executed:

bash> cat /var/log/auth.log* | grep -i COMMAND | less

Accessed Files With Vim

The Vim editor stores some local history and marks in a file named .viminfo in the user’s home directory. That file can include command-line history, search patterns and other useful traces of editing activity:

bash> cat ~/.viminfo

Log Files

Syslog

If the system logging service (for example, rsyslog or journald) is enabled and not tampered with, the files under /var/log are often the richest source of chronological evidence. The system log (syslog) records messages from many subsystems and services. Because syslog can become large, systems rotate older logs into files such as syslog.1, syslog.2.gz, and so on. Use shell wildcards and standard text tools to search through rotated logs efficiently:

bash> cat /var/log/syslog* | head

When reading syslog entries you will typically see a timestamp, the host name, the process producing the entry and a message. Look for unusual service failures, unexpected cron jobs running, or log entries from unknown processes.

Authentication Logs

Authentication activity, such as successful and failed logins, sudo attempts, SSH connections and PAM events are usually recorded in an authentication log such as /var/log/auth.log. Because these files can be large, use tools like grep, tail and less to focus on the relevant lines. For example, to find successful logins you run this:

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

Other Log Files

Many services keep their own logs under /var/log. Web servers, file-sharing services, mail daemons and other third-party software will have dedicated directories there. For example, Apache and Samba typically create subdirectories where you can inspect access and error logs:

bash> ls /var/log

bash> ls /var/log/apache2/

bash> ls /var/log/samba/

Conclusion

A steady, methodical sweep of the locations described above will give you a strong start in most Linux investigations. You start by verifying the OS, recording host metadata, enumerating users and groups, then you move to examining scheduled tasks and services, collecting relevant logs and history files. Always preserve evidence carefully and collect copies of volatile data when possible. In future articles we will expand on file system forensics, memory analysis and tools that make formal evidence collection and analysis easier.

Welcome back, aspiring cyberwarriors!

For decades, traditional HTTP traffic over TCP, also known as HTTP/1 and HTTP/2, has been the backbone of the web, and we have tools to analyze, intercept, and exploit it. But nowadays, we have HTTP/3, which is steadily increasing adoption across the web. In 2022, around 22% of all websites used HTTP/3; in 2025, this number increased to ~40%. And as cyberwarriors, we need to stay ahead of these changes.

In the article, we briefly explore what’s under the hood of HTTP/3 and how we can get in touch with it. Let’s get rolling!

What is HTTP/3?

HTTP/3 is the newest evolution of the Hypertext Transfer Protocol—the system that lets browsers, applications, and APIs move data across the Internet. What sets it apart is its break from TCP, the long-standing transport protocol that has powered the web since its earliest days.

TCP (Transmission Control Protocol) is reliable but inflexible. It was built for accuracy, not speed, ensuring that all data arrives in perfect order, even if that slows the entire connection. Each session requires a multi-step handshake, and if one packet gets delayed, everything behind it must wait. That might have been acceptable for email, but it’s a poor fit for modern, high-speed web traffic.

To overcome these limitations, HTTP/3 uses QUIC (Quick UDP Internet Connections), a transport protocol built on UDP and engineered for a fast, mobile, and latency-sensitive Internet. QUIC minimizes handshake overhead, avoids head-of-line blocking, and encrypts nearly the entire connection by default—right from the start.

After years of development, the IETF officially standardized HTTP/3 in 2022. Today, it’s widely implemented across major browsers, cloud platforms, and an ever-growing number of web servers.

What Is QUIC?

Traditional web traffic follows a predictable pattern. A client initiates a TCP three-way handshake, then performs a TLS handshake on top of that connection, and finally begins sending HTTP requests. QUIC collapses this entire process into a single handshake that combines transport and cryptographic negotiation. The first time a client connects to a server, it can establish a secure connection in just one round trip. On subsequent connections, QUIC can achieve zero round-trip time resumption, meaning the client can send encrypted application data in the very first packet.

The protocol encrypts almost everything except a minimal connection identifier. Unlike TLS over TCP, where we can see TCP headers, sequence numbers, and acknowledgments in plaintext, QUIC encrypts packet numbers, acknowledgments, and even connection close frames. This encryption-by-default approach significantly reduces the metadata available for traffic analysis.

QUIC also implements connection migration, which allows a connection to survive network changes. If a user switches from WiFi to cellular, or their IP address changes due to DHCP renewal, the QUIC connection persists using connection IDs rather than the traditional four-tuple of source IP, source port, destination IP, and destination port.

QUIC Handshake

The process begins when the client sends its Initial packet. This first message contains the client’s supported QUIC versions, the available cipher suites, a freshly generated random number, and a Connection ID — a randomly chosen identifier that remains stable even if the client’s IP address changes. Inside this Initial packet, the client embeds the TLS 1.3 ClientHello message along with QUIC transport parameters and the initial cryptographic material required to start key negotiation. If the client has connected to the server before, it may even include early application data, such as an HTTP request, to save an extra round trip.

The server then responds with its own set of information. It chooses one of the client’s QUIC versions and cipher suites, provides its own random number, and supplies a server-side Connection ID along with its QUIC transport parameters. Embedded inside this response is the TLS 1.3 ServerHello, which contains the cryptographic material needed to derive shared keys. The server also sends its full certificate chain — the server certificate as well as the intermediate certificate authorities (CAs) that signed it — and may optionally include early HTTP response data.

Once the client receives the server’s response, it begins the certificate verification process. It extracts the certificate data and the accompanying signature, identifies the issuing CA, and uses the appropriate root certificate from its trust store to verify the intermediate certificates and, ultimately, the server’s certificate. To do this, it hashes the received certificate data using the algorithm specified in the certificate, then checks whether this computed hash matches the one that can be verified using the CA’s public key. If the values match and the certificate is valid for the current time period and the domain name in use, the client can trust that the server is genuine. At this point, using the TLS key schedule, the client derives the QUIC connection keys and sends its TLS Finished message inside another QUIC packet. With this exchange completed, the connection is fully ready for encrypted application data.

From this moment onward, all traffic between the client and server is encrypted using the established session keys. Unlike traditional TCP combined with TLS, QUIC doesn’t require a separate TLS handshake phase. Instead, TLS is tightly integrated into QUIC’s own handshake, allowing the protocol to eliminate extra round-trips. One of the major advantages of this design is that both the server and client can include actual application data — such as HTTP requests and responses — within the handshake itself. As a result, certificate validation and connection establishment occur in parallel with the initial exchange of real data, making QUIC both faster and more efficient than the older TCP+TLS model.

How Does QUIC Network Work?

The image below shows the basic structure of a QUIC-based network. As illustrated, HTTP/3 requests, responses, and other application data all travel through QUIC streams. These streams are encapsulated in several logical layers before being transmitted over the network.

Anatomy of a QUIC stream:

A UDP datagram serves as the outer transport container. It contains a header with the source and destination ports, along with length and checksum information, and carries one or more QUIC packets. This is the fundamental unit transmitted between the client and server across the network.

A QUIC packet is the unit contained within a UDP datagram, and each datagram may carry one or more of them. Every QUIC packet consists of a QUIC header along with one or more QUIC frames.

The QUIC header contains metadata about the packet and comes in two formats. The long header is used during connection setup, while the short header is used once the connection is established. The short header includes the connection ID, packet number, and key phase, which indicates the encryption keys in use and supports key rotation. Packet numbers increase continuously for each connection and key phase.

A frame is the smallest structured unit inside a QUIC packet. It contains the frame type, stream ID, offset, and a segment of the stream’s data. Although the data for a stream is spread across multiple frames, it can be reassembled in the correct order using the connection ID, stream ID, and offset.

A stream is a unidirectional or bidirectional channel of data within a QUIC connection. Each QUIC connection can support multiple independent streams, each identified by its own ID. If a QUIC packet is lost, only the streams carried in that packet are affected, while all other streams continue uninterrupted. This independence is what eliminates the head-of-line blocking seen in HTTP/2. Streams can be created by either endpoint and can operate in both directions.

HTTP/3 vs. HTTP/2 vs. HTTP/1: What Actually Changed?

To understand the significance of HTTP/3, it helps to first consider the limitations of its predecessors.

HTTP/1.1, the original protocol still used by millions of websites, handles only one request per TCP connection. This forces browsers to open and close multiple connections just to load a single page, resulting in inefficiency, slower performance, and high sensitivity to network issues.

HTTP/2 introduced major improvements, including multiplexing, which allows multiple requests to share a single TCP connection, as well as header compression and server push. These changes provided significant gains, but the protocol still relies on TCP, which has a fundamental limitation: if one packet is delayed, the entire connection pipeline stalls. This phenomenon, known as head-of-line blocking, cannot be avoided in HTTP/2.

HTTP/3 addresses this limitation by replacing TCP with a more advanced transport layer. Built on QUIC, HTTP/3 establishes encrypted sessions faster, typically requiring only one round-trip instead of three or more. It eliminates head-of-line blocking by giving each stream independent flow control, allowing other streams to continue even if one packet is lost. It can maintain sessions through IP or network changes, recover more gracefully from packet loss, and even support custom congestion control tailored to different workloads.

In short, HTTP/3 is not merely a refined version of HTTP/2. It is a fundamentally redesigned protocol, created to overcome the limitations of previous generations, particularly for mobile users, latency-sensitive applications, and globally distributed traffic.

Get Started with HTTP/3

Modern versions of curl (7.66.0 and later with HTTP/3 support compiled in) can test whether a target supports QUIC and HTTP/3. Here’s how to probe a server:

kali> curl –http3 -I https://www.example.com

This command attempts to connect using HTTP/3 over QUIC, but will fall back to HTTP/2 or HTTP/1.1 if QUIC isn’t supported.

Besides that, it’s also useful to see how QUIC traffic looks “in the wild.” One of the easiest ways to do this is by using Wireshark, a popular tool for analyzing network packets. Even though QUIC encrypts most of its payload, Wireshark can still identify QUIC packet types, versions, and some metadata, which helps us understand how a QUIC connection is established.

To start, open Wireshark and visit a website that supports QUIC. Cloudflare is a good example because it widely deploys HTTP/3 and the QUIC protocol. QUIC typically runs over UDP port 443, so the simplest filter to confirm that you are seeing QUIC traffic is:

udp.port == 443

This filter shows all UDP traffic on port 443, which almost always corresponds to QUIC when dealing with modern websites.

QUIC uses different packet types during different stages of the connection. Even though the content is encrypted, Wireshark can still distinguish these packet types.

To show only Initial packets, which are the very first packets exchanged when a client starts a QUIC connection, use:

quic.long.packet_type == 0

Initial packets are part of QUIC’s handshake phase. They are somewhat similar to the “ClientHello” and “ServerHello” messages in TLS, except QUIC embeds the handshake inside the protocol itself.

If you want to view Handshake packets, which continue the cryptographic handshake after the Initial packets, use:

quic.long.packet_type == 2

These packets help complete the secure connection setup before QUIC switches to encrypted “short header” packets for normal data (like HTTP/3 requests and responses).
Also, QUIC has multiple versions, and servers often support more than one. To see packets that use a specific version, try:

quic.version == 0x00000001

This corresponds to QUIC version 1, which is standardized in RFC 9000. By checking which QUIC version appears in the traffic, you can understand what the server supports and whether it is using the standardized version or an older draft version.

Summary

QUIC isn’t just an incremental upgrade — it’s a complete reimagining of how modern internet communication should work. While the traditional stack of TCP + TLS + HTTP/2 served us well for many years, it was never designed for the realities of today’s internet: global-scale latency, constantly changing mobile connections, and the growing demand for both high performance and strong security. QUIC was built from the ground up to address these challenges, making it faster, more resilient, and more secure for the modern web.

Keep coming back, aspiring cyberwarriors, as we continue to explore how fundamental protocols of the internet are being rewritten.

Welcome back, aspiring cyberwarriors!

Before we can exploit a target, we need to understand its attack surface completely. This means identifying web servers, discovering hidden endpoints, analyzing response headers, and mapping out the entire web infrastructure. Traditional tools like curl and wget are useful, but they’re slow and cumbersome when you’re dealing with hundreds or thousands of targets. You need something faster and more flexible.

Httpx is a fast and multi-purpose HTTP toolkit developed by ProjectDiscovery that allows running multiple probes using a simple command-line interface. It supports HTTP/1.1, HTTP/2, and can probe for various web technologies, response codes, title extraction, and much more.

In this article, we will explore how to install httpx, how to use it, and how to extract detailed information about a target. We will also cover advanced filtering techniques and discuss how to use this tool effectively. Let’s get rolling!

Step #1 Install Go Programming Language

Httpx is written in Go, so we need to have the Go programming language installed on our system.

To install Go on Kali Linux, use the following command:

kali > sudo apt install golang-go

Once the installation completes, verify it worked by checking the version:

kali > go version

Step #2 Install httpx Using Go

To install httpx, enter the following command:

kali > go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

The “-v” flag enables verbose output so you can see what’s happening during the installation. The “@latest” tag ensures you’re getting the most recent stable version of httpx. This command will download the source code, compile it, and install the binary in your Go bin directory.

To make sure httpx is accessible from anywhere in your terminal, you need to add the Go bin directory to your PATH if it’s not already there. Check if it’s in your PATH by typing:

kali > echo $PATH

If you don’t see something like “/home/kali/go/bin” in the output, you’ll need to add it. Open your .bashrc or .zshrc file (depending on which shell you use) and add this line:

export PATH=$PATH:~/go/bin

Then reload your shell configuration:

kali > source ~/.bashrc

Now verify that httpx is installed correctly by checking its version:

kali > httpx -version

Step #3 Basic httpx Usage and Probing

Let’s start with some basic httpx usage to understand how the tool works. Httpx is designed to take a list of hosts and probe them to determine if they’re running web servers and extract information about them.

The simplest way to use httpx is to provide a single target directly on the command line. Let’s probe a single domain:

kali> httpx -u “example.com” -probe

This command initiates an HTTP probe on the website. This is useful for quickly checking the availability of the web page.

Now let’s try probing multiple targets at once. Create a file with several domains you want to probe.

Now run httpx against this file:

kali > httpx -l hosts.txt -probe

Step #4 Extracting Detailed Information

One of httpx’s most powerful features is its ability to extract detailed information about web servers in a single pass.

Let’s quickly identify what web server is hosting each target:

kali > httpx -l hosts.txt -server

Now let’s extract even more information using multiple flags:

kali> httpx -l hosts.txt -title -tech-detect -status-code -content-length -response-time

This command will extract the page title, detect web technologies, show the HTTP status code, display the content length, and measure the response time.

The “-tech-detect” flag is particularly valuable because it uses Wappalyzer fingerprints to identify the technologies running on each web server. This can reveal content management systems, web frameworks, and other technologies that might have known vulnerabilities.

Step #5 Advanced Filtering and Matchers

Filters in httpx allow you to exclude unwanted responses based on specific criteria, such as HTTP status codes or text content.

Let’s say you don’t want to see targets that return a 301 status code. For this purpose, the -filter-code or -fc flag exists. To see the results clearly, I’ve added the -status-code or -sc flag as well:

kali > httpx -l hosts.txt -sc -fc 301

Httpx outputs filtered results without status code 301. Besides that, you can filter “dead” or default/error responses with -filter-error-page or -fep flag.

kali> httpx -l hosts.txt -sc -fep

This flag enables “filter response with ML-based error page detection”. In other words, when you use -fep, httpx tries to detect and filter out responses that look like generic or error pages.

In addition to filters, httpx has matchers. While filters exclude unwanted responses, matchers include only the responses that meet specific criteria. Think of filters as removing noise, and matchers as focusing on exactly what you’re looking for.

For example, let’s output only responses with 200 status code using the -match-code or -mc flag:

kali> httpx -l hosts.txt -status-code -match-code 200

For more advanced filtering, you can use regex patterns to match specific content in the response (-match-regex or -mr flag):

kali> httpx -l hosts.txt -match-regex “admin|login|dashboard”

This will only show targets whose response body contains the words “admin,” “login,” or “dashboard,” helping you quickly identify administrative interfaces or login pages.

Step #6 Probing for Specific Vulnerabilities and Misconfigurations

Httpx can be used to quickly identify common vulnerabilities and misconfigurations across large numbers of targets. While it’s not a full vulnerability scanner, it can detect certain issues that indicate potential security problems.

For example, let’s probe for specific paths that might indicate vulnerabilities or interesting endpoints:

kali > httpx -l targets.txt -path “/admin,/login,/.git,/backup,/.env”

The -path flag, as the name suggests, tells httpx to probe specific paths on each target.

Another useful technique is probing for different HTTP methods:

kali > httpx -l targets.txt -sc -method -x all

In the command above, the -method flag is used to display HTTP request method, and -x all to probe all of these methods.

Summary

Traditional HTTP probing tools are too slow and limited for the kind of large-scale reconnaissance that modern bug bounty and pentesting demands. Httpx provides a fast, flexible, and powerful solution that’s specifically designed for security researchers who need to quickly analyze hundreds or thousands of web targets while extracting comprehensive information about each one.

In this article, we covered how to install httpx, basic and advanced usage examples as well as shared ideas on how httpx might be used for vulnerability detections. This tool really fast and can significantly boost your productivity whether you’re conducting bug bounty hunting or web app security testing. Check this out, maybe it will find a place in your cyberwarriors toolbox.

Welcome back, aspiring digital investigators!

Today we will take a look at WhatsApp forensics. WhatsApp is one of those apps that are both private and routine for many users. People treat chats like a private conversation, and because it feels comfortable, users often share things there that they would not say on public social networks. That’s why WhatsApp is so critical for digital forensics. The app stores conversations, media, timestamps, group membership information and metadata that can help reconstruct events, identify contacts and corroborate timelines in criminal and cyber investigations.

At Hackers-Arise we offer professional digital forensics services that support cybercrime investigations and fraud examinations. WhatsApp forensics is done to find reliable evidence. The data recovered from a device can show who communicated with whom, when messages were sent and received, what media was exchanged, and often which account owned the device. That information is used to link suspects and verify statements. It also maps movements when combined with location artifacts that investigators and prosecutors can trust.

You will see how WhatsApp keeps its data on different platforms and what those files contain.

WhatsApp Artifacts on Android Devices

On Android, WhatsApp stores most of its private application data inside the device’s user data area. In a typical layout you will find the app’s files under a path such as /data/data/com.whatsapp/ (or equivalently /data/user/0/com.whatsapp/ on many devices). Those directories are not normally accessible without elevated privileges. To read them directly you will usually need superuser (root) access on the device or a physical dump of the file system obtained through lawful and technically appropriate means. If you do not have root or a physical image, your options are restricted to logical backups or other extraction methods which may not expose the private WhatsApp databases.

Two files deserve immediate attention on Android: wa.db and msgstore.db. Both are SQLite databases and together they form the core of WhatsApp evidence.

wa.db is the contacts database. It lists the WhatsApp user’s contacts and typically contains phone numbers, display names, status strings, timestamps for when contacts were created or changed, and other registration metadata. You will usually open the file with a SQLite browser or query it with sqlite3 to inspect tables. The key tables investigators look for are the table that stores contact records (often named wa_contacts or similar), sqlite_sequence which holds auto-increment counts and gives you a sense of scale, and android_metadata which contains localization info such as the app language.

Wa.db is essentially the address book for WhatsApp. It has names, numbers and a little context for each contact.

msgstore.db is the message store. This database contains sent and received messages, timestamps, message status, sender and receiver identifiers, and references to media files. In many WhatsApp versions you will find tables that include a general information table (often named sqlite_sequence), a full-text index table for message content (message_fts_content or similar), the main messages table which usually contains the message body and metadata, messages_thumbnails which catalogs images and their timestamps, and a chat_list table that stores conversation entries. 

Be aware that WhatsApp evolves and field names change between versions. Newer schema versions may include extra fields such as media_enc_hash, edit_version, or payment_transaction_id. Always inspect the schema before you rely on a specific field name.

On many Android devices WhatsApp also keeps encrypted backups in a public storage location, typically under /data/media/0/WhatsApp/Databases/ (the virtual SD card)

or /mnt/sdcard/WhatsApp/Databases/ for physical SD cards. Those backup files look like msgstore.db.cryptXX, where XX indicates the cryptographic scheme version. 

The msgstore.db.cryptXX files are an encrypted copy of msgstore.db intended for device backups. To decrypt them you need a cryptographic key that WhatsApp stores privately on the device, usually somewhere like /data/data/com.whatsapp/files/. Without that key, those encrypted backups are not readable.

Other important Android files and directories to examine include the preferences and registration XMLs in /data/data/com.whatsapp/shared_prefs/. The file com.whatsapp_preferences.xml often contains profile details and configuration values. A fragment of such a file may show the phone number associated with the account, the app version, a profile message such as “Hey there! I am using WhatsApp.” and the account display name. The registration.RegisterPhone.xml file typically contains registration metadata like the phone number and regional format. 

The axolotl.db file in /data/data/com.whatsapp/databases/ holds cryptographic keys (used in the Signal/Double Ratchet protocol implementation) and account identification data. chatsettings.db contains app settings. Logs are kept under /data/data/com.whatsapp/files/Logs/ and may include whatsapp.log as well as compressed rotated backups like whatsapp-YYYY-MM-DD.1.log.gz

These logs can reveal app activity and errors that may be useful for timing or troubleshooting analysis.

Media is often stored in the media tree on internal or external storage:

/data/media/0/WhatsApp/Media/WhatsApp Images/ for images,

/data/media/0/WhatsApp/Media/WhatsApp Voice Notes/ for voice messages (usually Opus format), WhatsApp Audio, WhatsApp Video, and WhatsApp Profile Photos.

Within the app’s private area you may also find cached profile pictures under /data/data/com.whatsapp/cache/Profile Pictures/ and avatar thumbnails under /data/data/com.whatsapp/files/Avatars/. Some avatar thumbnails use a .j extension while actually being JPEG files. Always validate file signatures rather than trusting extensions.

If the device uses an SD card, a WhatsApp directory at the card’s root may store copies of shared files (/mnt/sdcard/WhatsApp/.Share/), a trash folder for deleted content (/mnt/sdcard/WhatsApp/.trash/), and the Databases subdirectory with encrypted backups and media subfolders mirroring those on internal storage. The presence of deleted files or .trash folders can be a fruitful source of recovered media.

A key complication on Android is manufacturer or custom-ROM behavior. Some vendors add features that change where app data is stored. For example, certain Xiaomi phones implement a “Second Space” feature that creates a second user workspace. WhatsApp in the second workspace stores its data under a different user ID path such as /data/user/10/com.whatsapp/databases/wa.db rather than the usual /data/user/0/com.whatsapp/databases/wa.db

As things evolve and change, you need to validate the actual paths on the target device rather than assuming standard locations.

WhatsApp Artifacts on iOS Devices

On iOS, WhatsApp tends to centralize its data into a few places and is commonly accessible via device backups. The main application database is often ChatStorage.sqlite located under a shared group container such as /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/ (some forensic tools display this as AppDomainGroup-group.net.whatsapp.WhatsApp.shared).

Within ChatStorage.sqlite the most informative tables are often ZWAMESSAGE, which stores message records, and ZWAMEDIAITEM, which stores metadata for attachments and media items. Other tables like ZWAPROFILEPUSHNAME and ZWAPROFILEPICTUREITEM map WhatsApp identifiers to display names and avatars. The table Z_PRIMARYKEY typically contains general database metadata such as record counts.

iOS also places supporting files in the group container. BackedUpKeyValue.sqlite can contain cryptographic keys and data useful for identifying account ownership. ContactsV2.sqlite stores contact details: names, phone numbers, profile statuses and WhatsApp IDs. A simple text file like consumer_version may hold the app version and current_wallpaper.jpg (or wallpaper in older versions) contains the background image used in WhatsApp chats. The blockedcontacts.dat file lists blocked numbers, and pw.dat can hold an encrypted password. Preference plists such as net.whatsapp.WhatsApp.plist or group.net.whatsapp.WhatsApp.shared.plist store profile settings.

Media thumbnails, avatars and message media are stored under paths like /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Media/Profile/ and /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Message/Media/. WhatsApp logs, for example calls.log and calls.backup.log, often survive in the Documents or Library/Logs folders and can help establish call activity.

Because iOS devices are frequently backed up through iTunes or Finder, you can often extract WhatsApp artefacts from a device backup rather than needing a full file system image. If the backup is unencrypted and complete, it may include the ChatStorage.sqlite file and associated media. If the backup is encrypted you will need the backup password or legal access methods to decrypt it. In practice, many investigators create a forensic backup and then examine the WhatsApp databases with a SQLite viewer or a specialized forensic tool that understands WhatsApp schema differences across versions.

Practical Notes For Beginners

From the databases and media files described above you can recover contact lists, full or partial chat histories, timestamps in epoch format (commonly Unix epoch in milliseconds on Android), message status (sent, delivered, read), media filenames and hashes, group membership, profile names and avatars, blocked contacts, and even application logs and version metadata. It helps us understand who communicated with whom, when messages were exchanged, whether media were transferred, and which accounts were configured on the device.

For beginners, a few practical cautions are important to keep in mind. First, always operate on forensic images or copies of extracted files. Do not work directly on the live device unless you are performing an approved, controlled acquisition and you have documented every action. Second, use reliable forensic tools to open SQLite databases. If you are parsing fields manually, confirm timestamp formats and time zones. Third, encrypted backups require the device’s key to decrypt. The key is usually stored in the private application area on Android, and without it you cannot decode the .cryptXX files. Fourth, deleted chats and files are not always gone, as databases may leave records or media may remain in caches or on external storage. Yet recovery is never guaranteed and depends on many factors including the time since deletion and subsequent device activity.

When you review message tables, map the message ID fields to media references carefully. Many WhatsApp versions use separate tables for media items where the actual file is referenced by a media ID or filename. Thumbnail tables and media directories will help you reconstruct the link between a textual message and the file that accompanied it. Pay attention to the presence of additional fields in newer app versions. These may contain payment IDs, edit history or encryption metadata. Adapt your queries accordingly.

Finally, because WhatsApp and operating systems change over time, always inspect the schema and file timestamps on the specific evidence you have. Do not assume field names or paths are identical between devices or app versions. Keep a list of the paths and filenames you find so you can reproduce your process and explain it in reports.

Summary

WhatsApp forensics is a rich discipline. On Android the primary artifacts are the wa.db contacts database, the msgstore.db message store and encrypted backups such as msgstore.db.cryptXX, together with media directories, preference XMLs and cryptographic key material in the app private area. On iOS the main artifact is ChatStorage.sqlite and a few supporting files in the app group container and possibly contained in a device backup. To retrieve and interpret these artifacts you must have appropriate access to the device or an image and know where to look for the app files on the device you are examining. Also, be comfortable inspecting SQLite databases and be prepared to decrypt backups where necessary.

If this kind of work interests you and you want to understand how real mobile investigations are carried out, you can also join our three-day mobile forensics course. The training walks you through the essentials of Android and iOS, explains how evidence is stored on modern devices, and shows you how investigators extract and analyze that data during real cases. You will work with practical labs that involve hidden apps, encrypted communication, and devices that may have been rooted or tampered with. 

Learn more:

https://hackersarise.thinkific.com/courses/mobile-forensics

Hello, aspiring digital forensics investigators!

Welcome back to our guide on memory analysis!

In the first part, we covered the fundamentals, including processes, dumps, DLLs, handles, and services, using Volatility as our primary tool. We created this series to give you more clarity and help you build confidence in handling memory analysis cases. Digital forensics is a fascinating area of cybersecurity and earning a certification in it can open many doors for you. Once you grasp the key concepts, you’ll find it easier to navigate the field. Ultimately, it all comes down to mastering a core set of commands, along with persistence and curiosity. Governments, companies, law enforcement and federal agencies are all in need of skilled professionals  As cyberattacks become more frequent and sophisticated, often with the help of AI, opportunities for digital forensics analysts will only continue to grow.

Now, in part two, we’re building on that to explore more areas that help uncover hidden threats. We’ll look at network info to see connections, registry keys for system changes, files in memory, and some scans like malfind and Yara rules to find malware. Plus, as promised, there are bonuses at the end for quick ways to pull out extra details

Network Information

As a beginner analyst, you’d run network commands to check for sneaky connections, like if malware is phoning home to hackers. For example, imagine investigating a company’s network after a data breach, these tools could reveal a hidden link to a foreign server stealing customer info, helping you trace the attacker.

‘Netscan‘ scans for all network artifacts, including TCP/UDP. ‘Netstat‘ lists active connections and sockets. In Vol 2, XP/2003-specific ones like ‘connscan‘ and ‘connections‘ focus on TCP, ‘sockscan‘ and ‘sockets‘ on sockets, but they’re old and not present in Vol 3.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> netscan

vol.py -f “/path/to/file” ‑‑profile <profile> netstat

XP/2003 SPECIFIC:

vol.py -f “/path/to/file” ‑‑profile <profile> connscan

vol.py -f “/path/to/file” ‑‑profile <profile> connections

vol.py -f “/path/to/file” ‑‑profile <profile> sockscan

vol.py -f “/path/to/file” ‑‑profile <profile> sockets

Volatility 3:

vol.py -f “/path/to/file” windows.netscan

vol.py -f “/path/to/file” windows.netstat

bash$ > vol -f Windows7.vmem windows.netscan

This output shows network connections with protocols, addresses, and PIDs. Perfect for spotting unusual traffic.

bash$ > vol -f Windows7.vmem windows.netstat

Here, you’ll get a list of active sockets and states, like listening or established links.

Note, the XP/2003 specific plugins are deprecated and therefore not available in Volatility 3, although are still common in the poorly financed government sector.

Registry

Hive List

You’d use hive list commands to find registry hives in memory, which store system settings malware often tweaks these for persistence. Say you’re checking a home computer after suspicious pop-ups. This could show changes to startup keys that launch bad software every boot.

‘hivescan‘ scans for hive structures. ‘hivelist‘ lists them with virtual and physical addresses.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> hivescan

vol.py -f “/path/to/file” ‑‑profile <profile> hivelist

Volatility 3:

vol.py -f “/path/to/file” windows.registry.hivescan

vol.py -f “/path/to/file” windows.registry.hivelist

bash$ > vol -f Windows7.vmem windows.registry.hivelist

This lists the registry hives with their paths and offsets for further digging.

bash$ > vol -f Windows7.vmem windows.registry.hivescan

The scan output highlights hive locations in memory.

Printkey

Printkey is handy for viewing specific registry keys and values, like checking for malware-added entries. For instance, in a ransomware case, you might look at keys that control file associations to see if they’ve been hijacked.

Without a key, it shows defaults, while -K or –key targets a certain path.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> printkey

vol.py -f “/path/to/file” ‑‑profile <profile> printkey -K “Software\Microsoft\Windows\CurrentVersion”

Volatility 3:

vol.py -f “/path/to/file” windows.registry.printkey

vol.py -f “/path/to/file” windows.registry.printkey ‑‑key “Software\Microsoft\Windows\CurrentVersion”

bash$ > vol -f Windows7.vmem windows.registry.printkey

This gives a broad view of registry keys.

bash$ > vol -f Windows7.vmem windows.registry.printkey –key “Software\Microsoft\Windows\CurrentVersion”

Here, it focuses on the specified key, showing subkeys and values.

Files

File Scan

Filescan helps list files cached in memory, even deleted ones, great for finding malware files that were run but erased from disk. This can uncover temporary files from the infection.

Both versions scan for file objects in memory pools.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> filescan

Volatility 3:

vol.py -f “/path/to/file” windows.filescan

bash$ > vol -f Windows7.vmem windows.filescan

This output lists file paths, offsets, and access types.

File Dump

You’d dump files to extract them from memory for closer checks, like pulling a suspicious script. In a corporate espionage probe, dumping a hidden document could reveal leaked secrets.

Without options, it dumps all. With offsets or PID, it targets specific ones. Vol 3 uses virtual or physical addresses.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir”

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -Q <offset>

vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -p <PID>

Volatility 3:

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑virtaddr <offset>

vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑physaddr <offset>

bash$ > vol -f Windows7.vmem windows.dumpfiles

This pulls all cached files Windows has in RAM.

Miscellaneous

Malfind

Malfind scans for injected code in processes, flagging potential malware.

Vol 2 shows basics like hexdump. Vol 3 adds more details like protection and disassembly.

Volatility 2:

vol.py -f “/path/to/file” ‑‑profile <profile> malfind

Volatility 3:

vol.py -f “/path/to/file” windows.malfind

bash$ > vol -f Windows7.vmem windows.malfind

This highlights suspicious memory regions with details.

Yara Scan

Yara scan uses rules to hunt for malware patterns across memory. It’s like a custom detector. For example, during a widespread attack like WannaCry, a Yara rule could quickly find infected processes.

Vol 2 uses file path. Vol 3 allows inline rules, file, or kernel-wide scan.

Volatility 2:

vol.py -f “/path/to/file” yarascan -y “/path/to/file.yar”

Volatility 3:

vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-rules <string>

vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-file “/path/to/file.yar”

vol.py -f “/path/to/file” yarascan.yarascan ‑‑yara-file “/path/to/file.yar”

bash$ > vol -f Windows7.vmem windows.vadyarascan –yara-file yara_fules/Wannacrypt.yar

As you can see we found the malware and all related processes to it with the help of the rule

Bonus

Using the strings command, you can quickly uncover additional useful details, such as IP addresses, email addresses, and remnants from PowerShell or command prompt activities.

Emails

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

IPs

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

Powershell and CMD artifacts

bash$ > strings Windows7.vmem | grep -E "(cmd|powershell|bash)[^\s]+"

Summary

By now you should feel comfortable with all the network analysis, file dumps, hives and registries we had to go through. As you practice, your confidence will grow fast. The commands covered here will help you solve most of the cases as they are fundamental. Also, don’t forget that Volatility has a lot more different plugins that you may want to explore. Feel free to come back to this guide anytime you want. Part 1 will remind you how to approach a memory dump, while Part 2 has the commands you need. In this part, we’ve expanded your Volatility toolkit with network scans to track connections, registry tools to check settings, file commands to extract cached items, and miscellaneous scans like malfind for injections and Yara for pattern matching. Together they give you a solid set of steps. 

If you want to turn this into a career, our digital forensics courses are built to get you there. Many students use this training to prepare for industry certifications and job interviews. Our focus is on the practical skills that hiring teams look for.

Welcome back, aspiring cyberwarriors!

The STRIDE methodology has been the gold standard for systematic threat identification, categorizing threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. However, applying STRIDE effectively requires not just understanding these categories but also having the experience to identify how they manifest in specific application architectures.

To solve this problem, we have STRIDE GPT. By combining the analytical power of AI with the proven STRIDE methodology, this tool can generate comprehensive threat models, attack trees, and mitigation strategies in minutes rather than hours or days.

In this article, we’ll walk you through how to install STRIDE GPT, check out its features, and get you started using them. Let’s get rolling!

Step #1: Install STRIDE GPT

First, make certain you have Python 3.8 or later installed on your system.

pi> python3 –version

Now, clone the STRIDE GPT repository from GitHub.

pi > git clone https://github.com/mrwadams/stride-gpt.git

pi> cd stride-gpt

Next, install the required Python dependencies.

pi > pip3 install -r requirements.txt –break-system-packages

This installation process may take a few minutes.

Step #2: Configure Your Groq API Key

STRIDE GPT supports multiple AI providers including OpenAI, Anthropic, Google AI, Mistral, and Groq, as well as local hosting options through Ollama and LM Studio Server. In this example, I’ll be using Groq. Groq provides access to models like Llama 3.3 70B, DeepSeek R1, and Qwen3 32B through their Lightning Processing Units, which deliver inference speeds significantly faster than traditional GPU-based solutions. Besides that, Groq’s API is cost-effective compared to proprietary models.

To use STRIDE GPT with Groq, you need to obtain an API key from Groq. The tool supports loading API keys through environment variables, which is the most secure method for managing credentials. In the stride-gpt directory, you’ll find a file named .env.example. Copy this file to create your own .env file:

pi > cp .env.example .env

Now, open the .env file in your preferred text editor and add the API key.

Step #3: Launch STRIDE GPT

Start the application by running:

pi> python3 -m streamlit run main.py

Streamlit will start a local web server.

Once you copy the URL into your browser, you will see a dashboard similar to the one shown below.

In the STRIDE GPT sidebar, you’ll see a dropdown menu labeled “Select Model Provider”. Click on this dropdown and you’ll see options for OpenAI, Azure OpenAI, Google AI, Mistral AI, Anthropic, Groq, Ollama, and LM Studio Server.

Select “Groq” from this list. The interface will update to show Groq-specific configuration options. You’ll see a field for entering your API key. If you configured the .env file correctly in Step 2, this field should already be populated with your key. If not, you can enter it directly in the interface, though this is less secure as the key will only persist for your current session.

Below the API key field, you’ll see a dropdown for selecting the specific Groq model you want to use. For this tutorial, I selected Llama 3.3 70B.

Step #4: Describe Your Application

Now comes the critical part where you provide information about the application you want to threat model. The quality and comprehensiveness of your threat model depends heavily on the detail you provide in this step.

In the main area of the interface, you’ll see a text box labeled “Describe the application to be modelled”. This is where you provide a description of your application’s architecture, functionality, and security-relevant characteristics.

Let’s work through a practical example. Suppose you’re building a web-based project management application. Here’s the kind of description you should provide:

“This is a web-based project management application built with a React frontend and a Node.js backend API. The application uses JWT tokens for authentication, with tokens stored in HTTP-only cookies. Users can create projects, assign tasks to team members, upload file attachments, and generate reports. The application is internet-facing and accessible to both authenticated users and unauthenticated visitors who can view a limited public project showcase. The backend connects to a PostgreSQL database that stores user credentials, project data, task information, and file metadata. Actual file uploads are stored in an AWS S3 bucket. The application processes sensitive data including user email addresses, project details that may contain confidential business information, and file attachments that could contain proprietary documents. The application implements role-based access control with three roles: Admin, Project Manager, and Team Member. Admins can manage users and system settings, Project Managers can create and manage projects, and Team Members can view assigned tasks and update their status.”

The more specific you are, the more targeted and actionable your threat model will be.

Besides that, near the application description field, you’ll see several dropdowns that help STRIDE GPT understand your application’s security context.

Step #5: Generate Your Threat Model

With all the configuration complete and your application described, you’re ready to generate your threat model. Look for a button labeled “Generate Threat Model” and click it.

Once complete, you’ll see a comprehensive threat model organized by the STRIDE categories. For each category, the model will identify specific threats relevant to your application. Let’s look at what you might see for our project management application example:

Each threat includes a detailed description explaining how the attack could be carried out and what the impact would be.

Step #6: Generate an Attack Tree

Beyond the basic threat model, STRIDE GPT can generate attack trees that visualize how an attacker might chain multiple vulnerabilities together to achieve a specific objective.

The tool generates these attack trees in Mermaid diagram format, which renders as an interactive visual diagram directly in your browser.

Step #7: Review DREAD Risk Scores

STRIDE GPT implements the DREAD risk scoring model to help you prioritize which threats to address first.

The tool will analyze each threat and assign scores from 1 to 10 for five factors:

Damage: How severe would the impact be if the threat were exploited?

Reproducibility: How easy is it to reproduce the attack?

Exploitability: How much effort and skill would be required to exploit the vulnerability?

Affected Users: How many users would be impacted?

Discoverability: How easy is it for an attacker to discover the vulnerability?

The DREAD assessment appears in a table format showing each threat, its individual factor scores, and its overall risk score.

Step #8: Generate Mitigation Strategies

Identifying threats is only half the battle. You also need actionable guidance on how to address them. STRIDE GPT includes a feature to generate specific mitigation strategies for each identified threat.

Look for a button labeled “Mitigations” and click it.

These mitigation strategies are specific to your application’s architecture and the threats identified. They’re not generic security advice but targeted recommendations based on the actual risks in your system.

Step #8: Generate Gherkin Test Cases

One of the most innovative features of STRIDE GPT is its ability to generate Gherkin test cases based on the identified threats. Gherkin is a business-readable, domain-specific language used in Behavior-Driven Development to describe software behaviors without detailing how that behavior is implemented. These test cases can be integrated into your automated testing pipeline to ensure that the mitigations you implement actually work.

Look for a button labeled “Generate Test Cases”. When you click it, STRIDE GPT will create Gherkin scenarios for each major threat.

Summary

Traditional threat modeling takes a lot of time and requires experts, which stops many organizations from doing it well. STRIDE GPT makes threat modeling easier for everyone by using AI to automate the analysis while keeping the quality of the proven STRIDE method.

In this article, we checked out STRIDE GPT and went over its main features. No matter if you’re protecting a basic web app or a complicated microservices setup, STRIDE GPT gives you the analytical tools you need to spot and tackle security threats in a straightforward way.

Welcome back, dear digital investigators! 

Today, we’re exploring mobile forensics, a field that matters deeply in modern crime investigations. Think about how much our phones know about us. They carry our contacts, messages, locations, and app history in many ways. They are a living log of our daily lives. Because they travel with us everywhere, they can be a goldmine of evidence when something serious happens, like a crime. In a murder investigation, for instance, a suspect’s or a victim’s phone can help us answer critical questions: Who were they in touch with right before the crime? Where did they go? What were they doing? What kind of money dealings were they involved in? All of this makes mobile forensics powerful for investigators. As digital forensic specialists, we use that data to reconstruct timelines, detect motives, and understand relationships. Because of this, even a seemingly small app on a phone might have huge significance. For example, financial trading apps may reveal risky behavior or debt. Chat apps might contain confessions or threats. Location logs might show the victim visiting unusual places.

The Difference Between Android and iOS Forensics

When we do mobile forensics, we usually see Android and iOS devices. These two operating systems are quite different under the hood, and that affects how we work with them. On Android, there’s generally more openness. The file system for many devices is more accessible, letting us examine data stored in app directories, caches, logs, and more. Because Android is so widespread and also fragmented with many manufacturers and versions, the data we can access depends a lot on the model and version. 

On iOS, things are tighter. Apple uses its own file system (APFS), and there’s strong encryption, often backed by secure hardware. That means extracting data can be more challenging. Because of this, forensic tools must be very sophisticated to handle iOS devices.

When it comes to which has more usable data, Android often gives us more raw artifacts because of its flexibility. But iOS can also be very rich, especially when data is backed up to iCloud or when we can legally access the device in powerful ways.

The Tools For the Job

One of the most powerful tools is Cellebrite, which is used by law enforcement and digital forensic labs. Cellebrite’s tools are capable of extracting data from both Android and iOS devices, sometimes even from locked devices. But the ability to extract depends a lot on the device model, its security patch level, and how encrypted it is.

There’s an interesting twist when it comes to GrapheneOS, which is a very security-focused version of Android. According to reports, Cellebrite tools struggle more with GrapheneOS, especially on devices updated after 2022. In some cases, they may be able to do a “consent-based” extraction (meaning the phone has to be unlocked by the user), but they can’t fully bypass the security on a fully patched GrapheneOS phone. Because of that, from a security perspective, users are strongly encouraged to keep their firmware and operating system updated. Regular updates close vulnerabilities. Also, using strong passcodes, enabling encryption, and being careful about where sensitive data is stored can make a real difference in protecting personal data.

Our Case: Investigating a Murder Using an Android Phone

Now, let’s turn to our case. We are in the middle of a murder investigation, and we’ve managed to secure the victim’s Android phone. After talking with witnesses and people who were close to the victim, we believe this phone holds critical evidence. To analyze all of that, we are using ALEAPP, a forensic tool made specifically for parsing Android data.

ALEAPP and How It Works

ALEAPP stands for Android Logs, Events, And Protobuf Parser. It’s an open-source tool maintained by the forensic community. Basically, ALEAPP allows us to take the extracted data from an Android phone, whether it’s a logical extraction, a TAR or ZIP file, or a file-system dump and turn that raw data into a human-readable, well-organized report. ALEAPP can run through a graphical interface, which is very friendly and visual, or via command line, depending on how you prefer to work. As it processes data, it goes through different modules for things like call logs, SMS, app usage, accounts, Wi-Fi events, and more. In the end, it outputs a report, so you can easily explore and navigate all the findings.

You can find the repository here:

https://github.com/abrignoni/ALEAPP

What We Found on the Victim’s Phone

We started by examining the internal storage of the Android device, especially the /data folder. This is where apps keep their private data, caches, and account information. Then, we prepared a separate place on our investigation workstation, a folder called output, where ALEAPP would save its processed data.

Once ALEAPP was ready, we launched it and pointed it to the extracted directories. We left all its parsing modules turned on so we wouldn’t miss any important artifact. We clicked “Process,” and depending on the size of the extracted data, we waited for a few minutes while ALEAPP parsed everything.

When the processing was done, a new folder appeared inside our output directory. In that folder, there was a file called index.html, that’s our main report. We opened it with a browser and the GUI showed us different categories. The interface is clean and intuitive, so even someone not deeply familiar with command-line tools can navigate it.

Evidence That Stood Out

One of the first things that caught our attention was a trading app. ALEAPP showed an installed application named OlympTrade. A quick web search confirmed that OlympTrade is a real online trading platform. That fits with what witnesses told us. The victim was involved in trading, possibly borrowing or investing money. We also noted a hash value for the app in our report, which helps prove the data’s integrity. This means we can be more confident that what we saw hasn’t been tampered with.

Next, we turned to text messages. According to the victim’s best friend’s testimony, the victim avoided some calls and said he owed a lot of money. When we checked SMS data in ALEAPP, we found a thread where the victim indeed owed $25,000 USD to someone.

We looked up the number in the contacts list, and it was saved under the name John Oberlander. That makes John an important person of interest in this investigation.

Then, we dove into location data. The victim’s family said that on September 20, 2023, he left his home without saying where he was going. In ALEAPP’s “Recent Activity” section, which tracks events like Wi-Fi connections, GPS logs, and other background activity, we saw evidence placing him at The Nile Ritz-Carlton in Cairo, Egypt. This is significant. A 5-star hotel, which could have security footage, check-in records, or payment logs. Investigators would almost certainly reach out to the hotel to reconstruct his stay.

The detective pressed on with his investigation and spoke with the hotel staff, hoping to fill in more of the victim’s final days. The employees confirmed that the victim had booked a room for ten days and was supposed to take a flight afterward. Naturally, the investigator wondered whether the victim had saved any ticket information on the phone, since many people store their travel plans digitally nowadays. Even though no tickets turned up in the phone’s files, the search did reveal something entirely different, and potentially much more important. We looked at Discord, since the app appeared in the list of installed applications. Discord logs can reveal private chats, plans, and sometimes illicit behavior. In this case, we saw a conversation indicating that the victim changed his travel plans. He postponed a flight to October 1st, according to the chat.

Later, he agreed to meet someone in person at a very specific place. It was the Fountains of Bellagio in Las Vegas. That detail could tie into motive or meetings related to the crime.

What Happens Next

At this stage, we’ve collected and parsed digital evidence, but our work is far from over. Now, we need to connect the phone-based data to the real world. That means requesting more information from visited places, checking for possible boarding or ticket purchases, and interviewing people named in the phone, like John Oberlander, or the person from Discord.

We might also want to validate financial trail through the trading platform (if we can access it legally), bank statements, or payment records. And importantly, we should search for other devices or backups. Maybe the victim had cloud backups, like Google Drive, or other devices that shed more light.

Reconstructed Timeline

The victim was heavily involved in trading and apparently owed $25,000 USD to John Oberlander. On September 20, 2023, he left his residence without telling anyone where he was headed. The phone’s location data places him later that day at The Nile Ritz-Carlton in Cairo, suggesting he stayed there. Sometime afterward, according to Discord chats, he changed his travel plans and his flight was rescheduled for October 1. During these chats, he arranged a meeting with someone at the Fountains of Bellagio in Las Vegas.

Summary

Mobile forensics is a deeply powerful tool when investigating crimes. A single smartphone can hold evidence that helps reconstruct what happened, when, and with whom. Android devices often offer more raw data because of their openness, while iOS devices pose different challenges due to their strong encryption. Tools like ALEAPP let us parse all of that data into meaningful and structured reports.

In the case we’re studying, the victim’s phone has offered us insights into his financial troubles, his social connections, his movements, and his plans. But digital evidence is only one piece. To solve a crime, we must combine what we learn from devices with interviews, external records, and careful collaboration with other investigators.

Our team provides professional mobile forensics services designed to support individuals, organizations, and legal professionals who need clear, reliable answers grounded in technical expertise. We also offer a comprehensive digital forensics course for those who want to build their own investigative skills and understand how evidence is recovered, analyzed, and preserved. And if you feel that your safety or your life may be at risk, reach out immediately. Whether you need guidance, assistance, or a deeper understanding of the digital traces surrounding your case, we are here to help.

Check out our Mobile Forensics training for more in-depth training

Welcome back, my aspiring hackers!

Nowadays, we often discuss the importance of protecting our systems from malware and sophisticated attacks. We install antivirus software, configure firewalls, and maintain vigilant security practices. But what happens when the attack vector isn’t a malicious file or a network exploit, but rather a legitimate browser feature you’ve been trusting?

This is precisely the threat posed by a new command-and-control platform called Matrix Push C2. This browser-native, fileless framework leverages push notifications, fake alerts, and link redirects to target victims. The entire attack occurs through your web browser, without first infecting your system through traditional means.

In this article, we will explore the architecture of browser-based attacks and investigate how Matrix Push C2 weaponizes it. Let’s get rolling!

The Anatomy of a Browser-Based Attack

Matrix Push C2 abuses the web push notification system, a legitimate browser feature that websites use to send updates and alerts to users who have opted in. Attackers first trick users into allowing browser notifications through social engineering on malicious or compromised websites.

Once a user subscribes to the attacker’s notifications, the attacker can push out fake error messages or security alerts at will that look scarily real. These messages appear as if they are from the operating system or trusted software, complete with official-sounding titles and icons.

The fake alerts might warn about suspicious logins to your accounts, claim that your browser needs an urgent security update, or suggest that your system has been compromised and requires immediate action. Each notification includes a convenient “Verify” or “Update” button that, when clicked, takes the victim to a bogus site controlled by the attackers. This site might be a phishing page designed to steal credentials, or it might attempt to trick you into downloading actual malware onto your system. Because this whole interaction is happening through the browser’s notification system, no traditional malware file needs to be present on the system initially. It’s a fileless technique that operates entirely within the trusted confines of your web browser.

Inside the Attacker’s Command Center

Matrix Push C2 is offered as a malware-as-a-service kit to other threat actors, sold directly through crimeware channels, typically via Telegram and cybercrime forums. The pricing structure follows a tiered subscription model that makes it accessible to criminals at various levels of sophistication. According to BlackFog company, the Matrix Push C2 costs approximately $150 for one month, $405 for three months, $765 for six months, and $1,500 for a full year. Payments are accepted in cryptocurrency, and buyers communicate directly with the operator for access.

From the attacker’s perspective, the interface is intuitive. The campaign dashboard displays metrics like total clients, delivery success rates, and notification interaction statistics.

As soon as a browser is enlisted by accepting the push notification subscription, it reports data back to the command-and-control server.

Matrix Push C2 can detect the presence of browser extensions, including cryptocurrency wallets like MetaMask, identify the device type and operating system, and track user interactions with notifications. Essentially, as soon as the victim permits the notifications, the attacker gains a telemetry feed from that browser session.

Social Engineering at Scale

The core of the attack is social engineering, and Matrix Push C2 comes loaded with configurable templates to maximize the credibility of its fake messages. Attackers can easily theme their phishing notifications and landing pages to impersonate well-known companies and services. The platform includes pre-built templates for brands such as MetaMask, Netflix, Cloudflare, PayPal, and TikTok, each designed to look like a legitimate notification or security page from those providers.

Because these notifications appear in the official notification area of the device, users may assume their own system or applications generated the alert.

Defending Against Browser-Based Command and Control

As cyberwarriors, we must adapt our defensive strategies to account for this new attack vector. The first line of defense is user education and awareness. Users need to understand that browser notification permission requests should be treated with the same skepticism as requests to download and run executable files. Just because a website asks for notification permissions doesn’t mean you should grant them. In fact, most legitimate websites function perfectly well without push notifications, and the feature is often more of an annoyance than a benefit. If you believe that your team needs to update their skills for current and upcoming threats, consider our recently published Security Awareness and Risk Management training.

Beyond user awareness, technical controls can help mitigate this threat. Browser policies in enterprise environments can be configured to block notification permissions by default or to whitelist only approved sites. Network security tools can monitor for connections to known malicious notification services or suspicious URL shortening domains.

Summary

The fileless, cross-platform nature of this attack makes it particularly dangerous and difficult to detect using traditional security tools. However, by combining user awareness, proper browser configuration, and anti-data exfiltration technology, we can defend against this threat.

In this article, we briefly explored how Matrix Push C2 operates, and it’s a first step in protecting yourself and your organization from this emerging attack vector.

Welcome back, my aspiring cyberwarriors!

Smart homes are increasingly becoming common in our digital world! These smart home devices have become of the key targets of malicious hackers. This is largely due to their very weak security. In 2025, attacks on connected devices rose 400 percent, with average breach costs hitting $5.4 million

In this three-day class, we will explore and analyze the various security weaknesses of these smart home devices and protocols.

Course Outline

1. Introduction and Overview of Smart Home Devices
2. Weak Authentication on Smart Home Devices
3. RFID and the Smart Home Security
4. Bluetooth and Bluetooth LE vulnerabilities in the home
5. Wi-Fi vulnerabilities and how they can be leveraged to takeover all the devices in the home
6. LoRa vulnerabilities
7. IP Camera vulnerabilities
8. Zigbee vulnerabilities
9. Jamming Wireless Technologies in the Smart Home
10. How attackers can pivot from an IoT devices in the home to takeover your phone or computer
11. How to Secure Your Smart Home

This course is part of our Subscriber Pro training package

Introduction:

Hello world of Hackers Arise, in this post, we delve into the complex world of Russian disinformation campaigns on the internet. As Master OTW clearly established in his interview with Yaniv Hoffman (watch the video below), the disinformation campaign carried out by the high-ranking Russian authorities is not something new. It has been developed for decades, and they have truly become extremely adept at it, especially now with the use of the internet and social media. Throughout the years, they have dedicated themselves to spreading hatred, envy, and resentment worldwide, which we could classify as Psychological Warfare Operations, but taken to the extreme, as they not only aim to misinform or influence to achieve specific strategic targets but also intend to divide and confront the entire world.

However, we do not say this capriciously; there are foundations and information that support our arguments, we also do not intend to hide or minimize the fact that all nation-states carry out this type of operations, but in the case of the Russian authorities, their intention redefines the concept of pure malevolence.

https://www.youtube.com/watch?v=t2P6iADGnpE

With the rise of social media and interconnected platforms, information dissemination has become a powerful tool for shaping public opinion. Russia, among other countries, has been at the forefront of exploiting these channels to advance its strategic goals. This article aims to shed light on the methods, motives, and implications of Russia’s disinformation campaigns while underlining the importance of critical thinking and media literacy in navigating the digital landscape.

 

Understanding Disinformation:

Disinformation is the dissemination of false or misleading information with the intention to deceive or manipulate the public. Russia has become notorious for employing sophisticated techniques to influence global narratives on a wide range of issues, from political events to social debates and international relations. Understanding the multifaceted nature of disinformation is crucial in recognizing and countering its effects.

The following link leads to a study whose key points I will list below with the aim of understanding the main characteristics of this type of operations carried out by the Russian authorities.

  – Russian Propaganda Is High-Volume and Multichannel– Russian Propaganda Is Rapid, Continuous, and Repetitive– Russian Propaganda Makes No Commitment to Objective Reality– Russian Propaganda Is Not Committed to Consistency 

Methods Used:

Russia employs an array of methods to propagate disinformation effectively. These include the use of bots and troll farms to flood social media with false narratives, the creation and distribution of deceptive content, and the manipulation of search engine algorithms to amplify biased information. By utilizing these methods, Russia can create an illusion of consensus and spread narratives that align with its geopolitical interests.

“The Russian Federation has engaged in a systematic, international campaign of disinformation, information manipulation and distortion of facts in order to enhance its strategy of destabilisation of its neighbouring countries, the EU and its member states. In particular, disinformation and information manipulationhas repeatedly and consistently targeted European political parties, especially during the election periods, civil society and Russian gender and ethnic minorities, asylum seekers and the functioning of democratic institutions in the EU and its member states.

In order to justify and support its military aggression of Ukraine, the Russian Federation has engaged in continuous and concerted disinformation and information manipulation actions targeted at the EU and neighbouring civil society members, gravely distorting and manipulating facts.” Source (Picture below)

 The mass media outlets mentioned above are either state-owned or corporations serving the state. However, Putin does not like independent journalism doing its job, and that’s why he took actions against them. Source Take a look at the amount of budget allocated by the Russian high command for those platforms to deploy disinformation.  

Motives Behind the Campaigns:

The motives driving Russia’s disinformation campaigns are diverse and can be linked to political, economic, and security-related goals. Destabilizing rival countries, sowing discord among allies, discrediting political opponents, and undermining democratic processes are some of the key objectives pursued through t
hese campaigns. Understanding these motives is essential in formulating an effective response.If you still don’t believe that they spread hate all over the internet, take a look at these myths whose explanations are debunked in the source we provided.

  And what about the Russian troll farm?  

Implications and Impact:

The impact of Russian disinformation campaigns is far-reaching. They can polarize societies, erode trust in democratic institutions, and exacerbate existing divisions within nations. In international affairs, disinformation can escalate tensions between countries and influence public opinion on foreign policy matters. Moreover, the erosion of trust in media sources can lead to a decline in accurate information and the rise of echo chambers. Russian officials and pro-Russian media capitalized on the fear and uncertainty caused by the COVID-19 pandemic, actively spreading conspiracy theories. Among these theories, they focused on false U.S. bio-weapon infrastructure claims. One notable example is an article published by New Eastern Outlook on 20th February, available in both Russian and English, alleging that the U.S. deployed a biological weapon against China.

  

Fighting Back:

Countering Russian disinformation requires a comprehensive approach. Governments, tech companies, and civil society must collaborate to identify and expose false narratives, invest in media literacy programs, and enhance cybersecurity measures to protect against information warfare. Educating the public on critical thinking and fact-checking is a powerful tool in combating the spread of disinformation, but it is also our responsibility as hackers and advocates of freedom within the cyberspace; we must make this responsibility our mission, our duty, to ensure free access to information.

 

Conclusion:

The internet has opened up new frontiers for information dissemination, but it has also become fertile ground for disinformation campaigns. Russia’s approach to shaping narratives on a global scale requires a vigilant and proactive response from the international community. By fostering media literacy and promoting responsible online behavior, we can safeguard the integrity of information and fortify our societies against the perils of disinformation.

Smouk out!

 

Welcome back, aspiring cyberwarriors!

In the world of penetration testing and red team operations, one of the most critical moments comes after you’ve successfully exploited a target system. You’ve gained initial access, but now you’re stuck with a basic, unstable shell that could drop at any moment. You need to upgrade that shell, manage multiple connections, and maintain persistence without losing your hard-won access.

Traditional methods of shell management are fragmented and inefficient. You might use netcat for catching shells, then manually upgrade them with Python or script commands, manage them in separate terminal windows, and hope you don’t lose track of which shell connects to which target. Or you can use Penelope to handle all those things.

Penelope is a shell handler designed specifically for hackers who demand more from their post-exploitation toolkit. Unlike basic listeners like netcat, Penelope automatically upgrades shells to fully interactive TTYs, manages multiple sessions simultaneously, and provides a centralized interface for controlling all your compromised systems.

In this article, we will install Penelope and explore its core features. Let’s get rolling!

Step #1: Download and Install Penelope

In this tutorial, I will be installing Penelope on my Raspberry Pi 4, but the tool works equally well on any Linux distribution or MacOS system with Python 3.6 or higher installed. The installation process is straightforward since Penelope is a Python script

First, navigate to the GitHub repository and clone the project to your system:
pi> git clone https://github.com/brightio/penelope.git

pi> cd penelope

Once the downloading completes, you can verify that Penelope is ready to use by checking its help menu:

pi> python3 penelope.py -h

You should see a comprehensive help menu displaying all of Penelope’s options and capabilities. This confirms that the tool is properly installed and ready for use.

Step #2: Starting a Basic Listener

The most fundamental use case for Penelope is catching reverse shells from compromised targets. Unlike netcat, which simply listens on a port and displays whatever connects, Penelope manages the incoming connection and prepares it for interactive use.

To start a basic listener on port 4444, execute the following command:

pi> python3 penelope.py

Penelope will start listening on the default port and display a status message indicating it’s ready to receive connections.

Now let’s simulate a compromised target connecting back to your listener.

You should see Penelope display information about the new session, including an assigned session ID, the target’s IP address, and the detected operating system. The shell is automatically upgraded to a fully interactive TTY, meaning you now have tab completion, the ability to use text editors like Vim, and proper handling of special characters.

Step #3: Managing Multiple Sessions

Let’s simulate managing multiple targets. In the current session, click F12 to open a menu. There, you can type help for exploring available options.

We’re interested in adding a new listener, so the command will be:

panelope> listeners add -p <port>

Each time a new target connects, Penelope assigns it a unique session ID and adds it to your session list.

To view all active sessions, use the sessions command within Penelope:

penelope > sessions

This displays a table showing all connected targets with their session IDs, IP addresses and operating systems.

To interact with a specific session, use the session ID. For example, to switch to session 2:

penelope > interact 2

Step #4: Uploading and Downloading Files

File transfer is a constant requirement during penetration testing engagements. You need to upload exploitation tools, download sensitive data, and move files between your attack system and compromised targets. Penelope includes built-in file transfer capabilities that work regardless of what tools are available on the target system.

To upload a file from your attacking system to the target, use the upload command. Let’s say you want to upload a Python script called script.py to the target:

penelope > upload /home/air/Tools/script.py

Downloading files from the target works similarly. Suppose you’ve discovered a sensitive configuration file on the compromised system that you need to exfiltrate:

penelope > download /etc/passwd

Summary

Traditional tools like netcat provide basic listening capabilities but leave you manually managing shell upgrades, juggling terminal windows, and struggling to maintain organized control over your compromised infrastructure. Penelope solves these problems. It provides the control and organization you need to work efficiently and maintain access to your hard-won, compromised systems.

The tool’s automatic upgrade capabilities, multi-session management, built-in file transfer, and session persistence features make it a valuable go-to solution for cyberwarriors. Keep an eye on it—it may find a place in your hacking toolbox.

Welcome back, my aspiring digital investigators!

In the rapidly evolving landscape of open source intelligence, Twitter (now rebranded as X) has long been considered one of the most valuable platforms for gathering real-time information, tracking social movements, and conducting digital investigations. However, the platform’s transformation under Elon Musk’s ownership has fundamentally altered the OSINT landscape, creating unprecedented challenges for investigators who previously relied on third-party tools and API access to conduct their research.

The golden age of Twitter OSINT tools has effectively ended. Applications like Twint, GetOldTweets3, and countless browser extensions that once provided investigators with powerful capabilities to search historical tweets, analyze user networks, and extract metadata have been rendered largely useless by the platform’s new API restrictions and authentication requirements. What was once a treasure trove of accessible data has become a walled garden, forcing OSINT practitioners to adapt their methodologies and embrace more sophisticated, indirect approaches to intelligence gathering.

This fundamental shift represents both a challenge and an opportunity for serious digital investigators. While the days of easily scraping massive datasets are behind us, the platform still contains an enormous wealth of information for those who understand how to access it through alternative means. The key lies in understanding that modern Twitter OSINT is no longer about brute-force data collection, but rather about strategic, targeted analysis using techniques that work within the platform’s new constraints.

Understanding the New Twitter Landscape

The platform’s new monetization model has created distinct user classes with different capabilities and visibility levels. Verified subscribers enjoy enhanced reach, longer post limits, and priority placement in replies and search results. This has created a new dynamic where information from paid accounts often receives more visibility than content from free users, regardless of its accuracy or relevance. For OSINT practitioners, this means understanding these algorithmic biases is essential for comprehensive intelligence gathering.

The removal of legacy verification badges and the introduction of paid verification has also complicated the process of source verification. Previously, blue checkmarks provided a reliable indicator of account authenticity for public figures, journalists, and organizations. Now, anyone willing to pay can obtain verification, making it necessary to develop new methods for assessing source credibility and authenticity.

Content moderation policies have also evolved significantly, with changes in enforcement priorities and community guidelines affecting what information remains visible and accessible. Some previously available content has been removed or restricted, while other types of content that were previously moderated are now more readily accessible. Also, the company updated its terms of service to officially say it uses public tweets to train its AI.

Search Operators

The foundation of effective Twitter OSINT lies in knowing how to craft precise search queries using X’s advanced search operators. These operators allow you to filter and target specific information with remarkable precision.

You can access the advanced search interface through the web version of X, but knowing the operators allows you to craft complex queries directly in the search bar.

Here are some of the most valuable search operators for OSINT purposes:

from:username – Shows tweets only from a specific user

to:username – Shows tweets directed at a specific user

since:YYYY-MM-DD – Shows tweets after a specific date

until:YYYY-MM-DD – Shows tweets before a specific date

near:location within:miles – Shows tweets near a location

filter:links – Shows only tweets containing links

filter:media – Shows only tweets containing media

filter:images – Shows only tweets containing images

filter:videos – Shows only tweets containing videos

filter:verified – Shows only tweets from verified accounts

-filter:replies – Excludes replies from search results

#hashtag – Shows tweets containing a specific hashtag

"exact phrase" – Shows tweets containing an exact phrase

For example, to find tweets from a specific user about cybersecurity posted in the first half of 2025, you could use:

from:username cybersecurity since:2024-01-01 until:2024-06-30

The power of these operators becomes apparent when you combine them. For instance, to find tweets containing images posted near a specific location during a particular event:

near:Moscow within:5mi filter:images since:2023-04-15 until:2024-04-16 drone

This would help you find images shared on X during the drone attack on Moscow.

Profile Analysis and Behavioral Intelligence

Every Twitter account leaves digital fingerprints that tell a story far beyond what users intend to reveal.

The Account Creation Time Signature

Account creation patterns often expose coordinated operations with startling precision. During investigation of a corporate disinformation campaign, researchers discovered 23 accounts created within a 48-hour window in March 2023—all targeting the same pharmaceutical company. The accounts had been carefully aged for six months before activation, but their synchronized birth dates revealed centralized creation despite using different IP addresses and varied profile information.

Username Evolution Archaeology: A cybersecurity firm tracking ransomware operators found that a key player had changed usernames 14 times over two years, but each transition left traces. By documenting the evolution @crypto_expert → @blockchain_dev → @security_researcher → @threat_analyst, investigators revealed the account operator’s attempt to build credibility in different communities while maintaining the same underlying network connections.

Visual Identity Intelligence: Profile image analysis has become remarkably sophisticated. When investigating a suspected foreign influence operation, researchers used reverse image searches to discover that 8 different accounts were using professional headshots from the same stock photography session—but cropped differently to appear unrelated. The original stock photo metadata revealed it was purchased from a server in Eastern Europe, contradicting the accounts’ claims of U.S. residence.

Temporal Behavioral Fingerprinting

Human posting patterns are as unique as fingerprints, and investigators have developed techniques to extract extraordinary intelligence from timing data alone.

Geographic Time Zone Contradictions: Researchers tracking international cybercriminal networks identified coordination patterns across supposedly unrelated accounts. Five accounts claiming to operate from different U.S. cities all showed posting patterns consistent with Central European Time, despite using location-appropriate slang and cultural references. Further analysis revealed they were posting during European business hours while American accounts typically show evening and weekend activity.

Automation Detection Through Micro-Timing: A social media manipulation investigation used precise timestamp analysis to identify bot behavior. Suspected accounts were posting with unusual regularity—exactly every 3 hours and 17 minutes for weeks. Human posting shows natural variation, but these accounts demonstrated algorithmic precision that revealed automated management despite otherwise convincing content.

Network Archaeology and Relationship Intelligence

Twitter’s social graph remains one of its most valuable intelligence sources, requiring investigators to become expert relationship analysts.

The Early Follower Principle: When investigating anonymous accounts involved in political manipulation, researchers focus on the first 50 followers. These early connections often reveal real identities or organizational affiliations before operators realize they need operational security. In one case, an anonymous political attack account’s early followers included three employees from the same PR firm, revealing the operation’s true source.

Mutual Connection Pattern Analysis: Intelligence analysts investigating foreign interference discovered sophisticated relationship mapping. Suspected accounts showed carefully constructed following patterns—they followed legitimate journalists, activists, and political figures to appear authentic, but also maintained subtle connections to each other through shared follows of obscure accounts that served as coordination signals.

Reply Chain Forensics: A financial fraud investigation revealed coordination through reply pattern analysis. Seven accounts engaged in artificial conversation chains to boost specific investment content. While the conversations appeared natural, timing analysis showed responses occurred within 30-45 seconds consistently—far faster than natural reading and response times for the complex financial content being discussed.

Systematic Documentation and Intelligence Development

The most successful profile analysis investigations employ systematic documentation techniques that build comprehensive intelligence over time rather than relying on single-point assessments.

Behavioral Baseline Establishment: Investigators spend 2-4 weeks establishing normal behavioral patterns before conducting anomaly analysis. This baseline includes posting frequency, engagement patterns, topic preferences, language usage, and network interaction patterns. Deviations from established baselines indicate potential significant developments.

Multi-Vector Correlation Analysis: Advanced investigations combine temporal, linguistic, network, and content analysis to build confidence levels in conclusions. Single indicators might suggest possibilities, but convergent evidence from multiple analysis vectors provides actionable intelligence confidence levels above 85%.

Summary

Predictive Behavior Modeling: The most sophisticated investigators use historical pattern analysis to predict likely future behaviors and optimal monitoring strategies. Understanding individual behavioral patterns enables investigators to anticipate when targets are most likely to post valuable intelligence or engage in significant activities.

Modern Twitter OSINT now requires investigators to develop cross-platform correlation skills and collaborative intelligence gathering approaches. While the technical barriers have increased significantly, the platform remains valuable for those who understand how to leverage remaining accessible features through creative, systematic investigation techniques.

To improve your OSINT skills, check out our OSINT Investigator Bundle. You’ll explore both fundamental and advanced techniques and receive an OSINT Certified Investigator Voucher.