This time, I completed over 10 practical lab tasks on SSH tunnelling, Linux process management, and cron configurations. But more interestingly, I tackled a hands-on investigation scenario: role-playing as a Security Engineer identifying Indicators of Compromise (IOCs) on a compromised Linux host.

I have attempted to give a step-by-step breakdown of how I investigated, analysed, and remediated the threat.

Note: the PID changes when the lab unexpectedly closed after a connection failure. But the results and processes are pretty much the same.

Tracking the Resource (Cryptominer)

The first sign of host compromise is usually anomalous resource consumption.

Using top, I spotted process PID 527 taking up nearly 99% of system resources. To pull its path and generate a cryptographic hash for artefact tracking, I ran:

#locate full path of PID 

ps -p 527

# Hash the binary for incident logging

md5sum /path/to/cryptominer >> hash.txt 

Uncovering the Hidden Backdoor

Next, I needed to identify any active backdoors maintaining network access.

Using socket statistics (ss), I checked for listening ports:

ss -tulpn

This highlighted a suspicious Python process listening on port 10348. Piping ps aux to filter for Python processes revealed the hidden executable location in a temporary directory:

ps aux | grep "python3"

# Output path: /tmp/.junk/bbac0ed1

I hashed this executable and logged it alongside the cryptominer in hash.txt.

Tracing C2 Persistence via Process Trees

Finding the Command and Control (C2) IP address and its persistence vector proved to be the most critical phase.

The standard process lists weren't showing the full hierarchy, so I used the process tree forest view

ps -auxf or pstree -p 

This displayed the visual tree, revealing that both the backdoor and cryptominer were children of Parent Process ID (PPID) 311.

Inspecting Boot Persistence

While ss -tunp providing connection hints, it didn't reveal the source script establishing the C2 connection. Looking at my note, after several trials, I inspected /etc/rc.local :

cat /etc/rc.local 

The file contained a startup script utilising nc (Netcat) to initiate an outbound connection to the C2 server IP address on system boot.

Remediation and Lessons

With all IOCs documented, I began eradication and immediately hit two major roadblocks that taught me valuable operational lessons.

Lesson A: SIGTERM vs. SIGKILL

I initially attempted a graceful kill using kill -15 . In incident response, graceful terminations (SIGTERM) allow malware to catch the signal and potentially trigger backup scripts or hide artefacts. Switching to kill -9 (SIGKILL) instantly killed the execution threads without delay.

Lesson B: Deleting Files vs. Deleting Staging Directories

After killing the processes, I deleted the script files using rm -rf. However, my lab validation remained stuck at 75%.

After reviewing my methodology, I realised that while the malicious binaries were deleted, the hidden directory path (/tmp/.junk) remained. Executing a recursive removal on the entire directory path finalised the cleanup:

rm -rf /tmp/.junk

Result: 100% Remediation.

Final Thoughts

Completing this by relying on muscle memory and my little journal, I found that threat hunting on Linux requires more than just knowing basic commands. It demands an understanding of how processes interrelate, where persistence hides, and how to perform complete eradication. It was fun while it lasted. And I was happy I learnt something new.

I lived quite a sedentary life as a child. I would sit in a spot for hours and watch other kids play from afar. Their screams and meaningless laughter echoed to me what it means to be free and a child in a scary world. It was different for me. I could only stare and make meaning of their joy from a distance. To be near them, I would have to violate the order of things. I violate what appears to be the limits of what I can do or not do.

My mother is a disciplinarian. She grants me only the kind of access she thinks I need at those points in my life: sit here, don’t go there, you can eat this, don’t touch that. As I read on file permissions as an adult in cyberspace, I could only see it through the lens of my mother’s scolding.

In the world of cybersecurity, the same is implied. To grant everybody access to systems, especially to sensitive information, is a drive into unimaginable chaos. As a child too, my mother prohibited me from things she found sensitive, especially when she found them obscene or private.

