We're changing our name.
Verodin is now Mandiant Security Validation. Click here to learn more.

Instrumenting Network Security

Because we love showing off Verodin SIP, this blog discusses what our Verodin security engineers have been building and what Verodin customers have been building around Verodin SIP Security Sequences.

August 29, 2017
Blog Tags

The biggest problem with network security is that it doesn’t provide security for your network. This isn’t because the products are necessarily bad or the team configuring those products lack training. It’s because there is rarely a validation platform in place to automatically and continuously make certain that what you’ve got is actually doing what you want.

Last week I wrote a short blog titled:  Security, Sequences, and Szechuan, where I talked about getting some of our Verodin security engineers together to discuss what they’ve been building and what Verodin customers have been building around Verodin SIP Security Sequences. Because we love showing off Verodin SIP, this blog provides the promised technical details.


Within the Verodin Security Instrumentation Platform (SIP) we have attack behaviors. These attack behaviors are used by customers to validate the effectiveness of their security stack. This is accomplished by safely measuring the impact of real attack behaviors within their production environments. In the real word, attacks are often made up of multiple behaviors, not isolated behaviors:  enter Verodin Sequences.

With Verodin SIP, sequences are attack behaviors chained together so that you can validate your security against a group of logically linked behaviors that are emblematic of what you would expect to see in real life. We want our customers to be able to run as many attack behaviors and as many sequences as they need to be safe. Because it isn’t cost-prohibitive for Verodin customers to turn on the “attack firehose,” they’ve really come up with some stellar, road tested sequences that add value and reduce risk on an ongoing basis.

I recently wrote a blog titled: Supercharge your DLP from POC to Production with SIP where I discussed how to build or use default Verodin SIP Evaluations. Like Evaluations, Sequences ship as default content and can be added by the user chaining together default actions or user-supplied actions sourced from locations like local packet captures, third-party PCAP and malware repositories, threat intelligence and ISACs. Sequences can be simple and focus on one type of threat or focus on several threats that when chained together represent what happens in the real world.

As with Verodin SIP Actions and Evaluations, Sequences operate by having Verodin Actors (VM/HW/SW/Cloud/Bootable USB) communicate with each other across network zones and in doing so measure what’s being blocked. And because the Verodin Director has API integration with SEIMs, log managers and the like, Verodin also knows what’s being detected and is creating alerts and if those alerts are being correlated.

FTP Sequence

Let’s start by building a basic sequence that is designed to evaluate if my security controls are preventing, detecting, alerting, and correlating on FTP activity to include data exfiltration. For the sake of this blog, I’m going to focus on network controls and not include endpoint security controls. We’ll hit the endpoint in future blogs.

This following sequence will check to see if my network security products such as firewalls, IPS, DLPs, proxies and related controls are working as intended if my SIEM is receiving the data and if so, if my SIEM is correlating the data and creating an event that can be responded to.

I want to build this sequence from scratch based on a few different pre-existing attack behaviors within Verodin SIP. I’m going to combine multiple related actions for this sequence that will execute between Verodin SIP network actors including:

  • Scanning for egress ports
  • Attempting Anonymous FTP
  • Attempting to upload a file containing PII
  • Attempting to upload another file containing credit card data

Note that all of the screenshots in this blog are from the Verodin SIP Director which is a management console.

As pictured below I did an initial search on Verodin SIP Actions for some TCP Scans and decided to pick “TCP Scan for Egress Ports” and added it to my Sequence with the “+Queue” button on the top right.

Now let’s add an Anonymous FTP action to the sequence. I conduct another search that yields the results below. Note how the highlighted “Queue” button now displays that I have two items in my sequence.

Now I want to add a couple data exfiltration attempts to the queue as pictured below. For the first one, I want to leverage an FTP Exfil with PII data. You can see in the image below I have a number of options including various levels of compression such a zip, double zip, zip 10 times, and different compression types like gzip, bzip2, tar, rar, and 7zip. I’m going to keep this basic with no compression and I’m going to leverage a pre-defined file (you can drag and drop to make your own) that is a 100-record .csv with PII as outlined in the highlighted description.

For my final action to add to the sequence I’m going to include exfiltration that contains credit card data, illustrated below.

Now that I have my four actions added together into a single sequence I can run this sequence between various SIP Actors to validate what’s blocked, what’s detected and alerted on, what makes it into the SIEM, and what’s correlated.

The screen capture of the results of this sequence is displayed below. We see that not only is FTP open (ports 20-21) but we have a number of clear text protocols that are being allowed through such as telnet (23), SMTP (25), DNS (53), TFTP (69) and several others.

We can also see that FTP access with the username “Anonymous” was not blocked, nor was an event created in the SIEM.

As for the data exfiltration, both .csv files – the one with PII and the one with credit card data – were allowed and didn’t generate events.

Based on these findings, we can now:

  • Modify the configurations on our network security controls to block
  • Modify the configurations on our network security controls to alert
  • Modify the configurations on our SIEM controls to correlate those alerts
  • Re-execute the sequence to validate that the configurations were made correctly
  • Set Verodin SIP to continuously monitor these parameters to ensure that what is now working, continues to work, and alert us should something that was blocking, alerting and correlating stop performing

We know exactly how our security controls will or will not react to these types of network behaviors. This also means we can get more value out of our network security controls. And best of all, through instrumentation, we have validated that our controls are now effective, operating as we want, and reducing risk.

Multipronged Attack Sequence

