I've been working on developing a custom cybersecurity home lab to practice implementing and utilizing defensive measures against cybersecurity risks.
Please check out part 1 if you haven’t already.
For Security Onion, I’m monitoring traffic on a SPAN port that captures data from both the LAN and corporate interfaces, allowing me to passively listen in without actively being part of the interfaces.
Practice #1
I've generated some suspicious internal traffic from the attacker machine. On Security Onion, I can see that some rules have been triggered.
Based on the alerts, it appears that multiple Nmap scans were conducted. By clicking on each alert, I can view the individual events within the grouped detection.
By expanding any of the alerts, I can see much more detail. Here, the attacker machine is trying to attack a device on the corporate network with the IP 192.168.3.2.
The alert includes the rule that was triggered. The rule is designed to detect any HTTP traffic from the internal network to any destination, regardless of the port used. It also requires that the User-Agent header starts with “Mozilla/5.0 (compatible|3b| Nmap scripting engine”. the |3b| represents a semicolon.
Under network.data.decoded, the triggering traffic is visible, including the header that meets the rule conditions. Nmap here is requesting the HNAP1 path.
If I want some more context, I can switch to the packet capture. I can see that the endpoint responded by saying the /HNAPI path does not exist. The header also reveals the server is running Microsoft’s HTTP API.
Since this reconnaissance attempt is happening internally, this alert would require investigation. I can escalate it by adding it to Cases and providing it the relevant information.
By filtering by the attacker’s IP address, I observed multiple suspicious port connection attempts resulting from Nmap scans. These findings should be documented and added to the previously created case.
practice #2
For this practice, I imported test traffic into Security Onion.
Below, a rule named “ET Malware Zbot Post Request to C2" was triggered.
The rule that was triggered defines when a connection from an internal network reaches out to the external network on any ports. It also checks for any established HTTP flow for particular headers.
Upon analyzing the packet capture, I observed a client sending a POST request to a PHP site using an outdated IE 6.0 user agent, which is suspicious. The destination host, ishi-bati.com, raises further concerns due to its unusual name.
I can also see that there is an established connection that is sending encrypted traffic back and forth.
This definitely looks suspicious so I will escalate this alert into a Case.
If I dig further into the source IP, I can find quite a few more alerts.
From the alerts, there seems to be a suspicious Windows EXE or DLL file download. Looking further into those alerts, I can confirm its an exe due to the “MZ” and “this program cannot be run in DOS mode”.
To gather detailed information about this specific network flow, I will correlate the network.community_id with the corresponding zeek.conn records, which store data about network connections. This will help identify the associated Windows executable, including its hash value.
By submitting the hash to VirusTotal, I can see that it corresponds to Zbot malware which is a family of Trojans known for stealing personal and financial information.
This device should immediately be isolated. For formal record keeping and management, I will escalate this alert to the Case we created earlier.
I can then add the file hash to the Observables section, which is used to track individual indicators such as IP addresses, domains, and file hashes related to the event.
Threat Hunting
What if no alerts are generated? I can use the Hunt section in Security Onion to manually look for any suspicious traffic.
For example, I want to look for HTTP traffic on non standard ports. A good starting point would be the zeek.http. Each record here contains HTTP meta data as well as destination port information.
By filtering for zeek.http logs and grouping by destination port, I can identify all destination ports along with the number of connections to each.
Interestingly enough, I see connections on port 6969. This is a common default port used for some BitTorrent connections. If I filter by body.length I can see how large the data being sent is.
This would definitely be something to look into as it could be a policy violation or something malicious.
If I filter by the destination port, I can see three corresponding logs.
By digging deeper, I can confirm that these are BitTorrent connections.
Lets investigate further by viewing this connections flows by correlating it with the network.community_id. We can now see the network, file, and http information for this P2P communication.
When I take a look at the zeek.conn and .file logs, nothing seems especially suspicious.
If I take a look at the packet capture, I can see that the source IP is reaching out to the host debian.org.
bttracker.debian.org:6969 is a public BitTorrent tracker run by the Debian project. It helps peers find each other to download Debian Linux ISOs or packages.
While the user has not connected to anything malicious, its still a possible policy violation as many organizations do not allow unauthorized P2P connections.
In the next session, I will be discussing my implementation for Nessus and how I use it in my home lab.