Some would say what’s old is new again when it comes to a phrase like “breach and attack simulations”.  How is this different from vulnerability scanning, pentesting, or red teaming?  Really it’s more of a maturation of cyber security services so if your organization doesn’t currently employ a combination of vulnerability scanning, penetration testing, or red teaming then breach and attack simulations services should probably be lower on your list.

What is Breach & Attack Simulation (BAS)?

“It’s an automated  or semi-automated emulation of threat actors TTP’s (tactics, techniques, and procedures) against information systems within your organization’s environment to determine how effective your current controls would protect, detect, and defend those information systems from malicious users.”

Now there are various definitions out there but think that pretty much sums up the intent of having a service like this in place.  That may sound like what red teaming and penetration testing are meant to accomplish but they aren’t one to one and their objectives are completely different.  I’ve done this before and called it an “assumed compromise” so really it’s a play on that but calling out breach and attack simulation as a separate capability or service helps more clearly define the objective you’re going after.

So how do the services differ and what are the main goals of introducing something like an assumed compromise or breach simulation?  The quick breakdown on the differences below should help.

This break down should help delineate the services and as you’re trying to mature cyber security services within your organization and leverage the table above to highlight the benefit that a BAS would provide.  So as you’re making the case for BAS within your organization whether that’s additional head count to support the service or if it’s simply a service you’d like to introduce alongside other services the above table will point your leadership in the right direction but let’s dig deeper into the benefits of BAS.

Key Benefits of BAS

1. Cost:  Spinning up resources to perform penetration testing or red teaming requires a lot of cycles.  Wing to wing penetration tests and red team assessments can last anywhere from 3 – 6 months and involve numerous resources.  Having a BAS solution is more cost effective as it eliminates the need for additional resources plus automates the task of pentesting and red teaming activities.
2. Mimics larger set of TTP’s consistently:  Penetration Testing and Red Teaming usually only care about the end game and aren’t necessarily interested in testing the whole environment to whereas BAS will test across the board all the different scenarios that a threat actor might leverage.  This is key as red teams or pentesters may not run a particular scenario for a number of reasons but BAS would cover that and may find something others would miss.
3. Agile:  Similar to the ease of launching a vulnerability scanner against a particular target leveraging a BAS solution one should easily be able to kick off a simulation against an environment.
4. Evaluation:  Having the ability to run the simulations in almost any environment is very handy.  As most know the attack surface across the organization varies and if it were all the same then that’d be a whole lot easier to defend but we don’t live in rainbow land.  Whether it’s running BAS on a more frequent basis to test your organization’s core detection capabilities or if it’s testing it against a business function within your organization that has customized applications and configurations BAS allows you to quickly and easily evaluate your risk posture.

Beyond some of the key benefits and the differences in technologies or services BAS will afford your organization what you really want from any new offering is what it’s going to achieve.  I’ve defined and highlighted features of BAS but the main intent is to discover any cyber security controls that may be deficient in your environment so to that point what are some of the main features that BAS will employ to help identify those gaps?

• Network assessment:  The multiple attack simulations will test all the various NIDS and alerts the SOC has setup to see which ones are getting notified appropriately
• Data exfiltration:  Will test various outbound techniques to see what controls are in place to defend against attackers getting information outside your boundaries
• Lateral movement:  Can perform threat actor techniques for such things as privilege escalation and lateral movement within your network and information systems
• Endpoint assessment:  Anti-virus, end point logging, and various other technologies are there to help alert or contain a threat so BAS has features to identify any gaps that might be missing with endpoint protections
• Email gateway:  Hopefully your email gateway is working like it should to protect your organization but if not BAS has the capability to test some of the various techniques threat actors are leveraging (office docs, pdfs, .Net apps, etc.) to get passed your defenses

This list could go on for quite a while but these are some of the major categories where a BAS solution could test cyber security controls that are simply not working at all or not deployed effectively.

Anytime you’re trying to sell something new within your organization it’s probably best to think of all the questions someone will ask whether that’s being inquisitive about the solution or from a devils advocate perspective.  Leaving off the cost aspect as that will vary hopefully my points help to answer potential questions but there are some questions that you can ask to leadership or folks within your organization that might shed light on how a BAS solution can bridge those gaps.

Can we detect simple and complex threat actor attacks?

Can various types of malware be transferred through our boundaries?

Will our alerting logic correlate certain events?

How secure are we from all the various TTP’s?

Could we respond quickly enough (ransomware, worms, etc.)?

Can an attacker run code or bypass application controls undetected?

If we ran this in other environments would we see it?