I remember a time I sat to watch a Nollywood film with my parents. Nobody tells you to close your eyes or turn away when a romantic scene plays. It is the kind of programming that runs in a typical Nigerian home. Other times, I found that the drawer to my dad’s private documents is locked. My mom’s ATM card is completely wrapped in layers and layers of papers and clothes and tucked in a bag far away from our imagination. I would know after she grants me elevated access but again, by the next time, the bag or the ATM card is in a different galaxy. I mean, am I not your son? Even when she knows little about computers or systems, her Zero Trust needs to be learnt.

Somehow, in the larger sense, this gene is what I will carry into the world: trust no one. Even when a policeman in mufti once stopped me for a search operation, I doubted his credibility and neither did I grant him access to my bag. In school, you find these scattered permissions everywhere: there is your roommate’s locked bag of food stuff you don’t have access to even at the brink of grave hunger, the places as a student you can’t enter except you’re a staff, and the extent of what you can do within such an ecosystem based on your role. Just as my mother dictates the boundaries of our house, an operating system does the same based on who you are: your identity.

When you have access to your user account and not another’s, it is rooted on the basics of permission and built entirely on the security principles of confidentiality, integrity, availability, authentication, authorisation, and non-repudiation.

By these standards, file permissions is about giving access to the extent that access should be granted to a specific user or group. For instance, the privilege of a root user cannot be the same as that of a regular one, except in certain temporary instances. But the key logic is the same: grant users permission to what role is assigned to them.

First, there are three levels of permission:

• Read (r) grants access to view the contents of a file or list contents of a directory.

• Write (w) allows you to modify or delete a file. For directories, it allows you to create, rename or delete.

• Execute (x) means you can run a file as a program or script and does not explicitly make you view or edit it.

These permissions rwx come to life when you use the ls -l command to view who owns and has access to do what with a file. Importantly, there are some things you should first be familiar with before we go deeper into other commands. By using the ls -l command along with the filename or path, you might see this output:

$ ls -l newdirectory
drwxrwxr-x 2 michael dev 4096 Jul 8 14:30 newdirectory

The permission string for newdirectory, for instance, is drwxrwxr-x. You might notice that some files begin their permission with d, a hyphen -, or the letter l. Don’t panic. They are filetypes:

• d is a directory

• - is a regular file

• l refers to a symbolic link

Now, the rwx pairs are used to tell what permissions an owner, group, or others have to that file. If any of them lacks these permissions, you will see the hyphen (e.g., r-x), which means the user doesn't have the permission to write the file. The entire output that follows the use of the ls -l command will be:

1. The file type (d, l, or -)

2. Permission on the file for owner, groups, and others (rwxrwxr-x)

3. The number of links

4. The owner of the file

5. The size of the file in bytes

6. Date of file creation and last modified

7. Name of the file

With this, the door to the next step can be opened: how do we change ownership (chown) and permissions (chmod).

Granting Ownership

When I had admission to study mass communication in the University of Benin, it was as though I was leaving the world I was familiar with behind me. But then, I had with me my mother’s blue travelling bag. She had acquired it after her marriage to my dad. Now, it is mine. I would arrange my clothes and some books as I bid them goodbye to a future unknown. Even as I write this, I cannot but stare at it as it lay at the corner of my room.

It is how ownership is transferred in Linux, too. In Linux, both the ownership for individuals and groups can be changed with the chown and chgrp commands respectively.

For individual users, the syntax is straightforward:

chown [user] [path/to/file]
# Example:
chown leah /tmp/leah_file

While to change the ownership for a group, one uses the chgrp (change group) command:

chgrp [group name] [path/to/file]
# Example:
chgrp dev Snort 

Changing Permission

There are two methods to modify permissions: the numerical format and the alphabetical or symbolic format (UGO, i.e., user-group-others method).

The Numerical Format

To understand this, it is important to reiterate that computers only know 0s and 1s: off and on, allowed and denied. In the numerical format, permissions use a 3-bit binary system for each category. It uses the octal notation to represent the combination of Read, Write, and Execute permissions with a three-digit number for the owner, group, and others.

Here is what I mean by octal notation or numeral system: it is a base-8 number system that uses only digits from 0-7. In Linux, it is the maximum value you can achieve with a 3-bit binary combo. Let me give you a map as to how these digits fit into the binary and file permissions so you understand it as we go deeper:

By this mapping, 7 is the absolute highest digit in the octal system. So, you probably won’t see 8 or 9 as part of the standard chmod permission command. We can make this further unambiguous when each permission is assigned a specific numeric and binary value as shown below:

So how is this calculated, you may ask? Let me simplify: since the permissions use a 3-bit binary system for each category, to find the octal number, you add the values of the active permissions together. Here:

• rwx: 4 + 2 + 1 = 7 (Binary = 111)

• rw-: 4 + 2 + 0 = 6 (Binary = 110)

• r-x: 4 + 0 + 1 = 5 (Binary = 101)

• r--: 4 + 0 + 0 = 4 (Binary = 100)

In perspective, it means if I run a command like chmod 755 filename, you set permissions for the three distinct groups using the numerical format:

• First digit (7) represents the permission for the Owner of the file (4 + 2 + 1 = rwx)

• Second digit (5) is permission for the Group (4 + 0 + 1 = r-x)

• Third digit (5) defines the permissions for Others (4 + 0 + 1 = r-x)

If we assemble them, the permission strings applied by running chmod 755 will be rwxr-xr-x.

The Alphabetical Format (UGO)

Unlike the numerical pattern, this format is rather symbolic. In this method, three things come to mind:

• . removes permission

• + adds permission

• = sets permission

For instance, to remove the write permission of the owner from a file, the syntax will be:

chmod u-w filename

From my mother’s lens, it will be a change in the house rules. That is, if she suddenly says I can no longer watch TV because I stay up late and barely do my assignments, that is u-w (User minus Write/Access).

Note: For multiple permissions using the UGO method, do not add a space between them:

chmod u=rw,g+x filename

Secure Permissions In-depth

When you read OccupyTheWeb’s Linux Basics for Hackers, you are opened up to the depth by which security can go. Part of that depth is how to set more secure default permissions with the umask method.

For a beginner or non-tech professional, umask is like a filter in my mom’s kitchen. Based on how wide the opening is determines what is removed or retained. So if a system’s default permission is 666 for a file, a umask of 022 will strip away permissions we shouldn’t have, leaving us with a secure 644.

I remember when my sister tried to sneak my wristwatch for a party some time ago. But then, she couldn’t beat the instinct of my mother. My mum would ask questions like: Who owns that watch? Is he aware? If the answer to that is no, she becomes the umask: stripping away access until you're left with what you should have, backed by her voice: “Go and keep it,” “Remove it,” “Before I open my eyes…”

In another piece, I will attempt to discuss special permissions like the set user id (SUID), set group id (SGID), and sticky bits. If you followed up to this point, it is my hope that what you find technical is only applicable in the real world. Through the lens of my mother’s scolding, you can understand to an extent what file permissions are.

This nostalgia and curiosity converged as I stared "naked" at my Linux terminal, invoking the spirits of Christopher Okigbo and Gabriel Okara, ready to search inside the womb of the machine.

For anyone starting out in Linux and finally getting a chance to open the terminal after navigating the rudiments of installation and distributions, you will find yourself before a dark screen with a single, blinking prompt:

username@hostname:current_directory$

Let us deconstruct this silent gatekeeper:

• username: The current user profile logged into the session.

• @: The structural separator differentiating the user from the host machine.

• hostname: The network name assigned to the specific machine.

• current_directory: The exact location within the filesystem where you are currently working.

• $: The symbol indicating you are a standard, unprivileged user.

In Linux, a user with absolute, unmitigated privileges is called the root user. When you log in with these administrative powers, the symbol shifts dramatically to a #.

This text-only environment is called the Command-Line Interface (CLI), the Console, or the Terminal, synonymous with Windows’ Command Prompt (CMD). Unlike a Graphical User Interface (GUI), which relies on a point-and-click architecture with icons neatly laid out, the CLI gives you granular control of a operating system through pure, text-based instructions. It is this instruction that is required to navigate the void and conjure meaning out of a silent world.

Without the foundational vocabulary of Linux commands, you will stand like a writer before a library containing millions of scattered, unlabelled books. And while there might be vague clues scattered here and there, walking blindly through this chaos would take weeks. In Windows or macOS, a simple graphical search bar masks this friction. Linux, however, demands text-built commands to search for files based on indexed databases, strict path locations, or raw filesystem attributes.