Now let’s look at a more detailed sequence that chains attacks together across multiple directions and multiple attack behavior domains. For this example, instead of building a sequence, we’re going to leverage a pre-defined sequence that one of our customers built and shared with the Verodin community. This sequence is now one of many default sequences within Verodin SIP.

Shown above is the Verodin Sequence “Post-Phishing Workstation & Database Compromises with Data Exfil” as seen in the highlighted box on top. Note the disparate groups on the far left.

There are three groups in this sequence.

Group 1

  • Bartalex Malware Download (This action downloads Bartalex from one Verodin SIP network actor to another)
  • Bartalex C2 Configuration Download (The targeted actor communicates with the attacking actor to be commanded)
  • Vawtrak Trojan Malware Download (Bartalex, being used as a vehicle to distribute malware, is commanded to download Vawtrak from the attacking actor)
  • Vawtrak Trojan Malware C2 Activity (The targeted actor communicates with the attacking actor to be commanded)

Group 2

  • Scan for Common Relational Databases Ports (The attacking actor looks for databases)
  • MS-SQL Database Password Hash Dump (After the attacking actor authenticates to the target actor which is acting like an MS-SQL database, the attacking actor executes the following: “SELECT * FROM master.sys.sql_logins” to steal the login information (name, password hash, etc.) of the database’s users)
  • Netsh Command Execution: Disable Windows Firewall (Using “Netsh firewall set opmode DISABLE” the attacking actor sends the target actor the network behaviors that will bring down Windows defenses)

Group 3

  • ICMP Tunnel-based Exfil/Upload of PII Data (As with the above FTP example, this actor attempts to upload a .csv file containing PII, only it’s tunneling PII from the source actor to the destination actor over ICMP for the final action of the sequence – data exfiltration)

Now we know what sequence we want to run. Next, we need to assign the actors so the actors know what parts to play during the sequence.

As shown above, the activities from the first group of the sequence will operate between the “Desktop Zone” network actor to the “Internet Zone” network actor. Note that Internet zone actors can live anywhere outside the organization’s networks to include a Microsoft or Amazon Cloud, a remote datacenter, etc.

In the screenshot above, the attack sequence is moving laterally from the network actor in the Desktop Zone to the network actor in the Server Zone.

The last part of the sequence is represented above with the Server Zone network actor attempting to tunnel data over ICMP to the Internet Zone network actor.

This sequence, in a nutshell, represents a compromised desktop user where the attack moves laterally to the more sensitive server network and finally PII to stolen and sent to the Internet.

With the actors assigned there is nothing left to do besides measure the impact of the attack behaviors that are being safely run and validate how the security products within the network are reacting to the attacks with blocking, detecting, alerting, correlating, etc.

In the screen capture below, on the right-hand side, we can see that all Bartalex and Vawtrak activity was allowed. Downloads and C2 activity are not being blocked at port or payload. However, the security products are detecting the attacks as illustrated in the events column. This means that the API integration between the Verodin Director and the SIEMs on this network received attack information.

As seen in the screenshot below, by clicking on the first Bartalex event, we find the following details which aren’t great. Both QRadar and Splunk received events that validate that something was detected and something was communicated to the SIEMs. However, in both cases, the events didn’t match a rule or search. As such, it is highly unlikely that a security analyst would ever see this. Note that in addition to the parsed event data, the actual raw data as received by both SIEMs is also displayed.

Now let’s move down to Vawtrak in the below image. If we click on the events for that action we see that QRadar and Splunk both received the events and the events matched a rule. These rules matched because when that part of the sequence was initially run, neither SIEM fired a rule. But, we were able to use the event data that showed up in the SIEM, based on running the Verodin SIP attack behaviors, to dictate what details needed to be added to the SIEM rule or search to correlate. This prescriptive capability is a huge help to anyone managing a SIEM.

Once the rule is created in the SIEM based on the exact events that will be created from this type of attack on your network, with your security controls and your configurations, those SIEM rules can be validated to ensure they work.

Imagine that, writing a rule in a SIEM and being able to know quickly and empirically if it will fire the way you want when there is an incident.   

The reaming two groups of the sequence pictured below illustrate that none of the attack activity was prevented. In a few cases, it was not even detected or at least alerts didn’t make it to the SIEMs as evidenced by no events displaying in the far-right column.

As with the previously discussed SIEM rules, tuning and re-validation can now occur. Furthermore, the preventative controls can be tuned such as IPS sigs, firewall rules, DLP configurations, etc., to not just detect these attacks, but actually prevent them.

With Verodin SIP sequences you can evaluate your entire security stack across prevention, detection, and response. While this blog is simply a high-level overview, it should be apparent how much value can be gleaned by safely measuring the impact of real attack behaviors within your production environment.

Make your security solutions work the way you want. Get the value you deserve. Don’t run security based on assuming your products are working – know their status empirically and leverage instrumentation to prescriptively help you mature your security effectiveness.

If you are interested in learning more about how Verodin SIP operates and the value security instrumentation can bring, please request a live demonstration.

Return to Blog
Get in touch:

Verodin provides security validation to measure, manage, and improve your overall effectiveness.

Chances are you’re ignoring valuable security data that can be gathered via instrumentation. Future-proof your security posture today.

Request a Demo

Chances are you’re ignoring valuable security data that can be gathered via instrumentation. Future-proof your security posture today.

Connect with an advisor

Get new cybersecurity effectiveness podcasts delivered straight to your inbox.

We will never sell or distribute your information.