Testing Evasiveness with Home Lab NIDS and HIDS – Part I

As professional pen-testers we often have the luxury of not being terribly concerned with stealth. Often we will explicitly announce our IP address, plan of action and start/stop times before an engagement. “Loud” (easily detectable/ alert-triggering) tools and methods can be used and a pen-tester can find it tempting to get complacent. However, if you plan on growing as a pen-tester, it’s important to always increase the amount that you emulate a true adversary… by being evasive.

Evasion encompasses every form of technique that bypass firewalls, defeats malware analysis, conceals identity, covers tracks and counters NIDS/NIPS (network-based intrusion detection/prevention systems) and HIDS (Host-based intrusion detection systems). In this post we will focus on setting up a NIDS and monitoring traffic we generate. Setting up your own private network environment to see whats being seen on the other side of your commands is both invaluable and thanks to cloud services and open-source NIDS/NIPS, easy. This post does largely presume you are familiar with Kali Linux, Digital Ocean and nmap.

The contents of part I:

  • Installing, configuring and using the Snort NIDS on a regular (internet facing) droplet
  • Testing various nmap scans against our Snort droplet

The contents of part II:

  • Enabling private networking on droplets VPC (Virtual private cloud)
  • Installing, configuring and using the WAZUH HIDS manager and agent on a private network
  • Testing various nmap scans against our WAZUH droplet

Installing, configuring and using Snort on a regular (internet facing) droplet

First we spin up a new droplet. I spun up a Debian 10.3 x64 image with the lowest tier ($5/month) plan (if not sure how to do that here is a terrific walk-through). One thing that walk-through wont tell you is all of the different things a droplet needs when its first called into existence. Here is a list of commands I immediately throw at a new droplet in the order I throw them. They are not all related to installing Snort, I just hate not having these on a machine. Throw these in a bash script or use the ones you like.

apt-get update
apt-get install apache2
apt install php
a2enmod ssl
apt install python-certbot-apache
apt install git
apt install locate
apt install nmap 
apt install curl
apt install dnsutils

Now we install Snort. The Snort site is an even better resource than one might expect for all Snort information and right there on page one is a list of options for downloading. However, they are unnecessary. We’re just going to use apt-get

apt-get install snort

As soon as that gets done and before we touch anything, we’re going to verify things went to plan by testing/reporting on current configuration with the -T command:

snort -T -c /etc/snort/snort.conf -i eth0
  • -T = test/report on current configuration
  • -c = use rules file /etc/snort/snort.conf
  • -i = interface
Verify Configuration

Now that that’s done we can actually run Snort and start to see some internet spiders and scanners as our new droplet is hit

snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth0
  • -A = Set alert mode: fast, full, console, test or none (alert file alerts only)
  • -q = Quiet. Don’t show banner and status report
  • -u = Run snort uid as user (or uid) after initialization
  • -g = Run snort gid as group (or gid) after initialization

As soon as our box start getting hits we start to see how the default rules work and what the output looks like. This is the output of my Kali box scanning my Snort droplet with a standard nmap -sC -sV scan:

Its a little tough to see in the screenshot but the readout is straight forward. I have highlighted some of the more interesting components of the output because they will be our focus. Within Snorts classification.config rules file are these short-names, descriptions and an assigned default priority rating from 1-4. 1 is the highest priority and much of the time means a verified attempted or successful attack. 4 is the lowest and anything assigned a 4 isn’t presented to console or recorded.

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: inappropriate-content,Inappropriate Content was Detected,1
config classification: policy-violation,Potential Corporate Privacy Violation,1
config classification: default-login-attempt,Attempt to login by a default username and password,2
config classification: sdf,Senstive Data,2
config classification: file-format,Known malicious file or file based exploit,1
config classification: malware-cnc,Known malware command and control traffic,1
config classification: client-side-exploit,Known client side exploit attempt,1

This is the default configuration and can obviously be changed according to an organizations priorities with little effort. This one is useful and succinct to look over here but there are other rules conf file examples that can be found on the Snort site here. Though the exact guidelines for how organizations set their rules are jealously guarded, it is common knowledge that they will generally have rules set to a more relaxed state than the default configuration, at least in reference to the perimeter. This may sound counter intuitive that a company would have looser rules, but as you’ll see when you start Snort on your internet facing droplet, there are attacks and attempted information leaks occurring at all times. Consequently, the need to loosen what constitutes an alert-worthy event.

