hacking, mobile

It’s Finally Here!!! Intro To Android Security VM v2

In my previous post I described how I started working on v2 of Intro TO Android Security VM.

To view that post, click HERE.

Anyway, I can finally say… I AM DONE WITH THE VM!

What’s different between version 1.1.2 to version 2. Well… keep reading

In version 2 I added more dynamic analysis tools such as MARA, PIDCat, QARK. In the pentesting section, I added Metasploit. I also added MobSF (a one stop shop with dynamic scanning for android applications) in a docker container. In version 1.1.2 I tried to upgrade my python version to 3.7.5 and broke my Linux build (could not update the distro).

After speaking with Anant (owner/creator of @AndroidTamer) we decided to put MobSF into a docker container to keep it contained and not break our build.

I also created the virtual machine from a vagrant machine, as I realized with version 1, I severely underestimated the storage I needed to include all the programs I wanted. I also included insecure android apps to test in the Documents folder.

Interested in learning more – download/use the virtual machine at the following location:

SourceForge –> IntroAndroidSecurity download | SourceForge.net, click on External Link

Finally, make sure to read the README.md file as most issues can be solved in that file!

Hope everyone enjoy the virtual machine. If you have any questions or want to see an application added – let me know!

boot2root, hacking, web application security

@Vulnhub – Solving #Cofveve

Another day, another challenge.

In this post we’re going to solve the Cofveve virtual machine.

Let’s get started

After downloading the virtual machine and starting it we see the following:

Using the netdiscover command we can find the IP that the virtual machine is using

Going back to our attacking machine (I’m using the parrot virtual machine).

Doing an nmap scan with the command – nmap -sV <IP address from netdiscover command>, we see the following

There are three ports that are open – ssh, and two http ports.

When http ports are opened the next step is to try to do a recursive brute force attacks to find hidden directories.

We’re going to use two programs – dirb and gobuster.

Doing the dirb of port 80, we get:

Using gobuster we see:

We see that both of the programs did not return anything.

Let’s try to the following programs with the 31337 port, let’s start

We see five files – a robots.txt, and four hidden files (start with .)

The robots.txt gives information about sites that should not be crawled by the internet. This is useful as it will give us files or directories (folders) to review to get more information.

Going to the robots.txt we see:

Hmm, there are three directories that are disallowed. Let’s try to go to them.

Let’s start with taxes. When navigating there we see:

We found the first flag!

Going to the second directory .bashrc we see

Hmm, it’s a file, let’s save it.

Going to the last directory of .profile we see

Another file to save.

Going back to either dirb or gobuster results we have one more directory, .ssh.

This is strange. The .ssh which is hidden should not be exposed on the internet. This folder has information about how to login into the system. Such information is a private key (which only the user should know) public key (which everyone knows), as well as other things.

Going to this folder we see:

We see three items, which look like additional files.

Let’s see if we can navigate to these files.

Navigating to the first item, id_rsa we see:

Another file, so let’s save it.

Let’s try the second file – authorized_keys. Going there we see:

Another file, let’s save it.

Finally, let’s go to the third item – id_rsa.pub

Now that we saved everything let’s go back to our virtual machine and open the files.

First, let’s open the id_rsa.pub file. This file is the public key that is part of a pair. The other pair is the private key. As the name suggests only the user should know their private key and not expose it to anyone else. The public key can be exposed to everyone.

Opening the file we see:

We see a ssh-rsa. RSA is a cryptographic algorithm. Looking at the end of the file we see a valid user – simon@covfefe. We need to save this user as we will need it later.

Opening the id_rsa file we see:

This file is the private key to log into the SSH server as Simon! This is bad, as I said before this file should NOT be exposed as Simon private key should only be known by him only.

Opening the authorized_keys file it has the same content as the id_pub

How can we use this information?

We know a user (simon@covfefe) and a private key.

Well we can log into the ssh server.

Let’s start.

We can use the command ssh -i id_rsa simon@covfefe

Let’s break this down.

We’re logging into the SSH server, specifying a file id_rsa (Simon’s private key) and the user of Simon

We get the following output:

Uh oh – we received an error:

The private key is too open. We need to change the make it less accessible. To do this we’re going to change the permissions from 644 to 600. What this will do is give access to the owner in this case parrot (which is us).

