Never Ending Security

It starts all here

The Kali Linux Dojo – A Kali Linux Workshop by its Developers

A Kali Linux Workshop by its Developers

Offensive Security is proud to present a Kali Linux workshop that provides a unique journey through our distribution while providing rare insights and an in-depth look at the most powerful features available in the Kali penetration testing platform.

Created by the Kali Linux development team and debuted at Black Hat USA 2014, this event will also include an interactive Q&A session with the developers, hands on instructions on creating your own custom Kali Linux ISOs, automatic unattended installations of Kali Linux, enterprise management of the distribution, building and utilizing Kali Linux on ARM platforms, and the step by step creation of a custom Raspberry Pi image – transforming it into an effective hardware backdoor. If you’ve ever wished for fluent proficiency with Kali Linux, this workshop is for you.

If you want to play along with us, you’ll need to come prepared with a fast laptop running an updated version of Kali Linux. For more details about the workshop and its requirements, check out our “Kali Linux Dojo” announcement page.

Kali Linux Dojo Workshop Topics and Description

Workshop #1: Kali Linux – Under the Hood

Technical Level : 1/5 | Duration : 45 minutes

In this workshop, we will introduce the Kali Linux security auditing distribution, its history, development, architecture, and features. We will delve into how we got to where we are today, how penetration-testing tools are evaluated for inclusion in the distribution, and a look at the road ahead. If we have enough time, we’ll also dabble with altering and patching Kali packages.

At the end of this session, we will also conduct a Q&A session where individuals can ask the Kali developers questions about the project. If you are new to Kali Linux and need a guided introduction or you have specific questions for the Kali team, this is the workshop for you. Workshop Goals – Get to know the developers, get warmed up and set-up, build some basic Kali packages.

Workshop #2: Rolling Your Own – Generating Custom Kali Linux ISOs

Technical Level : 2/5 | Duration : 1 hour

One of the most powerful features of Kali Linux is the ability to create your own flavours of the distribution containing customized tools, desktop managers, and services. This workshop will show you how to create your own personalized Kali Linux ISO, customizing virtually every aspect using the live-build utility and making efficient use of the various metapackages available in Kali.Workshop Goals – Attendees should be able to understand and independently build complex Kali images, such as the Kali Linux ISO of Doom.

Workshop #3: Pre-seeding, Automating, and Managing Multiple Kali Installations

Technical Level : 3/5 | Duration : 1 hour

Kali Linux supports several interesting installation and deployment options, which will be explored in depth. In this workshop, we’ll show you how to deploy Kali over the network with PXE and iPXE technologies, pre-seed installations, deploy custom Kali setups, and then use the Salt management and configuration package to manage multiple installations of Kali throughout the enterprise.Workshop Goals – Attendees should be able to install and automate Kali Linux instances to fit specific needs. Fluency in network installs, pre-seeding, and slipstreaming packages. If time permits, enterprise management of Kali with Salt.

Workshop #4: Penetration Testing From Your Pocket – Kali Linux on ARM and Android Devices

Technical Level : 3/5 | Duration : 1 hour

Kali Linux supports ARMEL and ARMHF architectures. This allows us to put Kali on a variety of interesting hardware platforms as well as easily conduct chroot installs of Kali Linux on Android. In this workshop, we will show you how to install Kali Linux within a chroot environment on an Android device. Workshop Goals – Attendees should be able to manually create custom Kali ARM images for use in chroot environments such as Android devices. Attendees should also be able to deploy these images on their Android cellphone and be fluent with supportive Android applications such as Linux Deploy.

Workshop #5: The Ultimate Hardware Backdoor – Kali Linux Edition

Technical Level : 3/5 | Duration : 1 hour