Internal networks protected by HIDS (Host-based Intrusion Detection Systems) discussed more in part 2, are often far more stringent than the default configuration, picking up on the slightest anomalies in their baseline traffic. The most mature organizations will set rules to hastily alert them of any traffic deemed out or the ordinary on the specific infrastructure they’re installed. For more information on the workings of these tools refer here.

With this in mind, I recommend starting to test what comes out on Snort’s end by gradually increasing the loudness of your nmap scans against the droplet. Below are a list of commands that increase in noise as you go down

nmap -sT -p80,443 -T2 -Pn <droplet IP>
nmap -sT --top-ports=10 -T2 -Pn <droplet IP>
nmap -sT --top-ports=100 -T2 -Pn <droplet IP>
nmap -sT --top-ports=100 -sV -T2 -Pn <droplet IP>
nmap --version-intensity=0 --max-hostgroup=50 --min-rate=150 --max-retries=2 --initial-rtt-timeout=50ms --max-rtt-timeout=200ms --max-scan-delay=5 -Pn -sS -sV -sU -p T:1-65535,U:53,67-69,111,123,135,137-139,161-162,445,500,514,520,631,996-999,1434,1701,1900,3283,4500,5353,49152-49154 <droplet IP>
nmap -A -Pn -p1-65535 --max-retries=0 <droplet IP>

You may be surprised, as I was, with what is flagged with a priority 3 (misc activity) versus whats flagged as priority 2 (attempted information leak). It appears that sometimes a command fabricated specifically to be surgical, unobtrusive and undetected gets flagged as a higher priority than a noisy, clumsy scan that is interpreted as one of the Internet’s many mindless spiders. It’s in these findings that make this entire process worth doing; to get an idea of how we’re seen on the other side.

You’re ready to play around with the Snort NIDS and see what’s picked up. In part II, we use WAZUH HIDS in a VPC to simulate a grey box/ internal engagement where you are inside a network performing the test. We’re using WAZUH, which is a fork of the popular open-source OSSEC (Open Source Security) HIDS. This is because I could have written another blog post on troubleshooting for OSSEC alone. There seems to be a number of library compatibility issues, one after another, for our Debian based droplets. WAZUH claims it is “a much more comprehensive, easy to use, reliable, scalable, and free open source solution.” As I was able to get it up and running from no more than its installation page commands, those claims are holding up so far.

Please do not hesitate to give whatever feedback you can on how I can improve on the subjects I cover, I would appreciate that. See you for part II

Wireless Security Assessment of an Organization

Image result for wireless assessment

Having recently completed a wireless network security assessment of an organization, I thought it useful to document the steps and tools I used on the engagement. This write-up largely covers the passive phase of discovering SSIDs in use within the client’s network, identify access points in use, and then finishing this phase with traffic analysis and wireless profiling. It is in this phase that we evaluate the cryptographic strength of the encryption algorithms in use along with any additional security controls in place.

After the passive phase comes the attack scenario, but that is going to be out of scope for this write-up. Instead, we’ll focus on the hardware and terminal commands and tools used to gather the information needed to carry out the attack scenario afterwards.

First, everything I’ll be doing will be using a Kali iso within VMware. Not my usual go-to Kali instance though. This is a Kali VM I use solely for wireless assessments and I try to change it as little as possible after I tweak it to work. This wont keep out every gremlin, but it makes things a little easier. Wireless tools are finicky, and different drivers, tool versions, chipsets and settings can lead to hours of troubleshooting. This is especially troublesome as a lot of what you do on wireless engagements is very time sensitive.

For hardware, I used the panda wireless PAU09 card. Its been a great little tool and is widespread and highly recommended in the community. Also they are fairly inexpensive so its not difficult to grab 2 or 3 of these, though for this assessment I used only one.

Image result for panda wireless pau09
Panda Wireless PAU09

To set this up, simply plug it in to the port > navigate to the virtual machine tab in the menu bar of your Kali VMware > select USB & Bluetooth > select Ralink USB (it comes up as that for some reason). Now to test it and see if your computer is seeing the device.


This command will list out the devices and if you see your device (Ralink Technology Group in the case of my panda card) you are one step closer. Now to see if it can connect to the proper interface


This command will allow you to display/ change parameters of the network interface. When typed in, you should see lo displays no wireless connections, eth0 displays no wireless connection, and you should now see wlan0 as displaying the name of your device. If you don’t see that, I’m so sorry, troubleshooting must begin now and at this stage its probably linked to your drivers or settings of your VM.


