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 dnsutilsNow 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 snortAs 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
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
# NEW CLASSIFICATIONS
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,1This 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
pursuit_of_root 