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 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.