While the architectural core of Linux still revolves around the classic Unix philosophy that "everything is a file," Linus Torvalds, the creator of Linux, famously refined this reality by stating that in Linux, "Everything is a stream of bytes." Let me explain.

To a computer, the universe consists entirely of 0s and 1s. These are bits (Binary Digits),the smallest imaginable units of data. To make sense of complex human concepts, like the integer 100 or the string "hello", the computer aggregates these bits into bytes (groups of 8 bits).

Character encoding standards, such as ASCII (American Standard Code for Information Interchange), map every human character to a unique decimal number. That decimal number is then converted into a sequence of 0s and 1s that the machine can process. For instance, using ASCII, the word "hello" breaks down into these decimal values:

$$\text{h} = 104, \quad \text{e} = 101, \quad \text{l} = 108, \quad \text{l} = 108, \quad \text{o} = 111$$

These decimals uniquely represent each letter before converting into binary for the hardware:

When Torvalds stated that "Everything is a stream of bytes," he was introducing a profound architectural minimalism. He stripped away the clunky, bureaucratic divisions of traditional computing. To the Linux kernel, there is no fundamental difference between a line of poetry, a keystroke on a physical keyboard, or a live alert hitting a firewalled SOC dashboard. They are all treated as a continuous, flowing ribbon of digital text.

Because the operating system treats everything as a stream, it becomes incredibly powerful. The exact same verbs we use to filter text when analyzing a manuscript can be deployed to dissect a massive wall of network logs. It is against this backdrop that our existence before the Linux terminal begins to find meaning.

Treat these commands not as syntax to be mindlessly crammed, but as active verbs aligned with your intent. Let them flow by the river of what you want to accomplish.

Finding Sherlock

I have always admired the Sherlock Holmes movie franchise. The twists, the puzzles, and the race to transform absolute chaos into something as structured and meaningful as a Beethoven symphony. Enola Holmes shares that same thrill, offering a beautiful palindrome for the experience of a Linux beginner: alone in a dark world.

The first step in Linux is knowing exactly where you stand in that vast world. Remember, the terminal is a dark room; every command you type is a flash of light that illuminates only what you have actively summoned to see.

Before we dive into these specific verbs, we must demystify two critical concepts: Executable files and the PATH variable.

First, executable files are your verbs. Unlike standard files (like a .txt file containing a poem draft) which hold data but cannot act on their own, an executable file contains a direct list of instructions telling the computer's processor to perform an action. In Windows, you recognize these as .exe files. In Linux, almost every command you type into your terminal, whether it is ls, grep, cat, or mkdir, is actually a tiny, self-contained executable program sitting in a directory tree hidden somewhere on your storage drive. When you invoke a command, you are running a software program.

To understand the PATH variable, you must see the Linux system as an immense archive of folders. If your system had to manually crawl through every single folder on your hard drive every single time you typed ls or pwd, the terminal would lag and freeze concomitantly.

To bypass this friction, the PATH environment variable acts as a built-in cheat sheet. It serves as a targeted directory map. The PATH variable is a strict, colon-separated list of specific directory routes, such as /bin, /usr/bin, or /sbin, where these executable commands find their permanent homes. When you type a command, the system checks the first folder on that list. If it is not there, it checks the second, then the third. If it finds it, it executes the program. If it exhausts the list without success, it spits out the classic error: "Command not found."

The System Search Verbs

1. pwd (Where Am I?)

As a beginner, I rely on the pwd (Print Working Directory) command to anchor myself. It acts as an immediate GPS map, telling you precisely where you are sitting in the virtual file tree. When you feel swallowed by the void, running pwd illuminates your exact coordinates.

2. ls (List the Surrounding World)

To see what files exist in your immediate vicinity, we deploy the ls (List) command. It becomes extraordinary when paired with operational flags. For instance, executing ls -l prints a detailed, long-form layout displaying visible files alongside their cryptographic permissions, ownership tags, exact file sizes, and modification timestamps.

