Hack w/ Me Episode 3: Linux Basics + VMs

Intro

Sup folks, my last completed module was about the basics of Linux, so that’s what this episode will be about. However, I’ll be covering a bit more than we covered in the module. Within TryHackMe, we covered basic commands, working with the filesystem, shell operations, flags & switches, and automation, to name a few. But what I also want to cover is how to get a Virtual Machine booted up using “Kali Linux”, which is a Linux distribution designed for digital forensics and penetration testing. That will involve us getting familiar with UTM, a full-featured system emulator and virtual machine host for iOS and macOS (sorry, Windows users, it might not be a 1:1 comparison on how to start the VM locally). We’ll also go through the entire process of installation of the distribution and even try our hand at a fun lil script 😏.

Before we get into the hands-on sections of this episode, let’s go over some Linux basics.

Lil Linux Lore

The name "Linux" is actually an umbrella term for multiple OS's that are based on UNIX (another operating system). Thanks to Linux being open-source, variants of Linux come in all shapes and sizes - suited best for what the system is being used for.

For example, Ubuntu & Debian are some of the more commonplace distributions of Linux because they are so extensible. For example, you can run Ubuntu as a server (such as websites & web applications) or as a fully-fledged desktop. While the TryHackMe module uses Ubuntu, when we are setting up our own VM, we will be using Debian, since that’s what Kali Linux is based on. When it comes to the commands and execution, though, both distributions should function very similarly.

"Linux" is often used to refer to the entire operating system, but in reality, Linux is the operating system kernel, which is started by the boot loader, which is itself started by the “Basic Input/Output System”/”Unified Extensible Firmware Interface” (BIOS/UEFI). The kernel assumes a role similar to that of a conductor in an orchestra—it ensures coordination between hardware and software. And no, I did not come up with that analogy myself lol. But enough of the technical jargon, let's get our VMS set up, then dive into some basics.

Setting Up Your VM

There are a handful of steps to properly set up both of the VMs we will be using in this episode, so I created a quick video to help walk through each step of the process while notating some of the known bugs when it comes to getting the “Kali Linux” VM set up.

Quick Setup Summary

UTM

* We will need UTM as our emulator. Download and install it →

https://mac.getutm.app

Kali

* Download the ISO image from their site → https://www.kali.org/get-kali/#kali-installer-images. Make sure you are downloading the right image for the architecture you’re on.

* Follow their official guide once you have it downloaded → https://www.kali.org/docs/virtualization/install-utm-guest-vm/

ParrotOS

* Download the pre-configured UTM from ParrotOS - Home → https://www.parrotsec.org/download/

* Follow their official installation guide → https://www.parrotsec.org/docs/virtualization/utm-configuration

Once you have both of these VMs installed, we are ready for action!

The Basics

Commands

Now, when it comes to commands, if you are familiar with macOS terminal commands, you should feel at home with Linux. Apple’s macOS is based on UNIX as well, so a lot of the commands for filesystem management, shell commands, and shortcuts should be identical.

Let’s start with the very basic command echo. echo will output any text that we provide. Check out this screenshot below. You can see the simple command input and the output.

There are various use cases for using echo from debugging to getting environment variables in a safe manner, and we will for sure be using some of them throughout this series.

Another basic command is whoami to find out what user we're currently logged in as. That’s the only function there, lol, a one-and-done command.

You can see in the screenshot above that I’m logged in as “mortaniel”.

Next we have pwd which stands for “print working directory”, and this just prints out where you are currently in your filesystem within your terminal.

The ls command prints out the contents of the directory you’re in.

The last command I wanna mention here is cd, which lets you navigate into certain directories. Below you can see me navigate into “Desktop” and I used ls to list out the contents on my VM’s desktop, which is just a custom folder named “Best Folder”.