To do this we will use the command chmod 600 id_rsa

Trying to log in again we have the following:

We need a passphrase… which we don’t have. How do we get this?

Doing a good ol’ Google search of cracking passphrase for id_rsa we see the following link

We see there’s a command ssh2john which can be used to crack the passphrase. Let’s do it!

First, we located where the ssh2john command lives in the file system. Next, we’re going to create a hash using ssh2john. We’re going to use this for the next step.

Next, we’re going to send our hash to john which will be used to crack it. We’re going to use the wordlist rockyou.txt which is a common wordlist used to crack passwords. Doing so, we found our passphrase – starwars.

Running our SSH command again, we enter the passphrase of starwars and we’re in the system!

Doing a long listing and showing all of the files (ls -la) we see the files we found before when brute forcing the directories. Let’s look at the .bash_history. This file is good to review as it will let you know commands that were executed on the machine.

Opening this file we see a read_message and then exit. What is read_message? Is this a program?

Executing the read_message we get a prompt. Let’s enter the name Simon. We received a message stating this is is a private messaging system and the source code is in the root directory.

Navigating to the root directory and doing a long listing with all the files (ls -la) we see there’s a read_message.c file, and flag.txt!

Opening the flag.txt file we see a permission denied :-(. Looking at the long listing again this file (flag.txt) can only be accessed the owner, which in this case is root (column 4). I am the user Simon, so I can’t view the file.

Opening the read_message.c file, we see source code, and… the second flag!

And it’s giving us a hint – we need to review the source code.

Looking at the source code we have a buffer (buf) that is holding 20 characters and is executing another file program which is pointing to /usr/local/sbin/message. Whenever we see buf we need to think of buffer overflows.

Buffer overflows are a vulnerability where you overflow the input to access other parts of the computer system. In this case, since we have a holding space of 20 characters – we’re going to overload the buffer with characters OVER 20 characters. Also we’re going to try to change the shell to /bin/sh <— bourne shell. We’re going to change the shell to escalate the user. Changing from Simon to root. We need to be root to open the flag.txt file.

Let’s try it.

Running the commands id and whoami we see we’re root!

Now let’s open the flag.txt and see what’s in the file.

We solved the challenge!

hacking, mobile

Get Excited! Version 2 of IntroToAndroidHacking Virtual Machine Is On The Way!

As the title suggests, I am working on the second version of the virtual machine I created in 2019.

I put myself out there and decided to create a training on Mobile Security and Bug Bounties – something I wanted to learn and am still interested in.

I noticed there was a virtual machine titled – Android Tamer, score! Well… not really. At the time, Android Tamer was SUPER out of date. Speaking with the creator, Anant Shrivastava about my dilemma needing a virtual machine for my training. Anant told me that it would be easier to create my own virtual machine as opposed to fixing the current version of Android Tamer.

Creating my own virtual machine? I’ve never done that before. Challenge accepted!

Anant, was SUPER helpful with all of my questions and guided me on creating the virtual machine. In about a month the first version was created. Yay!

After the training, I asked for feedback and decided I needed to revamp the virtual machine to make it more accessible/user friendly.

I added and updated out of date software in the virtual machine.

Then I noticed – I was running out of memory when trying to do my upgrades.

I realized at that moment, I totally underestimated the size of the virtual machine.

So, at this time I am revamping the virtual machine and starting with a barebone version of Ubuntu 18.04 (this is the OS the first version was built on) from Vagrant. Again, Anant gave me this advice when creating the first version. I didn’t go down that path as I never heard of Vagrant.

Speaking of Vagrant – shameless plug – I created a course through Cybrary on Intro to Vagrant. The course can be found here.

I started on the quest to version 2 yesterday (Sunday February 7, 2021), and I must say it was trying, yet fun.

Once I created the vagrantfile and started the vagrant box I realized I was dealing with the command prompt. I knew this wasn’t going to work and I needed to add a user interface. Looking on the internet, I found the lightdm and tried installing it. Once I rebooted my virtual machine, I encountered the error “could not log into session.” The login did not work.

Putting my research hat, I found the following link on how to remediate the no session login. Hmm, the ligthdm is using an older version of the unity framework that needs to be removed.

Rebooting the machine – it was a…

Somewhat success.

I had a user interface, but I didn’t like it. See tweets below

I wanted the user interface to have the same feel as the 18.04 Bionic Beaver operating system.

Doing even more research I found that 18.04 Bionic Beaver is using the MATE desktop.

Back to Google I go. I found a great site on how to install MATE onto a Linux operating system.

Somewhat score? The user interface is getting close, but not there.

Going back to the site above, I noticed that I installed the wrong version of the MATE desktop. I installed just the MATE desktop without the bells and whistles.

Looking at the bottom for the Ubuntu section it states – “

Alternatively you may choose to install Ubuntu MATE Remix.

Ubuntu MATE is a more comprehensive option that offers a slightly tweaked
layout, configuration, and themes to integrate into Ubuntu in a more seamless
fashion. This will install the complete MATE Desktop Environment as well as
LightDM and numerous other applications to provide a full and well rounded
desktop.

Once I installed the Remixed version – I finally found success!

Now that I have the interface I wanted – it’s time to add the tools and insecure apps.

Yes, that’s what set my virtual machine apart – I have insecure android apps installed in the virtual machine for students to learn mobile and android hacking as well as the common programs needed to perform mobile and android hacking.

Now, the fun part… Adding the software. I’ve added Metasploit, Burp and Zap proxies, etc.

I can’t wait to show the final product!

I hope everyone likes it…

hacking, owasp, web application security

Slides from Hacking OWASP Top 10 – Infinity Stones + Walkthrough at Blacks in Cybersecurity

On Friday February 5, 2021, I provided a training on teaching Application Security concepts using the OWASP Top 10.

The Open Web Application Security Project or OWASP is a non-profit organization whose mission is to make application security better. Members of OWASP meet every few years to create a top 10 list of the prevalent vulnerabilities in the industry. The last list was from 2017.

The structure of my training is the first part is to present the theoretical part – concepts and definitions. The last part of the training is a practical or application of the first part of the training (theoretical).

For the practical piece I used the website – BodgeIt Store. The BodgeIt Store is an insecure app, that should NOT be deployed in commercial servers. Many will say that the BodgeIt Store is a SUPER old insecure app (it’s close to 10 years old).

The app is close to 10 years old, but I find this app is good to teach application security as there’s a scoreboard and 12 challenges to complete.

Anyway, without further ado below are my slides from my training

I also provided documents that provide a walkthrough of the BodgeIt store as well as installing and using an interception proxy such as Burp Suite.

Finally, I included instructions on how to import the OWASP Broken Authentication VM which have a series of insecure apps.

See below.

Enjoy and keep hacking!

hacking, mobile

Slides from – Is Your App Safe? Reverse Engineering An Android App Training + Walkthrough from Blacks in Cybersecurity Winter Conference

During the weekend I participated as a speaker at the Blacks in Cybersecurity Winter Conference. This conference was online, and was a GREAT experience. I learned a lot of information and was able to meet with a lot of people and recruiters.

Anyway, my training today (Saturday February 6, 2021) was on reversing an Android application. In my training I talked about how apps are not safe by showing case studies (as recent as last week!) along with describing the components of an Android app. Next, I talked about how to reverse an Android app and how to do dynamic analysis using Frida. I finished the course by having a lab where I put all of the pieces together with the UnCrackable-Level1.apk.

Note – The virtual machine we’re using for this training is one that I created. The VM is titled, IntroToAndroidSecurity version 1.1.2. This VM has the common tools for Android Hacking in one place. I also included insecure Android apps in the virtual machine as well for participants to continue their learning/growth in mobile security. For the training I also used an Android emulator (Androidx86). I did this as I wanted all the participants to be on the same playing field. If we were doing mobile security as a job, we would want to have a real physical device.

Without further ado – here are my slides from the training.

Also, if you want to download the virtual machines (IntroToAndroidSecurity and Androidx86) from my training go to my Source Forge link here.

Note – Click on the External Links tab to get the VMs.

I am also including the documents I created for this training as well –

To set up the mobile lab, you will need the first two documents. I included the third document just in case the second document (importing Androidx86) does not work.

Document 4 is the walkthrough of the lab that I completed during the training.

cloud, hacking

flAWS Level 3 #aws #flaws #flAWS

Another day, another challenge.

Today’s blog post we will solve the third level of the flAWS CTF challenge.

To read the post for the second level click HERE.

Let’s get started.

Going to the URL: http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/, we see:

flaws_level3_landing_page

flaws_level3_landing_page_2

OK, we need to find an AWS key. Let’s see if we can find it.

First, we’re going to run the aws sync command. The sync command synchronize directories in a S3 buckets.

We’re going to enter the following: aws sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ .

Let’s break it down.

  1. We’re calling aws and specifying we want to sync a bucket
  2. We’re specifying the s3 bucket
  3. We’re specifying we want to have the synced files to be in our current folder (.)

After entering the command we get the following:

flaws_level3_aws_sync

We see the bucket is using GitHub. Let’s get the logs.

We’re going to run the git log command, which shows the following:

flaws_level3_aws_git_log

Hmm… we have a commit hash, let’s see if we can get more information.

Executing the command git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61, we see the following:

flaws_level3_aws_git_checkout

Next, we’re going to list the contents of the folder, and see what we find.

flaws_level3_aws_listing

Hmm… there’s an access_key.txt file, let’s see what’s in the file.

Opening the file (type ./access_keys.txt). We see an access_key and secret_access_key!

Let’s try to log into the AWS account.

We’re going to enter the command aws –profile level3 configure.

Let’s break this down

  1. Were stating we want to use aws with a named profile (of a specific user)
  2. We’re specifying the profile (user level3)
  3. We’re specifying configuration variables (from the config file)

Entering the access key, secret access key, region name (we found this in level 1), and pressing enter, we get the command prompt.

flaws_level3_aws_profile

Let’s see if we have access to the bucket.

Entering the command aws –profile level3 s3 ls we see:

flaws_level3_aws_profile_2

The contents are displayed, which means we have successfully gained access to the bucket.

Takeaways from the challenge:

Be careful what you store in git – logs are publicly accessible!

For this challenge, we were able to find access, secret access keys, and log into a AWS bucket all from a git commit message.

cloud, hacking

flAWS Level 2 #aws #flAWS #flaws

Another day, another challenge.

Today’s blog post we will solve the second level of the flAWS CTF challenge.

To read the post for the first level click HERE.

Let’s get started.

Going to the URL: http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/, we see:

flAWS_level_2_1flAWS_level_2_2

This challenge is similar to the level 1 except we need the free tier AWS account.

To complete that part of the challenge, click HERE.

Let’s list the bucket from level 2 and see if we can find anything.

We’re going to run the command we did in level 1:

aws s3 ls <s3 domain>

We will enter the command: aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

Doing this we have:

flaws_level2_listing_directory

We have a secret file titled, secret-e4443fc.

Let’s see if we can access this file.

Appending this file to the URL, we get:

flAWS_level2_solved

Yay!! We have solved the challenge.

 

cloud, hacking

flAWS Level 1 #aws #flAWS #flaws

Another day, another challenge.

In today’s post, we will solve the first challenge of the flAWS CTF.

flAWS CTF explores misconfigurations, and gotchas in AWS.

Let’s get started.

NOTE: I will be using the AWS command line. Which you can download HERE.

Going to the URL, http://flaws.cloud/, we’re presented with:

flAWS_landing_page

Scrolling down we see:

flAWS_level1

From the little bit of information we have this level contains buckets, and we possibly need to view the contents.

In AWS, there is a service called S3 or Simple Storage Service which is used for storing items for the Internet. To store an item you will need to create a bucket (see how everything is starting to come together…). Once the bucket is created, you can add your items to it.

Opening a command prompt we can type the following command

aws s3 ls <s3 domain>

Let’s break down this command.

  1. We’re using the AWS command line (by typing aws)
  2. We’re specifying we want to access the s3 service
  3. We want to list the contents of said bucket (ls = listing)
  4. We’re specify the s3 domain we want to access

In this case we will type aws s3 ls s3://flaws.cloud

Below is the output:

flaws_level1_listing_directory

Hmm… there’s a secret-dd02c7c.html file. Let’s see if we can access it.

Opening a web browser (I’m using Chrome) and entering the following URL: http://flaws.cloud/secret-dd02c7c.html,&nbsp;you should see:

flAWS_level1_solved

Yay! We have solved the challenge, along with getting the URL for level 2.

Look out for another blog post where we solve that challenge.

Takeaway from the challenge –

For this level the bucket was public which means it’s accessible for EVERYONE. If there’s sensitive information that the world should not see, AWS allows for buckets to be private.

 

boot2root, hacking, web application security

@TryHackMe – Pickle Rick CTF

Another day, another challenge.

Today’s blog post I will be solving the Pickle Rick CTF on TryHackMe.com. Click HERE to be redirected to the challenge.

After hitting the deploy button we now have our IP address.

pickle_ip_address

We see that this challenge is focused on finding vulnerabilities in a web server.

Let’s run nmap, nikto, and dirbuster to see what we find…

pickle_nmap

Executing nmap, we see that there are two port open – 22 (ssh), and 80 (http).

Moving on to nikto…

pickle_nikto

Running nikto we see that there is an login php file which is interested.

Finally, let’s look at dirbuster.

pickle_dirb

With dirbuster we have an access directory, as well as an index.html, and robots.txt file (both returning a 200 which is good). We also have a server-status which is returning a forbidden http code of 403.

We’ve done basic enumeration let’s move to the web app and see if we can find more clues.

Let’s answer the first question.

pickle_first_ingredient_question

Navigating to the IP address in a browser we see the following.pickle_landing_page

Nothing really stands out, except for the burping :-). Let’s view the source code and see what we find.pickle_source_code

