Assumed Breach: Because it’s not if, it’s when
We’ve all heard the phrase, “It’s not if, it’s when.” Eluding to the fact that everyone is at risk of being hacked despite the myriad of security controls that have been implemented to defend against would-be attackers and very capable and organized adversaries. Truth be told – the likelihood of experiencing an incident is very high, but part of good security hygiene is to constantly assess your investment in security to ensure that it is making a positive impact. Essentially, an effective security program means that you are becoming less of an economically viable target – the cost of pursuing a target outweighs the benefit… a discussion for another time.
When it comes to red team operations, it’s no secret that we are operating on a fixed schedule and likely under some restrictions in regard to types of activities that can be carried out. The adversary has no such restrictions. They pursue a target based on their mission objectives. They do not operate under strict rules of engagement, and the schedule… well… that’s just it. It’s not several weeks or just a few months, and it is not at the budgetary discretion of their client. They could be working for many months on end – possibly just performing discovery and weakness identification.
Providing value on an assessment is key, but that does not mean that an entire red team operation should be purely focused on gaining initial access. There is value in “getting in,” but to exhaust an entire engagement schedule on initial access provides little value to the client. That’s where assumed breach comes in.
Assumed breach is an approach where we consider that at some point in time, the bad guys WILL get in, so we need to identify what post-exploitation activities can be conducted in order to achieve the mission objectives. We also want to determine gaps in the program, security technology, and operational throughput of the blue team.
Clearing the Air – Making the Case for Assumed Breach
I have read a number of articles claiming that “Assumed breach isn’t effective,” and that organizations can just patch, use MFA, and train their employees to prevent initial access. I completely disagree with this. There is no guarantee that everyone will effectively be trained, that MFA is bulletproof (because it is not), and that patching will address all technical weaknesses. Multi-factor authentication is highly effective, patching does work, and training your users is your first line of defense – all of these things help, and they do dramatically decrease your attack surface, but take the recent Twitter hack into consideration. Insider threat anyone? How about Shitrix (CVE-2019-19781), and the dwell time on that sucker? Supply chain? Trusted relationships? Point being – You can’t account for everything, and that’s what the bad guys are counting on.
How does (should) it work?
Initial Access Threshold
Just because we are opting for Assumed Breach, doesn’t mean we don’t try for initial access. Instead, set a threshold. Set the maximum threshold by which initial access must be achieved, or… assumed breach! During that time, the attack plan and execution should follow through on any number of permitted ways of gaining initial access. To account for things like (ol’ faithful) phishing, you don’t wait an entire engagement for someone to click a link in hope of landing and expanding. Instead, you leave your hooks out there and move forward once the threshold has been reached. If you get a bite, you follow through, just as you would while trying to achieve initial access.
White Cell – Having an Insider
Having an insider is an excellent way to demonstrate insider threat, and also to plant your foothold. The white cell can do just that – a trusted person within the target organization that is acting as a coordinator or overseer of both teams. In the case of assumed breach – a malicious insider. The white cell will be responsible for pulling the trigger when the threshold for initial access is met. This can translate into many different ways. In some cases it is a matter of having them click a link, install software, implant a device, providing the red team with a valid account, or (literally) leaving a door open.
Implant – The Conduit
An implant is just that – a digital asset that is used to provide access to the red team. An implant can take several forms, and the reason for it being brought up in this post, is so that folks can get an idea of what makes the most sense based on their objectives. For instance – Hardware (Overt), Virtual Appliances (Less Overt), Software (Detectable), Valid Accounts (Clandestine). You may know of gaps in your security capabilities (specifically detection), or you may want the red team to take the vantage of a clandestine insider that has some degree of access. It all depends on the need.
Getting value out of a red team operation is key. Otherwise, you could find yourself in a situation where you think that everything is copacetic based on the mere fact that the red team did not achieve initial access. Achieving initial access is still critical – it should 100% be part of the engagement, but it should not be the primary focus. Determining the post-exploitation / post-compromise actions and the extent of reaching adversarial objectives is where you will realize the most value.