There are TONS of other commands available to use, and we’d be here all day if I tried listing them out with their use cases. For instance, the find command is very useful and worth covering; I just have to spare the time to fit everything under an hour. It would be extremely boring too 😂, and besides, there are going to be commands I use later in this episode and will provide a quick definition of what it is when I reference/use them. So let’s move on to the next section, where I want to discuss SSH.

Secure Shell: Operations & Deploy

Secure Shell (SSH) is the common means of connecting to and interacting with the command line of a remote Linux machine. In TryHackMe, we deploy two machines:

* The Linux machine

* The TryHackMe AttackBox

Where we go over common shell operations as well as how to use it to remotely log into the Linux Machine. So, what we’ll do is create 2 VMs locally to emulate what we’re doing in TryHackMe (or at least as close as possible). The main VM we will make should be a standard setup in terms of memory and storage allocation. This will be our “Attack Box”, and it will be using Kali Linux. The second VM we create will be our “Target Linux Machine”, and I’ll use ParrotOS for this one, to change it up a bit. You are more than welcome to use 2 Kali Linux VMs. Ubuntu, being the 2nd VM, is ideal if you can get it set up, but I’m having compatibility issues that I don’t feel like resolving, so I'm stuck with 2 different Debian-based distros. I’ll walk through how to set both up a bit later on, but our Attack Box will be where we get to test out some of these shell commands. I’m also going to walk through a cool and simple exploit to give an idea of what’s capable in the world of pen testing.

A few of those operations are as follows:

* &: This operator allows you to run commands in the background of your terminal.

* &&: This operator allows you to combine multiple commands together in one line of your terminal.

* >: This operator is a redirector - meaning that we can take the output from a command (such as using cat to output a file) and direct it elsewhere.

* >>: This operator does the same function of the > operator but appends the output rather than replacing (meaning nothing is overwritten).

If we want to get into more details on each operator:

Operator “&”

This operator allows us to execute commands in the background. For example, let’s say we want to copy a large file. This will obviously take quite a long time and will leave us unable to do anything else until the file is successfully copied.

The “&” shell operator allows us to execute a command and have it run in the background (such as this file copy), allowing us to do other things!

Operator “&&”

This shell operator is a bit misleading in the sense of how familiar is to its partner “&”. Unlike the “&” operator, we can use “&&” to make a list of commands to run for example command1 && command2. However, it’s worth noting that command2 will only run if command1 was successful.

Operator “>”

This operator is what’s known as an output redirector. What this essentially means is that we take the output from a command we run and send that output to somewhere else.

A great example of this is redirecting the output of the echo command that we learned in Task 4. Of course, running something such as echo wordsILoveToSay will return “wordsILoveToSay” back to our terminal — that isn’t super useful. What we can do instead is redirect “wordsILoveToSay” to something such as a new file!

Let’s say we wanted to create a file, and I’ll name it newFile with the message “sup”. We can run echo sup > newFile where we want the file created with the contents “sup” like so:

Now I personally don’t see much use of this other than allowing users to save command results directly to a file for later but I feel that’s something you’d just work on in whatever file you are writing code in. I could be missing the nice use case and maybe it’ll come to me in practice. That leads us to the “>>” operator.

Operator “>>”

This is pretty much an extension of the previous command. But instead of creating or replacing an entire file with the new command, this operator appends the output.

These are just very basic Linux commands, and I’m sure I’ll find more use for them the more I dabble. There is a lot more basic knowledge that I feel is useful but to go into detail on each one would make this a very long episode. So in the next section, im just going to list the command, give a quick definition, and show an example screenshot if applicable.

The File System

Navigating the file system is extremely important, but can be summed up clearly, in which your file system is like your playing field in an RPG, table top, or digital. In that RPG’s playing field/world (the filesystem), there are many paths that you can take once you leave home (different paths like /Home/Desktop/Pictures & /Home/Downloads/cool_img.jpg). But you can always come back home and even further, go back to your root(s)…aka /~. I haven’t seen anyone make a similar analogy, so I’m gonna call dibs on that until further notice 😏. But you want to be able to navigate your file system(s) effortlessly, because sometimes time is not on your side when trying to execute an exploit or defend yourself from one.