Viewing the source code (Right click on page, select view source code) we see at the bottom there’s a username. Let’s see if we can find a password. Maybe our dirbuster results will come in handy…pickle_robots

Going back to our results in dirb we notice there’s a robots.txt file. Going to this file, we see the above. Hmm, this is a strange robots.txt file. Maybe this could be the password, let’s see if it works.pickle_login

In our nikto results, we had a login page. Navigating to that page and entering our username from the index.html page, and a password from the robots.txt page we get the following.pickle_portal

Success! We’re in the application.

Let’s run the ls (listing) command with the options of all and long listing and see what we have.

pickle_listing

pickle_listing_directory

Opening the Sup3rS3cretPickl3Ingred.txt file we have the first ingredient below.pickle_first_ingredient

Also notice that the directory shows the asset directory that we found in dirbuster. Navigating to that webpage we see the following

pickle_assets_directory

The directory have gifs and jpgs, nothing of importance to solve the challenge.

Let’s move on to question 2.pickle_second_ingredient_question

We know this application is vulnerable to command injection, let’s see if we can perform a directory traversal to view other parts of the application. Going back to the directory  listing we notice there’s a clue.txt file. Opening the file we see the following

pickle_clue_txt

Our hunch was correct, we need to look around the file system to find the next ingredient. pickle_directory_traversal

