Termux ID: Debian -->

linux-soft-exploit-suggester finds exploits for all vulnerable software in a system helping with the privilege escalation. It focuses on software packages instead of Kernel vulnerabilities.

> python linux-soft-exploit-suggester.py -h

| _ __ _ _ | _ _ | _ | __ __ __ _ __ | _ _
|·| || |\/ (_ | ||_ |- /_)\/| \|| |·|- (_ | || )| )/_)(_ |- /_)|
||| ||_|/\ __)|_|| |_ \_ /\|_/||_|||_ __)|_||_/ |_/ \_ __) |_ \_ |
| _/ _/

linux-soft-exploit-suggester:
Search for Exploitable Software from package list.

optional arguments:
-h, --help Show this help message and exit
-f FILE, --file FILE Package list file
--clean Use clean package list, if used 'dpkg-query -W'
--duplicates Show duplicate exploits
--db DB Exploits csv file [default: file.csv]
--update Download latest version of exploits db
-d debian|redhat, --distro debian|redhat
Linux flavor, debian or redhat [default: debian]
--dos Include DoS exploits
--intense Include intense package name search,
when software name doesn't match package name (experimental)
-l 1-5, --level 1-5 Software version search variation [default: 1]
level 1: Same version
level 2: Micro and Patch version
level 3: Minor version
level 4: Major version
level 5: All versions
--type TYPE Exploit type; local, remote, webapps, dos.
e.g. --type local
--type remote
--filter FILTER Filter exploits by string
e.g. --filter "escalation"

usage examples:
Get Package List:
debian/ubuntu: dpkg -l > package_list
redhat/centos: rpm -qa > package_list

Update exploit database:
python linux-soft-exploit-suggester.py --update

Basic usage:
python linux-soft-exploit-suggester.py --file package_list

Specify exploit db:
python linux-soft-exploit-suggester.py --file package_list --db file.cve

Use Redhat/Centos format file:
python linux-soft-exploit-suggester.py --file package_list --distro redhat

Search exploit for major version:
python linux-soft-exploit-suggester.py --file package_list --level 4

Filter by remote exploits:
python linux-soft-exploit-suggester.py --file package_list --type remote

Search specific words in exploit title:
python linux-soft-exploit-suggester.py --file package_list --filter Overflow

Advanced usage:
python linux-soft-exploit-suggester.py --file package_list --level 3 --type local --filter escalation

Output
> python linux-soft-exploit-suggester.py --file packages --db file.csv

| _ __ _ _ | _ _ | _ | __ __ __ _ __ | _ _
|·| || |\/ (_ | ||_ |- /_)\/| \|| |·|- (_ | || )| )/_)(_ |- /_)|
||| ||_|/\ __)|_|| |_ \_ /\|_/||_|||_ __)|_||_/ |_/ \_ __) |_ \_ |
| _/ _/

[+] DNSTracer 1.9 - Buffer Overflow - local
From: dnstracer 1.9
File: /usr/share/exploitdb/platforms/linux/local/42424.py
Url: https://www.exploit-db.com/exploits/42424
[+] GNU Wget < 1.18 - Arbitrary File Upload / Remote Code Execution - remote
From: wget 1.17.1
File: /usr/share/exploitdb/platforms/linux/remote/40064.txt
Url: https://www.exploit-db.com/exploits/40064
[+] GNU Screen 4.5.0 - Privilege Escalation (PoC) - local
From: screen 4.3.1
File: /usr/share/exploitdb/platforms/linux/local/41152.txt
Url: https://www.exploit-db.com/exploits/41152
[+] Ghostscript 9.21 - Type Confusion Arbitrary Command Execution (Metasploit) - local
From: ghostscript 9.21
File: /usr/share/exploitdb/platforms/linux/local/41955.rb
Url: https://www.exploit-db.com/exploits/41955
[+] KeepNote 0.7.8 - Command Execution - local
From: keepnote 0.7.8
File: /usr/share/exploitdb/platforms/multiple/local/40440.py
Url: https://www.exploit-db.com/exploits/40440
[+] MAWK 1.3.3-17 - Local Buffer Overflow - local
From: mawk 1.3.3
File: /usr/share/exploitdb/platforms/linux/local/42357.py
Url: https://www.exploit-db.com/exploits/42357
[+] Sudo 1.8.20 - 'get_process_ttyname()' Privilege Escalation - local
From: sudo 1.8.20
File: /usr/share/exploitdb/platforms/linux/local/42183.c
Url: https://www.exploit-db.com/exploits/42183

...

Generate package list

Debian
dpkg -l > package_list

Red Hat
rpm -qa > package_list

TIP. Packages from running processes and SETUID binaries

Running packages
> for i in $(ps auex|sed -e ':l;s/  / /g;t l'|cut -d' ' -f11|grep -v '\['|grep '/'|sort -u); \
do \
dpkg -l | grep "^ii `dpkg -S $i 2>&1|cut -d':' -f1`" |tee -a potentials; \
done

SETUID Binaries
> for i in $(find / -perm -4000 -o -perm -2000 -type f 2>/dev/null); \
do \
dpkg -l | grep "^ii `dpkg -S $i 2>&1|cut -d':' -f1`"|tee -a potentials; \
done

