Ignoring low-risk secrets in GitGuardian? This could be a costly mistake. Learn how to avoid the hidden dangers of prematurely closing incidents.
The post From False Positives to Potential Breaches: The Risks of Prematurely Closing Incidents appeared first on Security Boulevard.
Cary, North Carolina, 20th August 2024, CyberNewsWire
The post INE Security Alert: The Steep Cost of Neglecting Cybersecurity Training appeared first on Security Boulevard.
Authors/Presenters:Yoochan Lee and Jinhan Kwak, Junesoo Kang, Yuseok Jeon, Byoungyoung Lee
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access. Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
The post USENIX Security ’23 – Pspray: Timing Side-Channel Based Linux Kernel Heap Exploitation Technique appeared first on Security Boulevard.
This is the second post in a series on Identity-Driven Offensive Tradecraft, which is also the focus of the new course we will launch in October. In the previous post, I asked, “How does one discover and abuse new attack paths?” To start answering this question, I made two key arguments:
In this post, I will share a framework I developed for discovering known and unknown attack paths.
Does Clean Source Violation Necessarily Introduce an Attack Vector?We’ve already established that attack paths are a chain of control relationships with at least one Clean Source Principle violation, but is the opposite also true? Does every Clean Source violation necessarily create an attack path? Logic suggests the answer is “no”, but let’s see why.
The reason lies in the “control” definition. In our context, we define “control” as a relationship that can contribute to compromising the target resource or impacting its operability. I previously explained that I chose the words “contribute to compromising or impacting” rather than “compromise or impact” because we sometimes need to abuse more than one security dependency to fully compromise or impact the target. For example, if multi-factor authentication (MFA) is enforced on an account, we must abuse both authentication factors to gain control.
Therefore, the conclusion was that a set of one or multiple security dependencies can control a resource that depends on it. I’ll note that not every control prerequisite is necessarily a security dependency. For example, you need to establish a connection to a remote host/service to control it, but a network connection is not a security dependency and shouldn’t be a security boundary, at least not in $CurrentYear.
Attack Path CriteriaTwo criteria determine whether a set of security dependencies violating the Clean Source Principle introduce an attack path:
I’m not adding the Clean Source violation as a criterion because it is implied and I’ll address it later.
Both criteria are binary, so we can represent security dependencies in a 2x2 matrix:
The top left quadrant is where we want to be: both criteria are met, so any Clean Source violation we identify is abusable. Paths BloodHound finds are in that quadrant — that’s the easy part. The challenge is bringing everything else into that quadrant. How do we achieve that?
Attack Path Discovery Framework Define TargetThere are generally two approaches for discovering attack paths:
The latter is more suitable for this framework but requires a well-defined target or targets. As attackers, we would derive that from our red team objectives. The former can also serve a purpose, especially earlier on, for gaining situational awareness.
Map Security DependenciesPerforming reconnaissance, enumeration, and discovery helps discover what is present in an environment and identify the target’s direct and transitive security dependencies. This activity represents an upward shift from the bottom quadrants to the top quadrants.
The bottom left quadrant represents known tradecraft, which is typically easier to discover. For example, we can run SharpHound and AzureHound to collect and ingest data into BloodHound. BloodHound can’t provide complete coverage of all known offensive tradecraft, so other enumeration tools and discovery techniques must be utilized.
The bottom right quadrant represents unknown tradecraft. It could be commodity, off-the-shelf technologies that we, as operators or as a community, don’t know how to abuse. It could also be proprietary/bespoke technologies for the target organization. Discovering those can be more challenging, as it requires more manual research and reconnaissance, which could involve scouring internal documentation and analyzing artifacts. Moving from the bottom right quadrant to the top right quadrant is essentially learning how things work, which is what hacking used to be all about.
Relying solely on existing tooling would completely ignore the bottom right quadrant and likely guarantee missing attack paths. Custom-built solutions and less commonly used technologies are typically more prone to vulnerabilities. Also, even if the target organization uses only stock technologies, we still need to learn how they are used to map their security dependencies. Remember that security dependencies are found not only in technology but also in people and processes, and those are almost always unique to the target organization.
Weaponize for ControlThe second criterion is knowing how to abuse the security dependencies to gain control of the dependent resource. Learning or developing the required attack primitives represents a leftward shift from the right quadrants to the left quadrants.
When targeting commodity, off-the-shelf technology, if new attack primitives are required, it is achieved through security research and tradecraft development. However, there is a plethora of known attacks against stock technologies and because the criterion is “knowing” how to abuse security dependencies to gain control, it can also be achieved through learning (did I mention we are launching a new course about identity-driven offensive tradecraft?). The bottom right quadrant represents such activities because we learn and develop tradecraft while not knowing if it is present in the target environment.
When targeting internally developed solutions, security assessments, red team operations, and penetration testing help discover attack primitives for abusing the technology and, as I mentioned, the people and processes. The top right quadrant represents this activity because we know the people, processes, and technology are present in the target environment, and we develop the required attack primitives with a specific target in sight.
Identify Clean Source ViolationsNow that we have a clear view of the target’s security dependencies and know how to abuse them to gain control, we need to identify Clean Source violations. Remember, security dependencies always exist, but without a Clean Source violation, they are not an attack path. There is nothing wrong with Domain Admins having admin access to a domain controller (DC); that is expected behavior.
We’re looking for a security dependency that is less trustworthy than the dependent resource, so the obvious next step is to assign a trustworthiness level to every node. We’ll keep it simple by using only three levels:
Let’s consider the following scenario:
The Production DB Server is the target. It has two security dependencies: the Domain Admins group and another dependency that we don’t know how to abuse. Because we don’t know how to abuse it, it does not meet the attack path criteria, so we can disregard it. The DA User is a member of the Domain Admins group and has a session on a compromised workstation.
Now, we can assign trustworthiness levels to the dependencies. The trustworthiness should be assigned based on the security controls enforced on the dependency. Domain Admins are more trustworthy than the target and can be marked green. In line with the Clean Source Principle, security best practices dictate that Domain Admins must use Privileged Access Workstations (PAW) because normal workstations lack the security controls required to protect privileged accounts. Therefore, the Compromised Workstation can be marked red.
What about the DA User? You could argue that it is missing a security control preventing it from establishing a session on a less trustworthy workstation, and therefore it is less trustworthy than the Domain Admins group. Members of the Domain Admins group should log into Privileged Access Workstations (PAW) only. It could also be that, despite that, the DA User is still more trustworthy than the target. Regardless, the Compromised Workstation is less trustworthy, and it is sufficient for introducing an attack path.
ConclusionAttack paths must include at least one clean source violation that we know how to abuse. Discovering attack paths requires acquiring capabilities to identify and abuse security dependencies to gain control of the dependent resources. Ultimately, assigning trustworthiness levels relative to a well-defined target allows for pinpointing Clean Source violations and identifying attack paths.
In the next post, we will apply this framework to a broadly used technology to demonstrate it.
Navigating the Uncharted: A Framework for Attack Path Discovery was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Navigating the Uncharted: A Framework for Attack Path Discovery appeared first on Security Boulevard.