The mind-blowing Kerberos "Use Any Authentication Protocol" Delegation

Kerberos delegation has been in the spot light for some time now and the risks behind it have been outlined in quite a few blogs and conference presentations - I particularly recommend reading https://adsecurity.org/?p=1667 and https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/. For some time, it was my incorrect understanding that unconstrained delegation is a massive problem while constrained/resource based is less destructive. That is however not the case, and the exploitation that is to follow absolutely blew my mind the first time I saw it in "action".

When a service account is set for "Use any authentication protocol" delegation, it means that the service account is allowed to delegate without being required to prove that a user authenticated to it! In normal words, just saying "I shall pass because I am the administrator, trust me!" opens the door with no questions asked and no one verifying that you are in fact the administrator. Sounds crazy, right? Let's have a walk though.

Privileged Access Workstation

Disclaimer: This blog post is not a complete guide on deploying Privileged Access Workstations (PAWs) that work in any environment. The information contained here defines the concept behind Privileged Access Workstations and presents a working generic implementation. Complete implementation requires deep knowledge of the specific infrastructure and definition of all the tasks to ensure that any other activity is denied execution on the machine, which reduces the likelihood of a potential compromise of it, significantly.

Securing Windows environments

Securing windows environments in a way that prevents lateral movement and/or escalation of privileges has become an incredibly difficult task. The research and tools created in the past 2-3 years have been simply amazing, which helped to identify new attacks and vulnerabilities, while lowering the sophistication required to exploit them. The easiest way to ensure that your environment is built in a secure manner, is to rebuild it from scratch with a security architect behind the design. As Microsoft states, one may never trust Active Directory, if it has been compromised, unless it is possible to return to a known good state.

Mitigate the risk of insecure passwords - we give you Get-bADpasswords

A common approach to gaining access into an Active Directory environment is to crack the password of a specific target user through means of brute-force or dictionary attacks. Built-in password policies for Active Directory can reduce the success rate of brute-force or dictionary attacks and will often prohibit access to accounts with too many failed login attempts.

AppLocker - hash *bad*listing

Application whitelisting is one of those actions on organization's security roadmaps, which either never happens or is adopted to fit the current environment rather than having it implemented to its full extent. Although far from perfect, with a large number of bypasses for its whitelisting capabilities (described in the Github repository here), AppLocker is still a great, free* tool which introduces resilience in the environment. Many of the bypasses rely on abusing Microsoft signed executables, as they are whitelisted by default and have the capability to launch other executables. In the previously linked Github repository, the author has made an effort to provide AppLocker rules to prevent the bypasses, however, many of these are likely to break things in a fully-functional real-world environment with "legacy" systems.

Routed SQL Injection

I encountered what is known as Routed SQL Injection a couple of times but it was never required to exploit the vulnerability to the full extent. Recently, I discovered an online challenge on the topic and decided to look at it in depth. An explanation of the vulnerability with a vulnerability code which is described in the beginning this post, can be found here.

Privilege escalation in IBM Notes Diagnostics #6

This is the fifth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Client side code execution in IBM Notes

This is the sixth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Privilege Escalation in Heimdal #2

This blog post highlights bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Privilege Escalation in Heimdal #1

This blog post highlights bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Privilege Escalation in IBM Notes Diagnostics #3-5

This is the fourth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom

Privilege Escalation in IBM Notes Smart Update Service

This is the third blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Privilege Escalation in IBM Notes Diagnostics #2

This is the second blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy

In this blog post I will tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

Privilege Escalation in IBM Notes Diagnostics #1

This is the first blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy

In these blog posts I will be a bit verbose and give insights into the process. Concrete exploitation steps and code is listed at the bottom.

Data Only Attacks Are Still Alive

The past week I have been fortunate enough to present at both Black Hat USA and DEF CON. My topic was on leveraging Write-What-Where vulnerabilities for Windows 10 Creators Update. You can find the slides here. In my DEFCON talk I mentioned additional KASLR bypasses, one of those use the field Win32ThreadInfo from the TEB to leak a pointer to ntoskrnl.exe. This pointer can be used to achieve arbitrary kernel mode code execution as explained in my presentation.

A couple of months ago I did a blogpost on data only attacks in kernel exploitation, which you can find here. I used the tagWND object to locate the EPROCESS of the current thread, while that technique is still perfectly valid, I wanted to present another way of doing it which does not involve creating a tagWND object.

The enterprise-ready workaround I would have expected from IBM

When IBM promised to release a workaround for the vulnerability we found in their product, I truly expected such a widely respected company to release an enterprise-ready workaround, and not just a manual approach to setting registry permissions in the GUI.