Eliminate duplicates and Run
> sort -u potentials > potentials_no_duplicates
> python linux-soft-exploit-suggester.py --file potentials_no_duplicates --level 2 --type local

| _ __ _ _ | _ _ | _ | __ __ __ _ __ | _ _
|·| || |\/ (_ | ||_ |- /_)\/| \|| |·|- (_ | || )| )/_)(_ |- /_)|
||| ||_|/\ __)|_|| |_ \_ /\|_/||_|||_ __)|_||_/ |_/ \_ __) |_ \_ |
| _/ _/

[+] Sudo 1.8.20 - 'get_process_ttyname()' Privilege Escalation - local
From: sudo 1.8.20
File: /usr/share/exploitdb/platforms/linux/local/42183.c
Url: https://www.exploit-db.com/exploits/42183
[+] Fuse 2.9.3-15 - Privilege Escalation - local
From: fuse 2.9.7
File: /usr/share/exploitdb/platforms/linux/local/37089.txt
Url: https://www.exploit-db.com/exploits/37089


Linux Soft Exploit Suggester - Search Exploitable Software On Linux


A Simple tool for installing pentest tools and forensic tools on Debian / Ubuntu Based OS
Tested on Linux Mint And Kali Linux

I Want To Get This How To Do ??
  • Change Your Privileges Terminal to Root Mode
your@terminal:~$ sudo su
  • And Then Clone This
your@terminal:~# git clone https://github.com/Yukinoshita47/Pentest-Tools-Auto-Installer.git
  • Get Inside Dir
your@terminal:~# cd Pentest-Tools-Auto-Installer
  • Give Chmod Access Level 777
your@terminal:~# chmod 777 ptai.sh
  • Run It
your@terminal:~# ./ptai.sh
for install the tools just press number of tools what you want to install it and then press enter and if you want to exit just press 1337 and then press enter or simple way to exit just press CTRL C

Video Demo
Demo Video Pentest Tools Auto Installer https://www.youtube.com/watch?v=eKrgr1gm3z8
Make Your Android For Pentesting With Gnuroot Debian And Pentest Tools Auto Installer https://youtu.be/Wdx1LSFLG5Y

List of tools
  1. Nmap[Network Scanner]
  2. Zenmap [Nmap Gui version]
  3. Wireshark [Network Sniffer]
  4. W3af [Web Vulnerability Scanner]
  5. Nikto [Web Vulnerability Scanner]
  6. Whatweb [Web Vulnerability Scanner]
  7. John [Password Cracker]
  8. PDF-Crack [PDF Password Cracker]
  9. FCrackZip [ZIP Password Cracker]
  10. Ophcrack [Password Cracker]
  11. Volatility [Digital Forensic]
  12. Digital Forensic Framework [Digital Forensic]
  13. GHex [Digital Forensic]
  14. Aircrack-Ng [Wifi Audit]
  15. Ettercap [Network Audit]
  16. Yersinia [Network Audit]
  17. Packet Sniffer / Spoofing [Network Audit]
  18. Wafw00f [Web Application Firewall Audit]
  19. SSLyze [SSL Audit]
  20. Droopescan [Wordpress, Joomla, And Other CMS Auditing]
  21. SQLMap [Automate SQL Injection Audit]
  22. SSLScan [SSL Audit]
  23. Hydra [Password Cracker]
  24. Dmitry [Intelligence Gathering]
  25. HAVP [HTTP Anti Virus Proxy]
  26. krdc [Windows Remote Desktop Connection client]
  27. Medusa [Password Cracker]

Screenshot







Pentest-Tools-Auto-Installer - A Simple Tool For Installing Pentest Tools And Forensic Tools On Debian / Ubuntu Based OS


Seccubus automates regular vulnerability scans with various tools and aids security people in the fast analysis of its output, both on the first scan and on repeated scans.
On repeated scan delta reporting ensures that findings only need to be judged when they first appear in the scan results or when their output changes.
Seccubus 2.x is the only actively developed and maintained branch and all support for Seccubus V1 has officially been dropped.

Seccubus V2 works with the following scanners:
  • Nessus
  • OpenVAS
  • Skipfish
  • Medusa (local and remote)
  • Nikto (local and remote)
  • NMap (local and remote)
  • OWASP-ZAP (local and remote)
  • SSLyze
  • Medusa
  • Qualys SSL labs
  • testssl.sh (local and remote)
For more information visit [www.seccubus.com]

Seccubus Docker container

Usage

Running a full stack (db/app/frontend) in a single container. And get an interactive shell
docker run -it seccubus/seccubus /bin/bash
By default the container holds a mysql server that runs and stores data locally. If you want data persistency there are two options:
Connect the container to a remote mysql/MariaDB database with environment viariables:
docker run -ti seccubus/seccubus -e DBHOST=dns.name.of.db.host \
-e DBPOSRT=3306 \
-e DBNAME=name.of.database \
-e DBUSER=db.username \
-e DBPASS=password \
/bin/bash
Or, mount a data volume with a db directory on it
mkdir data
mmdir data/db
docker run -it seccubus/seccubus -v ($pwd)/data:/opt/seccubus/data /bin/bash
Please be aware that you can only run one container at a time if you mount a local directory on /var/lib/mysql.

