In last month’s post, I wrote on how to send traffic into FortiNDR to detect malware and malicious activity. Since then I brainstormed how to pump a lot of malicious traffic through my network and ended up using a mix of FortiTester, AlphaSOC, nmap and malware samples. My goal is to see how FortiNDR detects these and how Blue Teams and SOCs can use FortiNDR to augment their ability to detect malicious activity and packages.
FortiTester is our traffic generation appliance that can emulate applications, malicious packages, and MITRE ATT&CK mapped TTPs. I configured FortiTester on my home’s unmanaged IoT network where I keep IP cameras, Smart TVs, etc. and pointed it at my Infrastructure network as the target where management for all my servers and systems reside. I’ll save a deep-dive into configuring and using FortiTester for a future post, but to keep it simple I configured FortiTester to use a range of IP addresses in the IoT network to send traffic to a range of IP addresses in the Infrastructure network. Next, I configured a traffic generation test in FortiTester using the following mix of traffic to generate 1Gbps of application traffic:
When I fired off my traffic generation test, I noticed the amount of anomaly traffic in FortiNDR spiked:
On the surface, most attackers wouldn’t be this sloppy to just start pumping traffic through the network. But FortiNDR can still be useful to pinpoint spikes in network traffic that might normally go unnoticed. Why is the network slow? I dunno, check FortiNDR.
But a better test was to fire off an IPS attack from FortiTester aimed at a FortiGate firewall. I configured FortiTester to send all of its 1,800 malicious payloads through the FortiGate and since my VMware environment on both sides of this FortiGate VM is mirroring those packets to FortiNDR, I was able to see every aspect of the attack:
4,190 network attacks detected! And they ranged from remote code execution to SQL injection, with everything in between. Most of these were blocked, as confirmed by looking at both the FortiGate logs and FortiTester’s results, but since we’re mirroring the FortiGate’s external interface we see them here regardless. Now when we drill into the Attack Scenario menu, we can see all the matching events for each attack scenario:
FortiNDR categorizes the attacks by severity and attack scenario. When we look at Critical events, we see two Fileless malware transfer attempts:
From that output, we can see the file’s MD5 hash to search with an EDR platform if it made it through. We can search FortiGuard Labs for any matches on this malware signature as well. But we can also view the sample’s info to understand it better:
In the above screenshot, we can see the history of when and where we’ve seen this file. We can see the attacker and victim information. And we can also download the file itself to reverse engineer in a sandbox and attempt to determine who wrote it and what purpose it serves.
The Host Story section of FortiNDR tells the story of the entities involved in malicious activity — both the attacker and victim. And the attack sequence is displayed in order to tell the story of what the attacker was attempting:
FortiTester sending 1,800 attacks at a victim illustrates the power of FortiNDR to detect the activity on the network and complement the visibility the EDR solution would detect on the endpoint and the visibility the SIEM solution would detect in the FortiGate logs.
One of my Fortinet peers recommended running AlphaSOC’s FlightSim to generate suspicious (though not malicious) traffic. You can download FlightSim from GitHub and run it to connect to fake C2 domains, connect to public IPs on random ports, resolve randomly generated domain names, connect to random public mail servers, etc. If you don’t specify which module to run, FlightSim will run them all which is good place to start:
Once I ran FlightSim, I went to FortiNDR to see what it alerted on. At first glance, I see a spike in Machine Learned anomalies that are suspicious connections to public IP addresses:
Next, I drill down into Device details to learn more about the attacker or compromised machine in these notifications:
In the above screenshot, I can see the IP and MAC addresses of the attacking/compromised device, but also a graph of the amount of network traffic sent/received. When navigating through more of the menus, I see the Botnet anomaly was triggered multiple times as the device of interest attempted to access Botnet domains (via the DNS server 10.0.0.20) such as miami-golf-club.com:
When we go to Network Insights > ML Discovery, we can see the list of anomalous sessions associated with an endpoint; once we view the Session Details, we can see why the session was flagged (in this case Destination IP New Address) as well any additional activity between those devices:
The session in the above screenshot is FlightSim connecting to a public mail server via SMTP. It’s the first time this endpoint has communicated to this new public mail server, so FortiNDR’s Machine Learning engine flagged it as anomalous (since we hadn’t connected to this public mail server during the 7 day machine learning period).
To see how FortiNDR detects port scans, I ran nmap on the local subnet. When I drill down into Network Attacks, I can see more details on the port scanning that was detected as well as try and determine the victim(s) being targeted:
You’ll note in the above screenshot that the Severity is Low because scanning is an early Reconnaissance phase of the MITRE ATT&CK Framework and not as severe as subsequent interactivity.
I went to Malware Bazaar to download some sample malware. We’re all adults, so please understand that downloading and executing these malware samples outside of a sandbox environment will make for a bad day. I downloaded some malware samples and then manually uploaded them to FortiNDR; a more streamlined option is to have FortiGate’s AV security profile automatically send a copy of the malware to FortiSandbox, which would then forward it to FortiNDR for a verdict.
In the screenshot above of Malware Bazaar, I chose the first RedLineStealer executable hoping that it’d be new enough to not have a widely-matching hash yet. I then uploaded the file to FortiNDR for analysis under Express Malware Analysis:
After 10 seconds or so, FortiNDR had rendered a verdict:
FortiNDR extracted the zip file and examined each file, giving each a verdict. When I drilled down into the “Banking Trojan” verdict, I saw more information such as the filename, hash and detection name:
In the above screenshot, I see that this RedLineStealer malware sample matches the W32/GenKryptik.BJQV!tr signature. I can also click on the “VT” link next to the MD5 hash to go to Virus Total and see which other engines have detected this executable as malicious.
How can I conclude a blog post on a product I’m just scratching the surface on its many use cases? Well, I’d never finish writing! That’s the thing about tinkering with solutions in a lab — you’re never finished! If you have experience with FortiNDR and how you’re using it, please leave a comment below. Thanks for reading! Andrew