Proof-of-Concept

Proof of Concept (PoC)

This is where we prove vulnerabilities in operating systems or application software.
We use this Proof of Concept (PoC) to prove that a security problem exists so that the developers or administrators can validate it, reproduce it, see the impact, and test their remediation efforts.
A PoC can have many different representations. For example, documentation of the vulnerabilities found can also constitute a PoC. The more practical version of a PoC is a script or code that automatically exploits the vulnerabilities found.
Sometimes when providing a client with a script, one significant disadvantage occurs from time to time. Once the administrators and developers have received such a script from us, they focus on changing the systems so that the script we created no longer works. The important thing is that the script is only one way of exploiting a given vulnerability. Therefore, working against our script instead of with it and modifying and securing the systems so that our script no longer works does not mean that the information obtained from the script cannot be obtained in another way.
The report they receive from us should help them see the entire picture, focus on the broader issues, and provide clear remediation advice.
Including an attack chain walkthrough in the event of domain compromise during an internal is a great way to show how multiple flaws can be combined and how fixing one flaw will break the chain, but the other flaws will still exist. If these are not also fixed, there may be another path to get to the point where the attack chain was remediated and continue onwards. We should also drive this point home during our report review meeting.

Example (Root Cause)

For example, if a user uses the password Password123, the underlying vulnerability is not the password but the password policy.
If a Domain Admin is found to be using that password and it is changed, that one account will now have a stronger password, but the problem of weak passwords will likely still be endemic within the organization.

PreviousLateral Movement NextPost-Engagement

Last updated 3 months ago

Proof of Concept (PoC)

This is where we prove vulnerabilities in operating systems or application software.

We use this Proof of Concept (PoC) to prove that a security problem exists so that the developers or administrators can validate it, reproduce it, see the impact, and test their remediation efforts.

A PoC can have many different representations. For example, documentation of the vulnerabilities found can also constitute a PoC. The more practical version of a PoC is a script or code that automatically exploits the vulnerabilities found.

Sometimes when providing a client with a script, one significant disadvantage occurs from time to time. Once the administrators and developers have received such a script from us, they focus on changing the systems so that the script we created no longer works. The important thing is that the script is only one way of exploiting a given vulnerability. Therefore, working against our script instead of with it and modifying and securing the systems so that our script no longer works does not mean that the information obtained from the script cannot be obtained in another way.

The report they receive from us should help them see the entire picture, focus on the broader issues, and provide clear remediation advice.

Including an attack chain walkthrough in the event of domain compromise during an internal is a great way to show how multiple flaws can be combined and how fixing one flaw will break the chain, but the other flaws will still exist. If these are not also fixed, there may be another path to get to the point where the attack chain was remediated and continue onwards. We should also drive this point home during our report review meeting.

Example (Root Cause)

For example, if a user uses the password Password123, the underlying vulnerability is not the password but the password policy.

If a Domain Admin is found to be using that password and it is changed, that one account will now have a stronger password, but the problem of weak passwords will likely still be endemic within the organization.