These are just some of the questions that BAS is meant to help answer.  Others within your organization may be able to either fully or partially answer these questions but no one is 100% secure and as we play this cat & mouse game with adversaries that are looking to find any crack within our armor then leveraging something like a BAS solution will help us to answer those questions more definitively and better yet put a solution in place that can be better adapted as you move forward facing even greater challenges.

References

https://misti.com/infosec-insider/a-primer-on-breach-and-attack-simulations

https://www.gartner.com/doc/3875421/utilizing-breach-attack-simulation-tools

Useful link for anyone wanting to download free virtual images to test IE versions https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Encoding SQL injection attacks is nothing new and automated tools like SQLmap will more than likely find flaws via this method.  That being said I was combing through some of my old docs and found what I think is a decent explanation how this type of attack leads to SQL injection.

I’ll be demonstrating this on an app called GetBoo that is installed on the OWASP broken web app project so feel free to download the virtual image they provide and begin playing with GetBoo and other similar broken applications.  Inside GetBoo we look for some SQL injection, unauthenticated vulnerabilities are always best if you can find them. Going to the home page of GetBoo we see there are comments posted to a bookmark. Hovering over the comment link and also clicking on the comment link takes us to http://172.16.114.218/getboo/comment.php?bID=2, keep in mind your IP address will be different. In Burp let’s send this request to repeater so that we can analyze if the bID parameter is vulnerable to SQL injection. First thing we’ll want to do is throw in the classic single quote, doing this responds back with a 500 server error.

This does not mean the application is vulnerable to SQL injection but it is an indicator that the application can’t handle the single quote without failure. Let’s look at a request that handles the single quote just fine, at the home page you can click on “Popular Tags”, after that click on sort by “Popularity”. Send that request to repeater in Burp and instead of “popularity” for the sort parameter place a single quote in for the value of sort. You will notice that the application handles the request just fine with a 200 OK status.

The other classic SQL injection string ‘ or 1=1 also gives us a 500 error, most of those classic ‘ or 1=1 attacks are followed by a – which is a comment in Microsoft SQL server. In this example we’re running MySQL so if we wanted to follow it up with a commend it would look like ‘ or 1=1#.

Still getting a 500 error. Let’s try another technique which is to finish out or complete the request with a single or double quote after a valid parameter value.

So finishing off the request with a single quote and appending the and 1=1 still results in the same error. You can try the same attack without the single quote to see the affect as well.

Just because we get a 200 OK doesn’t mean that our SQL injection was successful, if you put other meaningless data besides 1=1 you may not notice a change.

Here we see it doesn’t matter what we append after a valid value for the bID parameter because the application is simply ignoring anything after, so this isn’t going to lead us down the path to SQL injection at least for this particular parameter so somehow we need to focus on finishing off the query with either the single quote or another technique.

With GetBoo installed locally you can gain access to the Mysql database logs which is extremely helpful when trying to debug a successful SQL injection attack of course in the real world this is unlikely to happen but if you want to perform better testing on your application then giving application testers access will go a long way.

Let’s go back to our single quote attack and see the output from the database query.

Here we see that it is keeping the request as we sent it. In this case if the attack string bID=2’ and 1=1 is sent you get the same output from the Mysql database logs, this means the application is discarding anything after the single quote. One way of getting around that may be to encode your attack string. This time we will URL encode our attack string, so instead of the request being bID=2’ and 1=1 it will now be bID=2 %27%20%61%6e%64%20%31%3d%31. Once we run that the following shows up in the Mysql logs.

Encoding the attack made all the difference although we still get a 500 error when making the request so we’ll need keep hammering away.

Not all is lost though because notice in the Mysql output that a single quote is appended on the 1=1 even though we didn’t specify a single quote at the end of the attack. So instead of using numeric values we need to use strings and quote those strings but leave off the final quote as the application will put that in place for us. So in this case we can use the attack string bID=2’ and ‘blah’=’blah and the URL encoded value is bID= %32%27%20%61%6e%64%20%27%62%6c%61%68%27%3d%27%62%6c%61%68.

Great success we were able to get a meaningful 200 response to our attacks. In the output from Mysql we can see that it properly parsed our attack as a valid SQL statement.

Now that we confirmed that we’re actually making proper database requests we can begin to pilfer the contents of the database.

Just a quick tip I don’t see documented a bunch of places, when you want to feed metasploit a list of targets in a file you need to use the following syntax.

Below is a screenshot for context.

Just a quick one liner, you can also incorporate this into a huge sweep of the network which will hopefully identify MySQL databases with weak or default credentials.