The Breaches of 2023
If there was any pattern in the breaches of 2023, it was the usage of targeted organizations, mass phishing attempts, and access brokers.
Now I’m not going to cover every breach of 2023, just the ones that were the most impactful. Also, there will be an emphasis on tech companies affected, as that is what I am most familiar with. You will see some patterns in these breaches.
Snapshot of the last 18 months
BeyondTrust (Via Okta)
Cloudflare (Via Okta)
MGM Resorts
Keep in mind, generally speaking tech companies do things other companies would spit their coffee at the thought of. Practices such as
BYOD (before it was cool)
local admin
generous access control
Why you may ask?
The TLDR answer is tech companies tend to move fast. And what better way to operate and iterate than with little interruptions?
Not saying this is right, but it’s generally the way things have been. If you’re reading this and in a non-tech first field, you might be sweating.
Now that being said, these practices could make it where lateral movement is more feasible once an attacker gets a foothold. The attacker still has to get initial access, which we’ll go over how below.
At the same time, some practices that have become almost ubiquitous at tech companies for the better are Trusted Device (Zero Trust, etc.), and hardware security keys. This makes it that much harder for the initial foothold. See this post for more on that.
How did these attacks work?
One thing that the majority of these breaches (and those in 2022 for that matter) have in common are: a targeted employee was phished, access was obtained through employee, or through an access broker, lateral movement ensued.
One form of compromise from end to end could look the following
A carbon copy clone of the target’s SSO is made
Phishing link with cloned SSO page sent to employee
Employee clicks link (Since it looks legit)
2FA Push fatigue leads to employee accepting
Attacker has hands on keyboard access in the context of employee
In the Okta breach (one of them), a support staff employee was targeted. Leading to support admin access, but user access can suffice as was shown in the other attacks.
Another pattern seen in these attacks are the usage of anonymization services. For example, in the Coinbase incident, Mullvad VPN was used by the attacker. But others have been utilized as well.
You may have noticed another pattern here.
A lot of these companies overlap in tool usage. For example, it is not far fetched that the user base of Okta uses Twilio, or vice versa. If there is tool overlap between the SaaS companies then the threat actor can use one as a waterhole to get to the other other target.
How does this happen? Although this varies in some of these breaches, as alluded to earlier, there are a lot of similarities.
Below are the TTP’s that overlap.
Usage of VPS Infrastructure
Harvesting phone numbers from commercially available aggregation services
Mass Phishing lures to employees in targeted organization
Forms of Social Engineering
VPN or anonymization services used
Often times threat actors are using a Windows host
When it comes down to it, a lot these attacks are moderate in sophistication. Its just that they are executed to near perfection.
Kind of like a pro basketball player mastering certain moves. A crossover in theory is simple, but executed perfectly (through countless hours of practice) and it becomes increasingly difficult to defend.
This is not to take anything away from the threat actor. At the end of the day, execution is what matters.
Ideas > Execution
What we can we do about this?
Now that we went over some of these breaches, and what the TTP’s are let’s discuss defensive measures.
There are many practical steps companies can take to better our defenses.
From a prevention standpoint we can restrict access (authorization) and authentication.
Restricting access to applications to only those devices that are registered, meeting your companies policy criteria. The idea is that only devices that are managed are able to login and have access.
As mentioned earlier, hardware security keys are more common as a second factor today. This should be the default method in enterprise.
From a detection standpoint you can take a deny first approach.
For example, if only one type of Remote Desktop tool is sanctioned then anything else is sus.
Or if your company doesn’t use a particular VPN service, then any log activity showing someone utilizing this should be sus.
The TLDR here is if your company only uses one VPN provider, then anything outside of this should be investigated.
You can alert upon any de-registering of a second factor followed by a new second factor. You should operationalize the enrollment of a new second factor (security key) through your Helpdesk.
Take this same approach from a new device scenario. If user Bob logins with a new laptop device, with a new IP, and a new User Agent, there’s a good chance that isn’t Bob.
There could be nuance here, but the TLDR is if a user logged in with all of these novel attributes, and there is no record of user getting a new laptop deployed/assigned, this is sus.
In summary, these are just 5 practical steps to take.
Prevent access to only managed devices.
Utilize only hardware security keys as a second factor, prevent all others (within reason)
Detect on any non company usage of VPN services.
Detect on de-registering of second factor, registering of a new second factor.
Detect on Logins for user x with a new unaccounted device.
Wrapping Up
As stated earlier, this is not an exhaustive list of past years breaches, just some of the most impactful ones. In which we can learn a lot in order to better defend for this class of attack.
For a cool Github collection of breaches see
https://github.com/BushidoUK/Breach-Report-Collection
Hope you learned something new in this writeup!