Terminal Text Editor

If you’re a command-line wizard, you’d probably want to do everything in one location, including code updates. Well, there’s a way for you to do just that by accessing a code editor in your terminal window with Nano or VIM

Nano (GNU nano) is a text editor for Unix-like computing systems or operating environments using a command line interface that emulates the Pico text editor. It can be initialized with nano {fileName}. For example lets say in the “Best Folder” I created on my Kali Linux VM, I wanted to create a new file with text and then make a longer edit to the file. Instead of doing a bunch of ”>>” operations, we can just open up the file and make the full text change as needed. Quick little video of me doing just that:

This is an oversimplification of Nano’s use, but you get the picture of the capabilities.

VIM is a much more advanced text editor. Some of VIM’s benefits, albeit taking a much longer time to become familiar with, include:

* Customisable - you can modify the keyboard shortcuts to be of your choosing

* Syntax Highlighting - this is useful if you are writing or maintaining code, making it a popular choice for software developers

* VIM works on all terminals where nano may not be installed

* There are a lot of resources, such as cheatsheets, tutorials, and the like, available to use.

VIM, however, needs to be installed on your OS if it isn’t already from your distro you installed (in my case, it was). So, below is another quick video of how to get this installed, and I will make another edit to the file we altered using Nano.

This video has a bit of rambling and is NOT shorter than the one for Nano 😅. But after understanding the basics of Nano and VIM, you are well on your way to becoming a command-line hero.

General Utilities

There are a handful of general utilities at our disposal, but I want to make sure I cover downloading files, secure copy transfers, and serving files from a separate server.

Secure Copy (SCP)

Secure copy is as it seems, a means of securely copying files. Working with it requires only a SOURCE and a DESTINATION. Unlike the regular cp command, this command allows you to transfer files between two computers using the SSH protocol to provide both authentication and encryption. It goes 2 ways, you can:

* Copy files & directories from your current system to a remote system

* Copy files & directories from a remote system to your current system

Provided that we know usernames and passwords for a user on your current system and a user on the remote system. For example, let's copy an example file from our machine to a remote machine, which I pulled from TryHackMe:

With this information, we can craft our scp command (remembering that the format of SCP is just SOURCE and DESTINATION):

scp important.txt ubuntu@192.168.1.30:/home/ubuntu/transferred.txt

And now let's reverse this and layout the syntax for using scp to copy a file from a remote computer that we're not logged into

The command will now look like the following:

scp ubuntu@192.168.1.30:/home/ubuntu/documents.txt notes.txt

Downloading and serving files

To cover these 2, I made another video clip walking through how to accomplish this.

I highly recommend watching the video clip so you can see this in action, but to sum it up how TryHackMe has it:

Downloading Files (Wget)

The wget command allows us to download files from the web via HTTP -- as if you were accessing the file in your browser. We simply need to provide the address of the resource that we wish to download. For example, if I wanted to download a file named "myfile.txt" onto my machine, assuming I knew the web address, it would look something like this:

wget https://assets.tryhackme.com/additional/linux-fundamentals/part3/myfile.txt

In my video example, I show you how to do this between two VMs.

Serving Files

Ubuntu machines come pre-packaged with python3. Python helpfully provides a lightweight and easy-to-use module called "HTTPServer". This module turns your computer into a quick and easy web server that you can use to serve your own files, where they can then be downloaded by another computer using commands such as curl and wget. In my example video, we create a new server in my ParrotOS VM using the command python3 -m http.server within the directory where the target file lives, and once that’s running in your Linux machine, you’d run the following command → wget http://:8000/myfile.txt. You can get the IP on whatever machine you’re working with by using ip a. That command will print out something like this:

The IP address we want to look for is the inet value on ether, which is 192.168.64.2. So if I were to use this IP in the command from before, it would look like

wget http://192.168.64.2:8000/myfile.txt.

Sometimes you won't have access to make a GET request to servers you don’t have permission to access. But this leads us to understanding our local permissions

Permissions 101

The great thing about Linux is that permissions can be so granular that, whilst a user technically owns a file, if the permissions have been set, then a group of users can also have either the same or a different set of permissions to the exact same file without affecting the file owner itself.

Let’s put this into a real-world context; the system user that runs a web server must have permissions to read and write files for an effective web application. However, companies such as web hosting companies will have to want to allow their customers to upload their own files for their website without being the web server system user -- compromising the security of every other customer. Below is an overview of the types of permissions:

r - Permission to read. This grants permission only to open and view a file.

w - Permission to write. This grants permission only to view and edit a file.

x - Permission to execute. This allows users to execute a file (but not necessarily view or edit it).

To move ownership of a file to a different user so that they can control permissions, we can use the chown (change owner) command. For example:

chown ringo /tmp/coolFile

Similarly, you can change ownership from one group to another by using chgrp (change group). In this case, we want to give the security team access to a recently downloaded defensive tool, IDS (intrusion detection system). You would run a command like this:

chgrp securityGroup newIDS

This comes in handy if you are working with a team of pentesters, but the defensive/security team only needs full access to certain tools.

Switching between users on Linux is easy thanks to the su command. Unless you are the root user (or using root permissions through sudo), then you are required to know two things to facilitate this transition of user accounts:

* The user we wish to switch to

* The user’s password

The su command takes a couple of switches that I think are relevant to this explanation, but definitely check out the manual page for su to find out more. I’m just gonna cover the -l switch.

By providing the -l switch to su, we start a shell that is much more similar to the actual user logging into the system - we inherit a lot more properties of the new user, like environment variables and such.

For example, in the screenshot below, you can see the use of the -l switch and an instance without it.

When using su to switch to "ringo", our new session drops us into our previous user's home directory. Whereas, after using -l, our new session has dropped us into the home directory of "ringo" automatically.

Now let’s get back to the permissions. As noted before, every file and directory has a set of permissions that control who can read, write, or execute it. These permissions are often displayed in symbolic format, such as:

rwxrwxrwx

I find it easier to read as rwx|rwx|rwx. This format is split into three groups:

Each permission has a numeric value:

To calculate the numeric value, we add the values together for each group.

Some common examples are:

Understanding numeric permissions is important because:

* Many Linux commands use numeric values

* You can quickly identify security risks

* You can control who can access sensitive files

For example, we’d use the chmod (change mode) command followed by the numeric permission setting and then end it with the target file or directory, like so:

chmod 750 system_overview.txt

This means for system_overview.txt:

* Owner: full access

* Group: read + execute

* Others: no access

I highly recommend getting familiar with reading, granting, and removing permissions and their numeric format. Still trips me up a bit, but I’m sure over time, I’ll get very accustomed to reading it easily. The last major thing I wanted to discuss was automation.

Automation and the Cron Process

Users may want to schedule a certain action or task to take place after the system has booted. Take, for example, running commands, backing up files, or launching your favourite programs on, such as Spotify or Google Chrome.

So I’ll be talking about the cron process, but more specifically, how we can interact with it via the use of crontabs . Crontab is one of the processes that is started during boot, which is responsible for facilitating and managing cron jobs.

A crontab is simply a special file with formatting that is recognised by the cron process to execute each line step-by-step. Crontabs require 6 specific values:

Let’s use the example of backing up files. You may wish to back up “mortaniel”’s “Documents” every 12 hours. We would use the following formatting:

0 */12 * * * cp -R /home/mortaniel/Documents /var/backups/