Running a scan
Run the following command to start the scan 'ssllabs' in workspace 'Example' (this workspace is created by default if you use the local mysql database)
docker run -ti seccubus/seccubus scan Example ssllabs
Please be aware that you need soem data persistency here or the data will be stored in a local database that will be deleted whent he container terminates

Running a scheduler
You can run a docker container as a scheduler. This will make it run cron and allow your crontab to execute scans.You can populate the crontab by either placing a file called crontab in the /opt/seccubus/data volume or puting the lines of you crontab in evironement variables starting with CRON_
docker run -e "STACK=cron" -e "CRON_1=* 0 * * * bin/do-scan -w Example -s ssllabs" -ti seccubus/seccubus
This will spin up a container that executes scan ssllabs from workspace Example at midnight every night.
You can set the TZ vairable to control the timezone.

Controlling TLS certificates
The Seccubus container is TLS enabled by default. The environment variable TLS controls this behaviour. Of it is set to anything other then yes, TLS is turned off.
There are three ways to control the certificate:
  • Do nothing : Self signed certificates will be generated for you
  • Populate the variables TLSCERT and TLSKEY : The contents will be placed in /opt/seccubus/data/seccubus.pem and /opt/seccubus/data/seccubus.key and used
  • Put the certificates in the files seccubus.pem and seccubus.key on a data volume and mount it on /opt/seccubus/data

Show this help message
docker run -ti seccubus/seccubus help

Default command
If you don't specify a command to docker run
docker run seccubus/seccubus
The web server access log and error log will be tailed to the screen.

Other options
You can set the following environment variables:
  • STACK - Determines which part of the stack is run
    • full - Run everything
    • front - Start apache to serve the html/javascript frontend (this requires that the APIURL variable is set too)
    • api - Start apache to serve the json api at / (starts MariaDB too if required)
    • web - Start apache to serve both the html/javascript frontend and the json
    • perl - Do not start apache, just use this container as an perl backend
  • DBHOST, DBPORT, DBNAME, DBUSER, DBPASS - Database connection parameters
    • If DBHOST/DBPORT are set to 127.0.0.1/3306 the local MariaDB instance is started
  • APIURL - Path to the API url
    • Set this if your set STACK to front to redirect the API calls to an alternative relative or absolute URL.
  • BASEURI - Base URI for seccubus
    • Server the application at the value provided
  • SMTPSERVER - IP address or host name of an SMTP server to be used for notifications
  • SMTPFROM - From address used in notifications
  • TICKETURL_HEAD/TICKETURL_TAIL - If these are set ticket numberrs will be linked to this URL
  • SSHKEY1, SSHKEY2, SSHKEY3 .. SSHKEY9
    • The content of this environment variable will stored in the file /opt/seccubus/.ssh/SSHKEY1 etc.
    • You can use this mechanism to provide ssh keys that are used to start remote scans
  • HTTP_AUTH_HEADER - Set the http authentication header
    • If you are using something like OpenAM to authenticate your users, this allows you to set which http request header contains the user that OpenAM detected
  • TZ - Set the timezone of the container
  • TLS - Controls TLS behaviour yes means TLS is on, otherwise TLS is off. TLS is on by default.
  • JIT_GROUP - Controls JIT provisioning of users
  • CRON_MAIL_TO - Mail cron messages to this addres
  • CRON_* - Add these lines to crontab in alphabetical order

Seccubus - Easy Automated Vulnerability Scanning, Reporting And Analysis


Intelligence and Reconnaissance Package/Bundle installer.
IntRec-Pack is a Bash script designed to download, install and deploy several quality OSINT, Recon and Threat Intelligence tools. Due to the fact it manages the installation of the various dependencies related to these programs as well it aims to be a comprehensive assistant in setting up your intelligence gathering environment. Below is an overview of the tools and utilities it will help you set up.

+-----------------------+-------------------------------------------+
| Tool | Utility type and feature summary |
+-----------------------+-------------------------------------------+
|1. QuickScan | Port Scanner/WHOIS/Domain Resolver |
|2. DNSRecon | Advanced DNS Enumeration & Domain Utility |
|3. Sublist3r | OSINT Based Subdomain Enumeration |
|4. TekDefense-Automator| OSINT Based IP, URL and Hash Analyzer |
|5. TheHarvester | eMail, vHost, Domain and PII Enumeration |
|6. IOC-Parser | Threat Intel, parses IOC data from reports|
|7. PyParser-CVE | Multi Source Exploit Parser/CVE Lookup |
|8. Mimir | HoneyDB CLI/Threat Intelligence Utility |
|9. Harbinger | Cymon.io, Virus Total, Threat Feed Parser |
|10.Spiderfoot | Advanced OSINT/Reconnaissance Framework |
+-----------------------+-------------------------------------------+
Furthermore I have included functionality within the Bash script that allows the user to easily pull up two web based resources. Namely OSINT-Framework and HoneyDB. The former serves as a curated list of open source intelligence tools, websites and related materials for use as a reference guide. While the latter is an OSINT aggregative threat intelligence pool that collects and organizes data provided by HoneyPy honeypots. My Command Line Interface for which is included in the selection of tools available for download with IntRec-Pack as well.