This will be the concluding session, where we’ll use methods demonstrated throughout the day to show you how to create your very own “Raspberry Pi of Doom”, based off Kali Linux and a Raspberry Pi. The configuration involves creating an image file that contains a minimal Kali installation, which on boot, connects back to the penetration tester over a VPN connection and bridges the remote target network with the testers’. This image can then also be used on an Android device – proving to be perhaps the most potent hardware backdoor of them all. Workshop Goals – Attendees should be able to manually create custom native Kali ARM images for a Raspberry Pi which have similar properties to the “ISO of Doom”. This includes compiling a custom ARM kernel for the Raspberry Pi.

Battle Tested, Free Kali Linux Educational Resources

After a very short deliberation, the team decided that once these training materials are polished and battle tested in the upcoming conferences, we will release them publicly and free of charge so that Kali Linux users worldwide will all be able to benefit from accessible, high quality training materials revolving around our open source project. Our hope is that by doing this, our users will become both more aware and proficient with the advanced features available in Kali Linux and be able to use it more effectively. This means that we will release these workshop training materials to the public early 2015. We will of course announce this release via Twitter and our blogs, so stay tuned!

02 – Building Custom Kali ISOs

Building Custom Kali ISOs

One of the most powerful features of Kali Linux is the ability to create your own flavors of the distribution containing customized tools, desktop managers, and services. This workshop will show you how to create your own personalized Kali Linux ISO, customizing virtually every aspect using the live-build utility and making efficient use of the various meta-packages available in Kali.

The Awesomeness of Live Build

0x00 – Begin by updating the repos, installing the prerequisites, and checking out a fresh version of live-build-config from the Kali Git repositories:

apt-get update
apt-get install git live-build cdebootstrap devscripts -y
git clone git://
cd live-build-config

0x01 – Overwrite the default Kali package list, including only the packages you want. In the video, we simply edited the list and changed a few package names.

cat > config/package-lists/kali.list.chroot << EOF

0x02 – Add a customised syslinux boot entry which includes a boot parameter for a custom preseed file.

cat << EOF > config/includes.binary/isolinux/install.cfg
label install
menu label ^Install Automated
linux /install/vmlinuz
initrd /install/initrd.gz
append vga=788 quiet file=/cdrom/install/preseed.cfg locale=en_US keymap=us hostname=kali domain=local.lan

0x03 – Customise the ISO build. In this example, we’ll have the SSH service start by default. To do this, we can use a chroot hook script which is placed in the “hooks” directory:

echo ‘update-rc.d -f ssh enable’ >>  config/hooks/01-start-ssh.chroot
chmod +x config/hooks/01-start-ssh.chroot

0x04 – Next, we download a wallpaper and overlay it. Notoce how chroot overlayed files are placed in the includes.chroot directory.

mkdir -p config/includes.chroot/usr/share/wallpapers/kali/contents/images
mv kali_linux.jpg config/includes.chroot/usr/share/wallpapers/kali/contents/images

0x05 – Add a preseed file that will run through a default Kali installation with no input (unattended). We can include a ready made preseed configuration and alter it as needed:

mkdir -p config/debian-installer
wget -O config/debian-installer/preseed.cfg

0x06 – Let’s include a Nessus Debian package into the packages directory for inclusion into our final build. Since we used a 64 bit build, we’re including a 64 bit Nessus Debian package.Download the Nessus .deb file and place it in the packages.chroot directory:

mkdir config/packages
mv Nessus-*amd64.deb config/packages/

0x07 – Now you can proceed to build your ISO, this process may take a while depending on your hardware and internet speeds. Once completed, your ISO can be found in the live-build root directory.

lb build

For more live-build implementations, refer to the following:

03 – Kali Linux USB Persistence

USB Persistence & Encrypted Persistence

In this workshop, we will examine the various features available to us when booting Kali Linux from USB devices. We will explore features such as persistence, creating LUKS encrypted persistence stores, and even dabble in “LUKS Nuking” our USB drive. The default Kali Linux ISOs (from 1.0.7 onwards) support USB encrypted persistence.

0x01 – Start by imaging the Kali ISO onto your USB stick (ours was /dev/sdb). Once done, you can inspect the USB partition structure using parted /dev/sdb print.