In the above command we’re doing a directory traversal to move up to the root directory, list all of the files in long form (ls -al), and print the working directory to make sure we’re in the correct folder (pwd). Doing this we get the below screenshot.

pickle_root_directory

We’re viewing the root level directory, so our command(s) were a success! We notice a lot of folders, but at this time two are useful for us. The first is home, which in every  Linux system ever user has a home directory. The second is root (admin/super user) which can only be accessed through the admin. We’ll come back to root later. Let’s see if we can navigate to the home directory.

pickle_change_home_directory

pickle_listing_home_directory

Executing the command above, we’re now in the /home directory! We notice there are two folders, rick and Ubuntu. The Ubuntu folder is from the operating system. Let’s explore the rick folder and see what we can find.

pickle_change_rick_directory

Changing to the rick directory we see the second ingredient!

pickle_list_second_ingredient_rick_directory

pickle_less_second_ingredient

Using the less command we open the second ingredient. Note: The filename is in quotations due to spacing. Without the quotations Linux would interpret the second in second ingredients.

pickle_second_ingredient_answer

We now have our second ingredient, let’s answer the final question.

pickle_third_ingredient_question

Remember in the beginning of this walkthrough, I mentioned that another folder – root is of particular interest to us and only the admin or superuser is the only user to access this folder. Let’s see if we can elevate our privileges to the admin and view this folder.