An interesting feature of crontabs is that they also support the wildcard or asterisk (*). If we do not wish to provide a value for that specific field. For example, we don’t care what month, day, or year it is executed -- only that it is executed every 12 hours, we simply place an asterisk.

This can be confusing to begin with, which is why there are some great resources, such as "Crontab Generator", that allows you to use a friendly application to generate your formatting for you, as well as the site "Cron Guru".

If you need to start cron, you simply run cron. Crontabs can be edited by using crontab -e, where you can select an editor (such as Nano) to edit your crontab. In my example below, I confirmed Cron was running, and I created a new cron job to write out a message in a text file every 2 min. That cron command is:

*/2 * * * * echo "🔔 Cron fired at $(date)" >> ~/Desktop/cron_demo.txt

An easy way to follow that cron job is to tail the file and watch it in your terminal

tail -f ~/Desktop/cron_demo.txt

Bash Scripting

Now let’s have a little fun, we’re gonna create a lil script that will just be a series of questions, inputs, and the final echo statement that combines the input into a sentence. That doesn’t sound exactly thrilling lol, but it will give you a general idea on how to create and execute scripts.

Scripts can be executed through many methods and languages. Most interpreted languages (Python, Bash, Ruby, etc.) just need the runtime installed, and then scripts for that language can be run directly from the terminal. Compiled languages (C, Go) need a build step first. The shebang line

#!/usr/bin/env python3

lets you run scripts directly as ./python_demo.py on Unix systems, after making them executable with chmod +x python_demo.py. The same thing goes for creating a shell/bash script, just slightly different syntax:

#!/bin/bash/

From here, we will then start to build out our script. Now I’ve built the same script in both Python and Shell, just so you can see different flavors of the same code.

Python

#!/usr/bin/env python3 # Second script # Multi line text name = input("State your name, playa.\n") fruit = input("What's your favorite fruit?\n") print(f"Welcome to the Vice City, {name}. We have the finest {fruit} in the country.")

Shell/Bash

#! /bin/bash/ # Second bash script # Multi line text echo "State your name, playa." read name echo "What's your favorite fruit?" read fruit echo "Welcome to the Vice City, $name. We have the finest $fruit in the country."

Here you can see the 2 different ways to prompt users a couple of questions, storing the answer in a variable, and then printing out the last sentence with the variables included. The main difference here is how Python stores variables and how Shell stores them. I’m not an expert on Shell, but from what I learned, the read command takes the user input and splits the string into fields, assigning each new word to an argument. If there are fewer variables than words, read stores the remaining terms into the final variable. The splitting behavior is more advanced, and typically, you will just be using 1 variable at a time.

When it comes to Python, it’s clearly much cleaner in terms of being readable from the jump. You see both the name and fruit variables followed by the “=” operator, which is a clear indication that whatever else follows will be assigned to that variable. In our case, the input() function follows the “=” operator, which tells us that there will be a prompt that a user will need to respond to. That input is then stored in the connected variables. Finally, we print out a full sentence with those variables included. One caveat is that with Python, to include variables inside of strings, we need to use F-strings. With f-strings (formatted string literals), you can directly embed variables and expressions inside strings using curly braces {}, and this was introduced in version 3.6 to make string formatting and interpolation easier.

Python remains the most versatile language for scripting and automation in ethical hacking, so any type of scripting or exploits I make in future entries will use Python only, unless a different language serves the exploit better. Below is a quick demo on both scripts and how they are executed in the terminal.

Conclusion

That about wraps it up for this episode. I’ve only scratched the surface of Linux basics, and there are a handful of other things to look into and get a better understanding of if you want to continue learning the basics:

* Flags & Switches

* Package management

* Logs

* Processes

I hope that this was very insightful for everyone and that I sparked some interest in folks to invest some time in getting to know Linux a bit deeper ✌🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

* 🦋 Bluesky

* 📸 Instagram

* ▶️ Youtube

* 💻 Github

* 👾 Discord