dd if=kali-linux-1.1.0-amd64.iso of=/dev/sdb bs=1M

0x02 – Create and format an additional partition on the USB stick. In our example, we create a persistent partition of about 7 GB in size:

root@kali:~# parted
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type ‘help’ to view a list of commands.

(parted) print devices
/dev/sda (480GB)
/dev/sdb (31.6GB)

(parted) select /dev/sdb
Using /dev/sdb

(parted) print
Model: SanDisk SanDisk Ultra (scsi)
Disk /dev/sdb: 31.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
1      32.8kB  2988MB  2988MB  primary               boot, hidden
2      2988MB  3050MB  64.9MB  primary  fat16

(parted) mkpart primary 3050 10000
(parted) quit
Information: You may need to update /etc/fstab.

0x04 – Encrypt the partition with LUKS:

cryptsetup –verbose –verify-passphrase luksFormat /dev/sdb3

0x05 – Open the encrypted partition:

cryptsetup luksOpen /dev/sdb3 my_usb

0x06 – Create an ext3 filesystem and label it.

mkfs.ext3 /dev/mapper/my_usb
e2label /dev/mapper/my_usb persistence

0x07 – Mount the partition and create your persistence.conf so changes persist across reboots:

mkdir -p /mnt/my_usb
mount /dev/mapper/my_usb /mnt/my_usb
echo “/ union” > /mnt/my_usb/persistence.conf
umount /dev/mapper/my_usb
cryptsetup luksClose /dev/mapper/my_usb

Now your USB stick is ready to plug in and reboot into Live USB Encrypted Persistence mode.

Multiple Persistence Stores

At this point we should have the following partition structure:

root@kali:~# parted /dev/sdb print

We can add additional persistence stores to the USB drive, both encrypted or not…and choose which persistence store we want to load, at boot time. Let’s create one more additional non-encrypted store. We’ll label and call it “work”.

0x01 – Create an additional, 4th partition which will hold the “work” data. We’ll give it another 5GB of space.

root@kali:~# parted /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) print
Model: SanDisk SanDisk Ultra (scsi)
Disk /dev/sdb: 31.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
1      32.8kB  2988MB  2988MB  primary               boot, hidden
2      2988MB  3050MB  64.9MB  primary  fat16
3      3050MB  10.0GB  6947MB  primary

(parted) mkpart primary 10000 15000
(parted) quit
Information: You may need to update /etc/fstab.

0x02 – Format the fourth partition, label it “work”.

mkfs.ext3 /dev/sdb4
e2label /dev/sdb4 work

0x03 – Mount this new partition and create a persistence.conf in it:

mkdir -p /mnt/usb
mount /dev/sdb4 /mnt/usb
echo “/ union” > /mnt/usb/persistence.conf
umount /mnt/usb

Boot the computer, and set it to boot from USB. When the boot menu appears, edit the persistence-label parameter to point to your preferred persistence store!

Emergency Self Destruction of Data in Kali

As penetration testers, we often need to travel with sensitive data stored on our laptops. Of course, we use full disk encryption wherever possible, including our Kali Linux machines, which tend to contain the most sensitive materials.

root@kali:~# cryptsetup luksAddNuke /dev/sdb3
Enter any existing passphrase:
Enter new passphrase for key slot:

Now dump the keyslots to see the changes:

root@kali:~# cryptsetup luksDump /dev/sda5
Device /dev/sda5 doesn‘t exist or access denied.
root@kali:~# cryptsetup luksDump /dev/sdb3
LUKS header information for /dev/sdb3

Version:          1
Cipher name:      aes
Cipher mode:      xts-plain64
Hash spec:        sha1
Payload offset:   4096
MK bits:          256
MK digest:        f7 17 b9 a7 9f 7f 9b 21 f2 b9 40 78 c2 97 f5 f0 c2 bb 28 8b
MK salt:          f5 a4 80 02 e7 21 0d 7e 5a 64 f4 96 78 a3 15 3c
09 7b 3f 41 80 2b 5c bf c5 de 92 70 69 bb 34 b2
MK iterations:    64500
UUID:             96793acb-c2d3-45b7-aed9-1af952386556