Usage
Clone the tool from the repo and make it executable like so.
git clone https://github.com/NullArray/IntRec-Pack.git
cd IntRec-Pack
chmod +x intrec.sh
After which it can be started from the command line with sudo ./intrec.sh. Upon doing so you will be presented with a menu the options for which are as follows:
1) Help                  4) Specify Install Location
2) List and Install 5) Online Resources
3) Install All 6) Quit
The help option displays further usage information and general details about the tool. List and Install will list all the tools available for download/installation and lets you select the ones you would like. Upon doing so the tool plus it's dependencies will be installed in the current working directory. Unless the Specify Install Location option has been used to provide a path to a custom location. Install All will download and install all the tools available with this script and Online Resources will open the web applications previously mentioned.

Update
The script has been updated to version 1.0.1.

Changelog
Each installation operation now has its own function in order to make the script modular. This will also allow for the easy addition of operations that would install other/more tools in the future.
Additional checks have been added to the script in order to look for the presence of utilities such as wget, git and pip. This is important because some distros such as Debian and Devuan do not come with some of these utilities installed by default. Should the script find any of these utilities are missing it will attempt to automatically resolve the issue. Making the script effective and compatible with most Debian based distros.
From now on IntRec-Pack will check to see if it has been started with super user privilege. Since there are a lot of sudo commands in the script this will prevent the user from running into trouble halfway through the execution.


IntRec-Pack - Intelligence and Reconnaissance Package/Bundle installer

The Port Scan Attack Detector psad is a lightweight system daemon written in is designed to work with Linux iptables/ip6tables/firewalld firewalling code to detect suspicious traffic such as port scans and sweeps, backdoors, botnet command and control communications, and more. It features a set of highly configurable danger thresholds (with sensible defaults provided), verbose alert messages that include the source, destination, scanned port range, begin and end times, TCP flags and corresponding nmap options, reverse DNS info, email and syslog alerting, automatic blocking of offending IP addresses via dynamic configuration of iptables rulesets, passive operating system fingerprinting, and DShield reporting. In addition, psad incorporates many of the TCP, UDP, and ICMP signatures included in the Snort intrusion detection system. to detect highly suspect scans for various backdoor programs (e.g. EvilFTP, GirlFriend, SubSeven), DDoS tools (Mstream, Shaft), and advanced port scans (SYN, FIN, XMAS) which are easily leveraged against a machine via nmap. psad can also alert on Snort signatures that are logged via fwsnort, which makes use of the iptables string match extension to detect traffic that matches application layer signatures. As of the 2.4.4 release, psad can also detect the IoT default credentials scanning phase of the Mirai botnet.
The complete feature list is below.

Features
  • Detection for TCP SYN, FIN, NULL, and XMAS scans as well as UDP scans.
  • Support for both IPv4 and IPv6 logs generated by iptables and ip6tables respectively.
  • Detection of many signature rules from the Snort intrusion detection system.
  • Forensics mode iptables/ip6tables logfile analysis (useful as a forensics tool for extracting scan information from old iptables/ip6tables logfiles).
  • Passive operating system fingerprinting via TCP syn packets. Two different fingerprinting strategies are supported; a re-implementation of p0f that strictly uses iptables/ip6tables log messages (requires the --log-tcp-options command line switch), and a TOS-based strategy.
  • Email alerts that contain TCP/UDP/ICMP scan characteristics, reverse dns and whois information, snort rule matches, remote OS guess information, and more.
  • When combined with fwsnort and the iptables string match extension, psad can generate alerts for application layer buffer overflow attacks, suspicious application commands, and other suspect layer 7 traffic.
  • Icmp type and code header field validation.
  • Configurable scan thresholds and danger level assignments.
  • Iptables ruleset parsing to verify "default drop" policy stance.
  • IP/network danger level auto-assignment (can be used to ignore or automatically escalate danger levels for certain networks).
  • DShield alerts.
  • Auto-blocking of scanning IP addresses via iptables/ip6tables and/or tcpwrappers based on scan danger level. (This feature is NOT enabled by default.)
  • Parsing of iptables/ip6tables log messages and generation of CSV output that can be used as input to AfterGlow. This allows iptables/ip6tables logs to be visualized. Gnuplot is also supported.
  • Status mode that displays a summary of current scan information with associated packet counts, iptables/ip6tables chains, and danger levels.

Visualizing Malicious Traffic
psad offers integration with gnuplot and afterglow to produce graphs of malicious traffic. The following two graphs are of the Nachi worm from the Honeynet Scan30 challenge. First, a link graph produced by afterglow after analysis of the iptables log data by psad:
"Nachi Worm Link Graph"

The second shows Nachi worm traffic on an hourly basis from the Scan30 iptables data:
"Nachi Worm Hourly Graph"

Configuration Information
Information on config keywords referenced by psad may be found both in the psad(8) man page, and also here:
http://www.cipherdyne.org/psad/docs/config.html