Now we use airmon-ng in order to check and make sure there are no services that will interfere with the panda. Run the command:

airmon-ng check

There is likely to be services that are shown with airmon-ng check. Especially if the reader is using a fresh install of Kali. So you will very likely need to run airmon-ng check kill to conveniently kill these services:

airmon-ng check kill

Now we start airmon-ng with the start command followed by the interface created by the panda:

airmon-ng start wlan0


Now that we have our wireless cards working we can start up Kismet, the “wireless network and device detector, sniffer, wardriving tool, and WIDS (wireless intrusion detection) framework.” For this write-up, though it be published well into the 2020’s where there exists a newer version of Kismet, you may find in that there are a lot of professionals in the industry that still prefer the older version, found here:


The reason being that there are certain important filter options present in the older version that the newer version’s web UI lacks, ergo, we will be using the legacy version in this walk-through. After installing kismet we have to set the ncsource to wlan0 by un-commenting it in the conf file:

vim /etc/kismet/kismet.conf

un-commenting out ncsourse

Now kismet has our permission to help itself to the wlan0 interface. The first command we’ll use after we install Kismet is:

kismet -n

This command will start up kismet but the -n flag will keep it from logging the information it gathers. This is useful for setting up kismet and troubleshooting if need be without needlessly creating dozens of logs to confuse us later.

Navigating kismet is easy, just use the ~ to jump up to the main menu and use arrows to determine choices from there.

You will find your display varies from mine. This is because I have customized my columns to give me the information I deem most valuable for the engagement. You can do the same with ~ > Kismet > preferences > network columns. From here you can set what you want displayed and in what order with space to toggle On/off and +/- to change order of appearance. My preferences are shown below:

Now we’re ready to start the real analysis. On an engagement you will likely have several networks in scope to be looking for and these will appear in the SSID column. Once you have found one or all of them, take note of every channel they appear on.

For example, suppose our network in scope is CableWiFi. We find our domain in the SSID column, and then note each channel it appears on.

We note the channels 6, 149, 1 and 11. There would likely be more on a real engagement but four will serve the purpose of this example splendidly. For now kismet has served its purpose, we can power her down. We now fire up airodump-ng.


As we begin the process of narrowing our target, we start with airodump-ng to capture traffic and filter unassociated clients.

airodump-ng --ignore-negative-one -a --band ag --channel 1,6,11,149 --essid CableWiFi wlan0

–ignore-negative-one = removes message that says fixed channel wlan0: -1

-a = filters unassociated clients

–band = band on which airodump-ng should hop

–channel = specific channel to capture traffic

–essid = filter APs by ESSID

Once we initiated the command, we watch our tailored results come in and we hope to see BSSID’s that have associated clients connected. We also pay attention to the channels we see most often here when we do spot one with associated clients.

What we hope for is clients to pop in below the last line in the above image as they connect to the access points, which a necessity when seeking to carry out relay attacks, but that hasn’t happened with this demo. If it did, we would take note of the channel(s) associated with the most clients and narrow our command further:

airodump-ng --ignore-negative-one -a --band ag --channel 6 --essid CableWiFi wlan0 -w CableWiFi

-w (–write) = We now create a log file which is vital for the next component of this assessment within Wireshark.

Now we’ll leave aireplay-ng out for another time. For now, lets not focus on capturing handshakes to crack and instead on determining what ciphers and authentication key management is in place with Wireshark


We open Wireshark and open the .cap file which we saved when we used the -w flag along with a name in our airodump-ng command. Ours would be CableWiFi-01.cap for example. Now we hit the info column header to organize into groups by the info category. What we’re looking for is the probe response which is the response to our probe request. When an access point sees a probe request frame directed at the specific access point (or to all stations in the area using the broadcast SSID) it will send out a probe response. Once we find one we can select it ant then below expand IEEE 802.11 wireless LAN > tagged parameters > Tag: RSN information (robust security network). This shows us ciphers in place like TKIP or AES and if we expand Auth key management as well, we see the type, like PSK.

Photo credit to Nayarasi of mrncciew.com for a perfect example of RSN information

There is so much you can do at this point but that as far as we’ll go in this walk-through. Good luck in your pursuit of root.

Thank you to Matt B for teaching me all of this and Brett L for the PR.