But when your objective lies deep within the infrastructure beyond your current folder, finding your target requires moving from the fastest database tools to the most intensive filesystem scours.

3. which (Where is My Shortcut?)

Think of which as asking the system, "Which door do I open to find where this command actually lives?" It reads your system's PATH variable and returns the exact binary file path of the command you are typing.

When you invoke which cat, you are asking the terminal where that tool keeps its physical bones. The terminal blinks and points you directly to /usr/bin/cat.

Sometimes, the detective encounters a pseudonym. If you stand before a modern security distribution like Kali Linux and execute which grep, the terminal bounces back an unexpected line:

grep: aliased to grep --color=auto

Don’t panic. Linux handles command names much like a literary tradition handles pen names. The creators of the distribution have set an alias, a shortcut that automatically intercepts the command and appends a flag forcing the terminal to highlight search results in vivid color. Because the which command is a literal detective, it reports the alias first. To rip away the mask and force it to show the physical path beneath the nickname, pass it through the all matches flag:

which -a grep

Only then does the raw, underlying path reveal itself: /usr/bin/grep.

4. whereis (Give Me the Complete Archive File)

The whereis command goes a step further than which. It is the equivalent of walking up to a library desk and demanding the complete reference profile on a topic. When you use whereis, the system doesn't just look for the binary; it simultaneously returns the file location of the executable binary, the source code archives, and the system manual (man) pages associated with that command.

5. locate (Check the Old Card Catalogue)

The locate command allows you to query a built-in internal system database (mlocate.db) for near-instantaneous search results. However, there is a catch: because it reads from an indexed database rather than crawling the live filesystem, a file created five minutes ago will be completely invisible to it. The card catalog hasn't been updated yet.

To fix this and force the indexing clerk to update its records, you must manually trigger the database update process using administrative sovereignty:

sudo updatedb

The sudo prefix ("SuperUser Do") grants the command root privileges to scan the entire system, refreshing the index so that your subsequent locate queries land with absolute precision.

6. find (Kick Down the Doors and Search Every Corner)

As the name implies, find is the heavy artillery deployed for rigorous, intensive investigations. It does not rely on a pre-compiled database like locate. Instead, it initiates a live, real-time scour of the raw physical filesystem, analyzing blocks, permissions, names, sizes, and recent creation timestamps. It can locate a file minted mere seconds ago.

To harness the find command, you must master its structural syntax:

$$\text{find} \quad [\text{directory_to_search}] \quad [\text{options}] \quad [\text{expression}]$$

A tactical deployment of this command looks like this:

find . -type f -name Bisi

This tells the system to search the current directory (represented by the dot .) for a regular file (-type f) whose exact name matches (-name) Bisi. Furthermore, you can supercharge this search by leveraging wildcards (such as *, ?, or []) to hunt down partial matches or specific file extensions.

7. man (The Systems Tour Guide)

When the sheer volume of options and expressions feels overwhelming, the man (Manual) command becomes your ultimate compass. It serves as your system's built-in reference documentation. Running a simple syntax like man find or man grep pulls up a highly detailed roadmap explaining every hidden capability your tools possess.

The Rule of Thumb

Mastering Linux is fundamentally rooted in having a solid, unshakeable grasp of the basics. For me, this is how I measure growth: one command at a time, learning at my own pace, enjoying the spaces where curiosity keeps me alive.

The next time you stand naked before the blinking prompt of a Linux terminal, ask yourself two questions: “Where am I?” and “Where do I want to go?” As you navigate those answers, your actions will dictate your commands naturally.

When you sit down at the keyboard, keep these guiding principles close:

1. Be patient with the process. You do not need to memorize thirty commands in a single day. Let them flow from your actual analytical intent.

2. Verify your instruments. If you need to quickly check whether an application tool is properly installed and verify where it resides, run which or whereis.

3. Optimize your resources. If you need to instantly locate a standard file without lagging your machine's hardware with massive disk reads, rely on locate.

4. Deploy forensic precision. If you are conducting a rigorous investigation to hunt down a hidden, malicious, or recently altered system file, accept the processing time and unleash find.

Till next time, Linux, before your terminal I will stand.