Methodology
All information psad analyzes is gathered from iptables log messages. psad by default reads the /var/log/messages file for new iptables messages and optionally writes them out to a dedicated file (/var/log/psad/fwdata). psad is then responsible for applying the danger threshold and signature logic in order to determine whether or not a port scan has taken place, send appropriate alert emails, and (optionally) block offending ip addresses. psad includes a signal handler such that if a USR1 signal is received, psad will dump the contents of the current scan hash data structure to /var/log/psad/scan_hash.$$ where "$$" represents the pid of the running psad daemon.
NOTE: Since psad relies on iptables to generate appropriate log messages for unauthorized packets, psad is only as good as the logging rules included in the iptables ruleset. Hence if your firewall is not configured to log packets, then psad will NOT detect port scans or anything else. Usually the best way setup the firewall is with default "drop and log" rules at the end of the ruleset, and include rules above this last rule that only allow traffic that should be allowed through. Upon execution, the psad daemon will attempt to ascertain whether or not such a default deny rule exists, and will warn the user if not. See the FW_EXAMPLE_RULES file for example firewall rulesets that are compatible with psad.
Additionally, extensive coverage of psad is included in the book "Linux Firewalls: Attack Detection and Response" published by No Starch Press, and a supporting script in this book is compatible with psad. This script can be found here:
http://www.cipherdyne.org/LinuxFirewalls/ch01/

Installation
Depending on the Linux distribution, psad may already be available in the default package repository. For example, on Debian or Ubuntu systems, installation is done with a simple:
apt-get install psad
If psad is not available in the package repository, it can be installed with the install.pl script bundled in the psad sources. The install.pl script also handles upgrades if psad is already installed. psad requires several perl modules that may or may not already be installed on your Linux system. These modules are included in the deps/ directory in the psad sources, and are automatically installed by the install.pl script. The list of modules is:
  • Bit::Vector
  • Date::Calc
  • IPTables::ChainMgr
  • IPTables::Parse
  • NetAddr::IP
  • Storable
  • Unix::Syslog
psad also includes a whois client written by Marco d'Itri (see the deps/whois directory). This client does better than others at collecting the correct whois information for a given IP address.

Firewall Setup
The main requirement for an iptables configuration to be compatible with psad is simply that iptables logs packets. This is commonly accomplished by adding rules to the INPUT and FORWARD chains like so:
iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
The rules above should be added at the end of the INPUT and FORWARD chains after all ACCEPT rules for legitimate traffic and just before a corresponding DROP rule for traffic that is not to be allowed through the policy. Note that iptables policies can be quite complex with protocol, network, port, and interface restrictions, user defined chains, connection tracking rules, and much more. There are many pieces of software such as Shorewall and Firewall Builder, that build iptables policies and take advantage of the advanced filtering and logging capabilities offered by iptables. Generally the policies built by such pieces of software are compatible with psad since they specifically add rules that instruct iptables to log packets that are not part of legitimate traffic. Psad can be configured to only analyze those iptables messages that contain specific log prefixes (which are added via the --log-prefix option), but the default is for psad to analyze all iptables log messages for evidence of port scans, probes for backdoor programs, and other suspect traffic.

Platforms
psad generally runs on Linux systems, and is available in the package repositories of many major Linux distributions. If there are any operational issues with psad, please open an issue on psad

psad - Intrusion Detection and Log Analysis with iptables


Nzyme collects 802.11 management frames directly from the air and sends them to a Graylog (Open Source log management) setup for WiFi IDS, monitoring, and incident response. It only needs a JVM and a WiFi adapter that supports monitor mode.

Think about this like a long-term (months or years) distributed Wireshark/tcpdump that can be analyzed and filtered in real-time, using a powerful UI.

If you are new to the fascinating space of WiFi security, you might want to read my Common WiFi Attacks And How To Detect Them blog post.

A longer blog post with nzyme examples and use-cases is published on: Introducing Nzyme: WiFi Monitoring, Intrusion Detection And Forensics

What kind of data does it collect?
Nzyme collects, parses and forwards all relevant 802.11 management frames. Management frames are unecrypted so anyone close enough to a sending station (an access point, a computer, a phone, a lightbulb, a car, a juice maker, ...) can pick them up with nzyme.
  • Association request
  • Association response
  • Probe request
  • Probe response
  • Beacon
  • Disassociation
  • Authentication
  • Deauthentication

What do I need to run it?
Everything you need is available from Amazon Prime and is not very expensive. There even is a good chance you have the parts around already.

One or more WiFi adapters that support monitor mode on your operating system.
The most important component is one (or more) WiFi adapters that support monitor mode. Monitor mode is the special state of a WiFi adapter that makes it read and report all 802.11 frames and not only certain management frames or frames of a network it is connected to. You could also call this mode sniffing mode: The adapter just spits out everything it sees on the channel it is tuned to.
The problem is, that many adapter/driver/operating system combinations do not support monitor mode.
The internet is full of compatibility information but here are the some adapters we can run nzyme with on a Raspberry Pi 3 Model B:
  • ALFA AWUS036NH - 2.4Ghz and 5Ghz (Amazon Prime, about $40)
  • ALFA AWUS036NEH - 2.4Ghz (Amazon Prime, about $50)
  • ALFA AWUS036ACH - 2.4Ghz and 5Ghz (Amazon Prime, about $50)
  • Panda PAU05 - 2.4Ghz (Amazon Prime, about $15)