pickle_sudo_listing

Before we can access this folder, let’s run the sudo -l command to see what privileges we have on this box.

Executing this command we see that we can execute ANY command on this box WITHOUT a password (ALL NOPASSWD: ALL). This surely is NOT good security! Let’s use the sudo command with the listing (ls) with the root folder and see what we can find.

pickle_sudo_listing_as_root

Executing the command, we see that there are two files in the /root folder. One of them is named 3rd.txt. Could this be our third ingredient? Let’s see.

pickle_access_root_listing

Executing the sudo command in conjunction with the less command on the 3rd.txt file, we see that we do indeed have the third and final ingredient.

pickle_less_root_third_ingredient

pickle_third_ingredient

Challenge solved!

boot2root, hacking, web application security

@TryHackMe – Basic Pentesting Room

Another day, another challenge.

Today’s blog post – I will give a walk-through on a boot-to-root room called, “Basic Pentesting Room”. This boot to root is perfect to get practice in preparation for the OSCP.

Let’s get started.

Logging into TryHackMe with your credentials and heading into the room we see the following:

TryHackMe1

OK, we have tasks to complete and we will learn the following skills – brute forcing, hash cracking, service enumeration, and Linux enumeration.

The first question is:

TryHackMe2

Clicking the deploy button at the top we get the following:

tryhackme

Second question is:

TryHackMe3

OK, we need to find the services exposed. What can we do?

One solution is to use nmap -sV (TCP scan) <IP address>

In this case it would be nmap -sV 10.0.0.204. Doing this we see the following screenshot:

tryhackme_nmap

Success! We now have the services.

TryHackMe4

Let’s use dirb to find the hidden directories. See the following screenshot:

tryhackme_dirb

Our hidden directory is development.

TryHackMe5

Reviewing our enumeration we see that ports 139 and 445 are open. These ports are used for SMB (Server Message Blocks) which are HIGHLY vulnerable. Let’s run the command enum4linux and see what we find.

tryhackme_smbtryhackme_smb2

We found two users: kay and jan

Question #5!

TryHackMe6

First, entering kay, I received an error. Let’s try entering jan. Success!

TryHackMe7

Let’s fire up Hydra which is password cracking tool with the password list of rockyou (this password list is used a lot in Kali and even in the OSCP… hint, hint!)

tryhackme_hydra

TryHackMe8

The service we use to access the server is SSH.

TryHackMe9

tryhackme_jantryhackme_jan2

TryHackMe10

kay

TryHackMe11

Since we have a new user (kay) and we have a ssh folder that lists the public key we can try to get the password.

TryHackMe12

From question #10 we have the user (kay) and a public key how can we go about cracking the key?

Doing a quick Google search, I was presented with the following link.

Scrolling down we see the following:

ssh_command

Let’s see if we can recreate this to find the passphrase. Using the ssh2john we created the hash.

tryhackme_ssh2johntryhackme_zip

Next we’ll use John The Ripper with the famous rockyou wordlist to see if we can crack the passphrase.tryhackme_kay1We were successful! The passphrase is beeswax. Let’s try to ssh with kay’s private key and see if we can get in.

tryhackme_kay2

Entering the passphrase we see that we were able to successfully log into the kay account! Just to be sure I issued the command of whoami (don’t mind the fat fingering!)

tryhackme_kay_listing

tryhackme_kay_passwordNext, we run the list command to see what we’re working with. We see a pass.bak file, let’s see if this lists the password. Opening the file we see the password. Score!

Let’s run sudo -l, which will show us what commands kay can run as root. We’re prompted with the password and we entered the password that we just acquired. We’re presented with all of the commands that kay can run, and we see that kay can execute all commands as root. Great, this will be helpful for us.

There’s another file that is important in the directory – bash_history. Bash_history is useful because it shows all the commands the user executed before logging off. Let’s open the file.

tryhackme_bash_historytryhackme_listing_2

After opening the file we see a lot of commands. There is one that is very useful – sudo su. If working correctly, running this command we will change from the kay user to root. In other words we would do privilege escalation – where we start as a non-admin user and through improper configuration change to a root user. Let’s try the command and see if it works.

tryhackme_sudo_su

Running the sudo su command, and typing whoami, we see that we’re now root! We do another directory  listing which shows the files from before, so no change. Let’s see if we can get into the root directory.tryhackme_kay6

Changing to the root directory we see that there is a flag.txt file. Opening this file we presented with the verbiage above. We solved the challenge!