Key Slot 0: ENABLED
Iterations:             258064
Salt:                   df 3c d6 03 4a 78 ce ef 62 fd f1 56 25 d4 c5 96
2a 12 bb 94 4b d7 cf c1 0a b5 27 47 09 ae 31 46
Key material offset:    8
AF stripes:             4000
Key Slot 1: ENABLED
Iterations:             259108
Salt:                   30 07 ff ef fc f5 74 65 04 f7 66 87 77 f1 74 4f
7d 2f 76 e2 71 e7 6a 9c 6d c1 c1 7b 80 53 cb c1
Key material offset:    264
AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Backup you LUKS keyslots and encrypt them:

cryptsetup luksHeaderBackup –header-backup-file luksheader.back /dev/sdb3
openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back

Now boot into your encrypted store, and give the Nuke password, rather than the real decryption password. This will render any info on the encrypted store useless. Once this is done, verify that the data is indeed inacessible.

Lets restore the data now. We’ll decrypt our backup of the LUKS keyslots, and restore them to the encrypted partition:

openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back
cryptsetup luksHeaderRestore –header-backup-file luksheader.back /dev/sdb3

Our slots are now restored. All we have to do is simply reboot and provide our normal LUKS password and the system is back to its original state.

04 – Raspberry Pi Disk Encryption

With the advent of smaller, faster ARM hardware such as the new Raspberry Pi 2, we’ve been seeing more and more use of these small devices as “throw away hackboxes”. While this might be a new and novel technology, there’s one major drawback to this concept – and that is the confidentiality of the data stored on the device itself. Most of the setups we’ve seen do little to protect the sensitive information saved on the SD cards of these little computers. This fact, together with a nudge from friends on twitter is what prompted us to create an LUKS encrypted, NUKE capable Kali Linux image for our Raspberry Pi 2 device. The following blog post describes the process, so you can repeat it and make your own shiny shiny.

Birds Eye View of the Disk Encryption Process

Before we begin, let’s take a minute to quickly describe what we’ll be doing – as while this process is not complicated, it *is* involved. This is basically our shpiel:

  1. We download Kali Raspberry Pi 2 (RPi 2) image, dd it to an SD card.
  2. We chroot to the RPi 2 image and install / update several files in preparation for our crypted boot.
  3. We create an initramfs file which includes Dropbear and freshly generated SSH keys.
  4. We rsync the modified rootfs to a temporary backup location, and then delete the rootfs partition from the SD.
  5. We then recreate an encrypted partition to which we restore the root partition data. That’s it!

If all goes well, the RPi 2 will boot, and then LUKS will kick in and ask for a password to decrypt the root drive, while simultaneously opening a Dropbear SSH session through which you can SSH in and provide a boot decryption password. Oh yeah, did we mention this image also has LUKS NUKE capabilities?

Getting your hands dirty

As always, all our ARM dev is done on a Kali amd64 machine, and we’ve made sure that we have all the dependencies we need. We download the Kali RPi 2 image, extract is and dd it to our SD card, which in our case showed up as sdb2 – adapt as necessary!

dd if=/root/kali-1.0.9-rpi.img of=/dev/sdb bs=1M

Once dd’ed we mount the various partitions and chroot into the Kali RPi 2 image:

mkdir -p /mnt/chroot/boot

mount /dev/sdb2 /mnt/chroot/
mount /dev/sdb1 /mnt/chroot/boot/

mount -t proc none /mnt/chroot/proc
mount -t sysfs none /mnt/chroot/sys
mount -o bind /dev /mnt/chroot/dev
mount -o bind /dev/pts /mnt/chroot/dev/pts

cp /usr/bin/qemu-arm-static /mnt/chroot/usr/bin/
LANG=C chroot  /mnt/chroot/

We then update our image and install some essential packages we will need for our process:

rm -rf /var/lib/apt/lists
mkdir -p lists/partial
apt-get update
apt-get install kali-archive-keyring busybox cryptsetup dropbear

We create an initial initramfs file which will trigger the dropbear SSH key generation. We first find out the modules directory version number…

root@kali:/# ls -l /lib/modules/ |awk -F” ” ‘{print $9}’

…and then use that version info to generate the initramfs file.

mkinitramfs -o /boot/initramfs.gz 3.12.26

We configure the OpenSSH service to start at boot, and remember to change the default password!

update-rc.d ssh enable

Next, we verify that the /boot directory is mounted, and if so, we modify the boot parameters in cmdline.txt and config.txt.

nano /boot/cmdline.txt

and add / change to the following parameters:

root=/dev/mapper/crypt_sdcard cryptdevice=/dev/mmcblk0p2:crypt_sdcard rootfstype=ext4

Next comes config.txt:

echo initramfs initramfs.gz 0x00f00000 > /boot/config.txt

Now we deal with the Dropbear SSH access. We copy over the SSH private key to our laptop :

cat /etc/initramfs-tools/root/.ssh/id_rsa

…and limit the SSH connection to allow interaction with the cryptroot application only.

nano /etc/initramfs-tools/root/.ssh/authorized_keys

We paste the following before the ssh public key begins.

command=”/scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 ‘cryptroot’ | cut -d ‘ ‘ -f 3`”

We then create a fstab and crypttab with our configure boot device and exit the chroot:

cat <<EOF > /etc/fstab
proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mapper/crypt_sdcard  /     ext4    defaults,noatime  0       1

echo crypt_sdcard  /dev/mmcblk0p2  none    luks > /etc/crypttab

We re-generate the initramfs and exit the chroot.

mkinitramfs -o /boot/initramfs.gz 3.12.26

…and proceed to backup our rootfs partition:

umount /mnt/chroot/boot
umount /mnt/chroot/sys
umount /mnt/chroot/proc
mkdir -p /mnt/backup
rsync -avh /mnt/chroot/* /mnt/backup/

Once outside of the chroot, we unmount everything:

umount /mnt/chroot/dev/pts
umount /mnt/chroot/dev
umount /mnt/chroot

Once done, we delete the existing 2nd partition on the SD card, and recreate an empty one, which we set up for LUKS encryption.

echo -e “d\n2\nw” | fdisk /dev/sdb
echo -e “n\np\n2\n\n\nw” | fdisk /dev/sdb

Unplug your SD card and replug it back in to have the new partitions register, then start setting up your encrypted partition.

cryptsetup -v -y –cipher aes-cbc-essiv:sha256 –key-size 256 luksFormat /dev/sdb2
cryptsetup -v luksOpen /dev/sdb2 crypt_sdcard
mkfs.ext4 /dev/mapper/crypt_sdcard

Once ready, we restore the rootfs backup to the now encrypted partition…

mkdir -p /mnt/encrypted
mount /dev/mapper/crypt_sdcard /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
umount /mnt/encrypted/
rm -rf /mnt/backup

…then unmount and close the volume.

cryptsetup luksClose /dev/mapper/crypt_sdcard

That’s it! Now all that remains to do is boot up the RPi 2 using the modified SD card. The initramfs will load Dropbear and get a DHCP address on your local LAN (you can also hardcode an IP) allowing you to SSH to the booting RPi and enter a decryption password. Once the password is accepted, Dropbear will exit and the RPi will continue to boot. You should see something like the following:

root@kali:~# ssh -i key
The authenticity of host ‘ (’ can’t be established.
RSA key fingerprint is a6:a2:ad:7d:cb:d8:70:58:d1:ed:81:e8:4a:d5:23:3a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘’ (RSA) to the list of known hosts.
Unlocking the disk /dev/mmcblk0p2 (crypt_sdcard)
Enter passphrase: cryptsetup: crypt_sdcard set up successfully
Connection to closed.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s