If you have another one that supports monitor mode, you can use that one. Nzyme does by far not require any specific hardware.

A small computer to run nzyme on.
It's recommended to run nzyme on a Raspberry Pi 3 Model B. This is pretty much the reference architecture, because that is what I run it on. A Raspberry Pi 3 Model B running Nzyme with three WiFi adapters in monitor mode has about 25% CPU utilization in the busy frequencies of Downtown Houston, TX.
In the end, it shoulnd’t really matter what you run it on, but the docs and guides will most likely refer to a Raspberry Pi with a Raspbian on it.

A Graylog setup
You need a Graylog setup with ah GELF TCP input that is reachable by your nzyme sensors. GELF is a Graylog-specific and structured log format. Because nzyme sends GELF, you don't have to set up any kind of parsing rules in Graylog and still have all fields available as key:value pairs for powerful search and analysis.
You can start a GELF input for nzyme using your Graylog Web Interface. Navigate to System -> Inputs, select GELF TCP in the dropdown menu and hit Launch new input. A modal dialog will open and ask you a few questions about, for example, which address to bind on and what port to use. The input will be immediately available for nzyme after pressing Save.


Channel hopping
The 802.11 standard defines many frequencies (channels) a network can operate on. This is useful to avoid contention and bandwidth issues, but also means that your wireless adapter has to be tuned to a single channel. During normal operations, your operating system will do this automatically for you.
Because we don’t want to listen on only one, but possibly all WiFi channels, we either need dozens of adapters, with one adapter for each channel, or we cycle over multiple channels on a single adapter rapidly. Nzyme allows you to configure multiple channels per WiFi adapter.
For example, if you configure nzyme to listen on channel 1,2,3,4,5,6 on wlan0 and 7,8,9,10,11 on wlan1, it will tune wlan0 to channel 1 for a configurable time (default is 1 second) and then switch to channel 2, then to channel 3 and so on. By doing this, we might miss a bunch of wireless frames but are not missing out on some channels completely.
The best configuration depends on your use-case but usually you will want to tune to all 2.4 Ghz and 5 Ghz WiFi channels.
On Linux, you can get a list of channels your WiFi adapter supports like this:
$ iwlist wlan0 channel
wlan0 32 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 12 : 2.467 GHz
Channel 13 : 2.472 GHz
Channel 14 : 2.484 GHz
Channel 36 : 5.18 GHz
Channel 38 : 5.19 GHz
Channel 40 : 5.2 GHz
Channel 44 : 5.22 GHz
Channel 46 : 5.23 GHz
Channel 48 : 5.24 GHz
Channel 52 : 5.26 GHz
Channel 54 : 5.27 GHz
Channel 56 : 5.28 GHz
Channel 60 : 5.3 GHz
Channel 62 : 5.31 GHz
Channel 64 : 5.32 GHz
Channel 100 : 5.5 GHz
Channel 102 : 5.51 GHz
Channel 104 : 5.52 GHz
Channel 108 : 5.54 GHz
Channel 110 : 5.55 GHz
Channel 112 : 5.56 GHz
Current Frequency:2.432 GHz (Channel 5)

Things to keep in mind
A few general things to know before you get started:
  • Success will highly depend on how well supported your WiFi adapters and drivers are. Use the recommended adapters for best results. You can get them from Amazon Prime and have them ready in one or two days.
  • At least on OSX, your adapter will not switch channels when already connected to a network. Make sure to disconnect from networks before using nzyme with the on-board WiFi adapter. On other systems, switching to monitor mode should disconnect the adapter from a possibly connected network.
  • Nzyme works well with both the OpenJDK or the Oracle JDK and requires Java 7 or 8.
  • Wifi adapters can draw quite some current and I have seen Raspberry Pi 3’s shut down when connecting more than 3 ALFA adapters. Consider this before buying tons of adapters.

Testing on a MacBook
(You can skip this and go straight to a real installation on a Raspberry Pi or install it on any other device that runs Java and has supported WiFi adapters connected to it.)

Requirements
Nzyme is able to put the onboard WiFi adapter of recent MacBooks into monitor mode so you don’t need an external adapter for testing. Remember that you cannot be connected to a wireless network while running nzyme, so the Graylog setup you send data to has to be local or you need a wired network connection or a second WiFi adapter as LAN/WAN uplink.
Make sure you have Java 7 or 8 installed:
$ java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Download and configure
Download the most recent build from the Releases page.
Create a new file called nzyme.conf in the same folder as your nzyme.jar file:
nzyme_id = nzyme-macbook-1
channels = en0:1,2,3,4,5,6,8,9,10,11
channel_hop_command = sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport {interface} channel {channel}
channel_hop_interval = 1
graylog_addresses = graylog.example.org:12000
beacon_frame_sampling_rate = 0
Note the graylog_addresses variable that has to point to a GELF TCP input in your Graylog setup. Adapt it accordingly.
Please refer to the example config in the repository for a more verbose version with comments.

