NetFlow and its iterations have one goal: produce a metadata-only summary of the network flows.
There are two IDS placement types: inline and passive modes. Passive stores all the network traffic so it can perform various tasks. Inline would be pass the traffic through it, inspecting as it goes.
Presently, IDS/IPS modules are often integrated into modern firewall solutions to ensure rule blocking automations are performed on the same device.
Snort is one of the most-used IDS solutions and relies on different iterations of rulesets in both free and paid subscriptions. These rulesets define the criteria to match against when inspecting traffic.
Foundations of IDS and Rule Crafting
IDS rules are also known as signatures and need to be always evolving.
Snort rules consist of two main components: the rule header and the rule options. The header dictates the action taken, then checks any network-related data. The options are the core mechanisms of a rule and are split into two sub-categories: General Rule Options and Detection Options. General Rule options provide classification information. Detection Options implements the actual detection routine, based on the provided pattern.
To maximize performance, filter on the rule headers first.
Example Snort Rule to detect ICMP traffic
alert icmp $HOME_NET any <> $EXTERNAL_NET any ( msg:"ICMP Traffic Detected"; sid:10000001; metadata:policy security-ips alert;)
The header tells Snort to alert on ICMP traffic originating from local networks ($HOME_NET) to any external networks ($EXTERNAL_NET), in a bidirectional (<>) fashion. The rule options, surrounded by parentheses, includes the log message, the snort id, and the metadata tag.
offsec@snort01:~$ cat /var/log/snort/alert_fast.txt
10/19-07:11:26.417656 [**] [1:55703:4] "OS-WINDOWS Microsoft Windows Netlogon crafted NetrServerReqChallenge elevation of privilege attempt" [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 192.168.51.50:54810 -> 172.16.51.10:49675
...
Extra Mile I
The snort01 machine has tshark preinstalled. Replicate the zerologon pcap Snort rule analysis directly on the machine without using Wireshark.
Novel Vulnerabilities
In regards to the unknown and unrecognizable threats, there are some ways to defend still. One means of defense is implementing an allow access-list. Essentially a whitelist stating specific items are allowed.
Web application vulnerabilities can be grouped into macro categories that OWASP tracks in their popular Top 10 charts. Most attacks targeting the same macro-vulnerability have a common denominator, which means multiple generic detection rules can be crafted to catch various stages of the attack.
Utilizing the SQLi rulesets that ship with Snort, developed by the Talos group
Verifyin gthe Snort daemons and SQLi ruleset are running and being used
MD5, SHA256 or other hashed value that matches a specific file
IP Addresses
Easy
IPv4/IPv6 host address or CIDR belonging to an attacker infrastructure (i.e. a C2 server)
Domain Names
Simple
Full domain name or subdomain, often employed to dynamically resolve C2 servers IPs
Network/Host Artifact
Annoying
Any byte or distinctive traits that can be used to identify the attacker traffic
Tools
Challenging
Any piece of software that is crafted by the attacker
TTPs
Tough
Reconstruct the Tactic, Technique and Procedure (TTP) that the attacker adopt during a specific phase
C2 would typically call back to a static IP address or domain name. Because this can be easily blocked by an IPS, attackers created the domain flux technique where domains are dynamically generated at runtime through a Domain Generation Algorithm (DGA).
After launching the launcher.baton the target's desktop...
Verifying the Empire agent
(Empire) >
[+] New agent LGK4AE5C checked in
[*] Sending agent (stage 2) to LGK4AE5C at 192.168.50.40
(Empire) > agents
┌Agents──────────┬────────────┬──────────────┬──────────────────┬────────────┬──────┬───────┬─────────────────────────┬──────────┐
│ ID │ Name │ Language │ Internal IP │ Username │ Process │ PID │ Delay │ Last Seen │ Listener │
├────┼───────────┼────────────┼──────────────┼──────────────────┼────────────┼──────┼───────┼─────────────────────────┼──────────┤
│ 3 │ LGK4AE5C* │ powershell │ 172.16.50.10 │ AD\Administrator │ powershell │ 6160 │ 5/0.0 │ 2021-11-03 05:52:18 EDT │ SOC200 │
│ │ │ │ │ │ │ │ │ (3 seconds ago) │ │
└────┴───────────┴────────────┴──────────────┴──────────────────┴────────────┴──────┴───────┴─────────────────────────┴──────────┘
Extra Mile II
Try to set up a new Empire listener on Kali attacker01 in a way that cannot be detected by the Snort rule we covered in the Learning Module. Once configured, generate the Agent, test the C2 channel between server02 and attacker01, and then build a Snort rule to detect the newly-created C2.
Note: remember to restart both internal and external Snort services on snort01 in order to load the new rules.
Network Communications
Historically, attackers have used several protocols for command delivery and exfiltration to include HTTP, HTTPS, DNS, IRC, and others.
Inspecting Snort logs for Empire's HTTP communication trails
