$host [domain name] root@kali:/# host google.com google.com has address 172.217.13.174 google.com has IPv6 address 2607:f8b0:4020:806::200e google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com.
The DNS is divided into two categories: public and private (like the IP addresses). The Google DNS address is public so that anyone connected to the internet can reach Google's website.
On the other hand, we can have private DNS for our local intranet. This can be set up using a DNS server (e.g., Microsoft Windows Server) or your router if it has a built‐in DNS server. In my home network, I defined a domain called ksec.local
. Each host on the network will have a domain name that corresponds to its IP address. For example, my file server domain name is ds‐server.ksec.local
(because the server hostname is ds‐server
), and the router/DNS server will manage all the DNS A records (an A record is a mapping between IPv4 addresses and domain names):
root@kali:~# host ds-server.ksec.local ds-server.ksec.local has address 10.0.0.177
If you specify a nonexisting DNS record, you will get an error message (this is useful to brute‐force the DNS records):
root@kali:~# host hello.ksec.local Host hello.ksec.local not found: 3(NXDOMAIN)
Take note that you can add your own static DNS records inside your Kali host. The file is located at /etc/hosts
, and here you can redirect any domain name to any live IP address. (This is how DNS poisoning works; the hacker will manipulate the A records to point to his server IP address.)
root@kali:~# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 kali # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
You'll learn more about this subject later in this book, and you will learn how DNS brute‐forcing and zone transfers work.
To display the active network connections on your Kali host, you must use the netstat
command tool to get the job done. You'll use this command in your post‐exploitation phase to check how the Linux host is communicating with its network.
On our Kali host, we have started the SSH (port 22) and the web (port 80) services; the netstat
tool will allow us to see them listening for incoming connections:
root@kali:~# netstat -antu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN udp 0 0 10.0.0.185:68 10.0.0.1:67 ESTABLISHED
It's essential to understand what each option means:
‐a/‐‐all : Display all the sockets. Take note that this option is very verbose; thus, we need to combine it with the following options (to filter the output).
‐n/‐‐numeric : Do not resolve names. In the previous command, you saw that the IP address is followed by the port number. If I don't use the ‐n option, then the tool will try to figure out the service name (for example, for 80, it's going to be HTTP instead).
‐t/‐‐tcp : Display TCP connections.
‐u/‐‐udp : Display UDP connections.
There are so many ways to transfer files in Kali Linux. First, to download files from the internet/intranet, you have two tools in your arsenal: wget
and curl
. In the following example, we use both of the tools to download a password text file from one of my local web servers:
$wget [URL] root@kali:~# wget http://ubuntu.ksec.local/passwords.txt --2020-10-01 13:32:02-- http://ubuntu.ksec.local/passwords.txt Resolving ubuntu.ksec.local (ubuntu.ksec.local)… 10.0.0.186 Connecting to ubuntu.ksec.local (ubuntu.ksec.local)|10.0.0.186|:80… connected. HTTP request sent, awaiting response… 200 OK Length: 0 [text/plain] Saving to: 'passwords.txt.1' passwords.txt.1 [ <=> ] 0 --.-KB/s in 0s 2020-10-01 13:32:02 (0.00 B/s) - 'passwords.txt.1' saved [0/0] $curl -O [URL] root@kali:~# curl -O http://ubuntu.ksec.local/passwords.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 32 100 32 0 0 16000 0 --:--:-- --:--:-- --:--:-- 16000
If you want to download files from GitHub, then you can use the git
command:
$git clone [git project URL]
Another way to securely transfer files using the SSH protocol is the scp
command tool. It's important to understand that you will need the SSH service to be started for this process to work properly. As usual, you see a practical example of how the workflow of copying works from source to destination.
First, we will start the SSH server on a remote Ubuntu Linux host, and this is where you're going to download my files. (By default SSH server is not installed on Ubuntu. To get the job done, execute the command $sudo apt install openssh‐server ‐y
.) In this example, we are downloading a passwords.txt
file from the remote Ubuntu server:
gus@ubuntu:~$ ls Desktop Downloads passwords.txt Public Videos Documents Music Pictures Templates
To get the job done of downloading the file, use the scp
command with the following pattern (the dot at the end means that we are copying the file to our current directory in Kali):
$scp [remote-username@remote-ip:/remote-path] [destination local path] root@kali:~# scp gus@ubuntu.ksec.local:/home/gus/passwords.txt . gus@ubuntu.ksec.local's password: passwords.txt 100% 17 16.7KB/s 00:00
Next, we will try to push a file called test.txt
from my Kali to the remote SSH server (we will copy the file on the user's home directory in Ubuntu) using the scp
command again:
$scp [file local path] [remote-username@remote-ip:/remote-path] root@kali:~# scp /root/test.txt gus@ubuntu.ksec.local:/home/gus gus@ubuntu.ksec.local's password: test.txt 100% 5 0.4KB/s 00:00
Later in this book, you will see even more ways to transfer files such as Samba, FTP, etc. For the time being, you just learned the most common ways that you need to be aware of.
With so many commands to learn in this chapter, it's overwhelming, right? The secret of mastering the usage of the terminal window is through practice. It will take a while to get familiar with the terminal window, but once you're in, you will fall in love with it.
Your role is focused on penetration testing, and the goal of this chapter is to make it easy for you to handle the system of Kali Linux. This chapter presented the necessary tools and commands that you will encounter during an engagement. In the end, you're not a Linux system admin, but in cybersecurity, you will need to think out of the box.
In the previous chapter, you learned lots of commands in Linux. Now, let's take your skills to the next level in the command‐line tools. In this chapter, you will see how to create scripted commands using Bash based on what you have learned so far.
Why Bash scripting? The universality of Bash gives us, penetration testers, the flexibility of executing powerful terminal commands without the need to install a compiler or an integrated development environment (IDE). To develop a Bash script, all you need is a text editor, and you're good to go.
When should you use Bash scripts? That's an important question to tackle before starting this chapter! Bash is not meant for developing sophisticated tools. If that's what you would like to do, you should use Python instead (Python fundamentals are covered later in this book). Bash is used for quick, small tools that you implement when you want to save time (e.g., to avoid repeating the same commands, you just write them in a Bash script).
Читать дальше