Run
After disconnecting from all WiFi networks (you might have to "forget" them in the macOS WiFi settings), you can start nzyme like this:
$ java -jar nzyme-0.1.jar -c nzyme.conf
18:35:00.261 [main] INFO horse.wtf.nzyme.Main - Printing statistics every 60 seconds. Logs are in [logs/] and will be automatically rotated.
18:35:00.307 [main] WARN horse.wtf.nzyme.Nzyme - No Graylog uplinks configured. Falling back to Log4j output
18:35:00.459 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [en0]
18:35:00.474 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [en0] acquired. Cycling through channels <1,2,3,4,5,6,8,9,10,11>.
18:35:00.483 [nzyme-loop-0] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [en0] ... (⌐■_■)–︻╦╤─ – – pew pew
Nzyme is now collecting data and writing it into the Graylog input you configured. A message will look like this:

Installation and configuration on a Raspberry Pi 3

Requirements
The onboard WiFi chips of recent Raspberry Pi models can be put into monitor mode with the alternative nexmon driver. The problem is, that the onboard antenna is not very good. If possible, use an external adapter that supports monitor mode instead.
Make sure you have Java 7 or 8 installed:
$ sudo apt install openjdk-8-jre
$ java -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
OpenJDK Zero VM (build 25.40-b08, interpreted mode)

Download and configure
Download the most recent Debian package (.DEB) from the Releases page.
Install the package:
$ sudo dpkg -i [nzyme deb file]
Copy the automatically installed config file:
$ sudo cp /etc/nzyme/nzyme.conf.example /etc/nzyme/nzyme.conf
Change the parameters in the config file to adapt to your WiFi adapters, Graylog GELF input (See What do I need to run it? -> A Graylog setup and use-case. The file should be fairly well documented and self-explanatory.
Now enable the nzyme service to make it start on boot of the Raspberry Pi:
$ sudo systemctl enable nzyme
Because we are not rebooting, we have to start the service manually for once:
$ sudo systemctl start nzyme
$ sudo systemctl status nzyme


That's it! Nzyme should now be logging into your Graylog setup. Logs can be found in /var/log/nzyme/ and log rotation is enabled by default. You can change logging and log rotation settings in /etc/nzyme/log4j2-debian.xml.
$ tail -f /var/log/nzyme/nzyme.lo
18:11:43.598 [main] INFO horse.wtf.nzyme.Main - Printing statistics every 60 seconds. Logs are in [logs/] and will be automatically rotated.
18:11:49.611 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [wlan0]
18:12:12.908 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [wlan0] acquired. Cycling through channels <1,2,3,4,5,6,8,9,10,11,12,13,14>.
18:12:13.009 [nzyme-loop-0] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [wlan0] ... (⌐■_■)–︻╦╤─ – – pew pew
18:12:14.662 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [wlan1]
18:12:15.987 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [wlan1] acquired. Cycling through channels <36,38,40,44,46,48,52,54,56,60,62,64,100,102,104,108,110,112>.
18:12:15.992 [nzyme-loop-1] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [wlan1] ... (⌐■_■)–︻╦╤─ – – pew pew
18:13:05.422 [statistics-0] INFO horse.wtf.nzyme.Main -
+++++ Statistics: +++++
Total frames considered: 597 (92 malformed), beacon: 506, probe-resp: 15, probe-req: 76
Frames per channel: 112: 21, 1: 26, 3: 10, 4: 158, 6: 97, 8: 2, 9: 15, 10: 2, 11: 264, 12: 2
Malformed Frames per channel: 6: 1.03% (1), 8: 50.00% (1), 9: 13.33% (2), 11: 32.95% (87), 12: 50.00% (1),
Probing devices: 5 (last 60s)
Access points: 26 (last 60s)
Beaconing networks: 17 (last 60s)
18:14:05.404 [statistics-0] INFO horse.wtf.nzyme.Main -

Renaming WiFi interfaces (optional)
The interface names wlan0, wlan1 etc are not always deterministic. Sometimes they can change after a reboot and suddenly nzyme will attempt to use the onboard WiFi chip that does not support moniotr mode. To avoid this problem, you can "pin" interface names by MAC address. I like to rename the onboard chip to wlanBoard to avoid accidental usage.
This is what ifconfig looks like with no external WiFi adapters plugged in.
pi@parabola:~ $ ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:0f:0e:d4
inet addr:172.16.0.136 Bcast:172.16.0.255 Mask:255.255.255.0
inet6 addr: fe80::8966:2353:4688:c9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1327 errors:0 dropped:22 overruns:0 frame:0
TX packets:1118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:290630 (283.8 KiB) TX bytes:233228 (227.7 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:304 errors:0 dropped:0 overruns:0 frame:0
TX packets:304 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:24552 (23.9 KiB) TX bytes:24552 (23.9 KiB)

wlan0 Link encap:Ethernet HWaddr b8:27:eb:5a:5b:81
inet6 addr: fe80::77be:fb8a:ad75:cca9/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
In this case wlan0 is the onboard WiFi chip that we want to rename to wifiBoard.
Open the file /lib/udev/rules.d/75-persistent-net-generator.rules and add wlan* to the device name whitelist:
# device name whitelist
KERNEL!="wlan*|ath*|msh*|ra*|sta*|ctc*|lcs*|hsi*", \
GOTO="persistent_net_generator_end"
Reboot the system. After it is back up, open /etc/udev/rules.d/70-persistent-net.rules and change the NAME variable:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:27:eb:5a:5b:81", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlanBoard"
Reboot the system again and enjoy the consistent naming. Any new WiFi adapter you plug in, will be a classic, numbered wlan0, wlan1 etc that can be safely referenced in the nzyme config without the chance of accidentally selecting the onboard chip, because it's called wlanBoard now.
eth0      Link encap:Ethernet  HWaddr b8:27:eb:0f:0e:d4  
inet addr:172.16.0.136 Bcast:172.16.0.255 Mask:255.255.255.0
inet6 addr: fe80::8966:2353:4688:c9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:349 errors:0 dropped:8 overruns:0 frame:0
TX packets:378 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:75761 (73.9 KiB) TX bytes:69865 (68.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:228 errors:0 dropped:0 overruns:0 frame:0
TX packets:228 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:18624 (18.1 KiB) TX bytes:18624 (18.1 KiB)

wlanBoard Link encap:Ethernet HWaddr b8:27:eb:5a:5b:81
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Known issues
  • Some WiFi adapters will not report the MAC timestamp in the radiotap header. The field will simply be missing in Graylog. This is usually an issue with the driver.
  • Some Linux distributions will try to manage the network adapters for you and interfere with nzyme. For example, on Ubuntu, you have to disable NetworkManager. There is plenty of documentation for this available and I will not duplicate it. I also did not encounter this on any Raspbian based Raspberry Pi yet. The airmon-ng project has a built in way to find and kill processes that might interfere:
~# airmon-ng check
Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID Name
718 NetworkManager
870 dhclient
1104 avahi-daemon
1105 avahi-daemon
1115 wpa_supplicant

Protips

Use Graylog lookup tables
A simple CSV lookup table for Graylog can translate BSSIDs/MAC addresses to real device names for easier browsing and quicker analysis.
$ cat /etc/graylog/station-mac-addresses.csv 
"mac","station"
"82:2A:A8:07:4C:8D", "Home Main"
"2C:30:33:A5:8D:94", "Home Extender"
A message with translated fields could look like this:

CLI parameters
Nzyme has a few CLI parameters, some of which can be helpful for debugging.
  • --config-file, -c
    • Path to config file. This is the only required parametr.
  • --debug, -d
    • Override Log4j configuration and start with log level DEBUG.
  • --trace, -t
    • Override Log4j configuration and start with log level TRACE.
  • --packet-info, -p
    • Print simple packet size information for every frame that is received.
As an example for CLI parameter usage, here is how to start nzyme in debug mode with packet information printing:
java -jar nzyme.jar --debug --packet-info 

Legal notice
Make sure to comply with local laws, especially with regards to wiretapping, when running nzyme. Note that nzyme is never decrypting any data but only reading unencrypted data on license-free frequencies.


Nzyme - Collects 802.11 Management Frames And Sends Them To A Graylog Setup For Wifi Ids, Monitoring, And Incident Response


This is the initial release for FruityC2 (alpha version). Can be installed on any linux system, but the installation scripts are made for Debian based systems. There are a lot of functionalities that will be include in future releases, and probably a lot of code will be changed, but this version is enough to show FruityC2.

FruityC2 is a post-exploitation (and open source) framework based on the deployment of agents on compromised machines. Agents are managed from a web interface under the control of an operator.

It works as a command-and-control model and is language and system agnostic. New agents are being developed to expand the capabilities and options for FruityC2.

A web client is used to interact with the FruityC2 API in a client/server mode. The client is a single web page divided into 5 sections: Interact, Listener, Payload, Delivery, Config. These options provide full control and access to the functions included in FruityC2 to create, deliver and interact with a functioning C2 capability.

During the development of the initial alpha version, I divided the efforts between the client and the server, but mainly on the client.
The next steps are to improve the Stager and Agent, add more functionalities and commands, and I will start developing new stagers and agents for other OS systems.
Note: The current Stager and Agent can be only executed on Windows (powershell), but this will be extended in future releases to other systems and file types.

Install

Method 1: Standard installer (Server)
script: install.sh
Note: you need to download the master.zip file or to clone the repository (FruityC2).

Method 2: Standalone installer (Server and Client)
script: install-standalone.sh
  • You need Debian (or based) installed (or a Live CD version) to use this script.
  • Download installer-standalone.sh from https://github.com/xtr4nge/FruityC2/
  • run install-standalone.sh (It will downlaod and install all the dependencies, FruityC2 and FruityC2-Client)
  • Done.

FruityC2 Server
Edit the file config/settings.conf and add the IP (from where FruityC2-Client will be used) in section:
[souce][[control]
allow = '127.0.0.1', '10.0.0.1', 'fruityc2-client-ip'

Then run
./FruityC2.py
Note: To use FruityC2 you need FruityC2-Client. You don't need a webserver to use FruityC2-Client, just open index.html.

FruityC2-Client Wiki
https://github.com/xtr4nge/FruityC2-Client/wiki

Extra Scripts

download-modules-extra.sh
This script can be used to download extra modules from the projects: Empire, PowerSploit, PowerShell-AD-Recon and Nishang

reset.sh
This script can be used to backup the data, logs and config files to then reset the server data.


FruityC2 - Post-Exploitation Tool to Manage Compromised Machines from a Web Interface