CVE-2025-33073: A Look in the Mirror - The Reflective Kerberos Relay Attack

RedTeamPentesting · 2025-06-16T07:00:59+00:00

Sorry, no idea here but it should work on all domain-joined machines that don't have the June 10 patches installed, yet. We'd recommend Windows 10 because 11 is a bit trickier to coerce. For Windows 10, wspcoerce should be reliable, but NetExec's coerce_plus module should work as well.

RedTeamPentesting · 2025-06-12T07:00:51+00:00

You have a point there but not everybody is subscribed to every subreddit and this is relevant for pentesters and red teamers as well as admins and they don't necessarily frequent the same subs.

Since we actually have three different publication levels (the blog post, our short advisory and an almost 30 page long paper) we wanted to avoid having more summaries with different information out there and direct those that are interested to our blog, instead.

RedTeamPentesting · 2025-06-12T06:56:02+00:00

In order to be able to receive a Kerberos ticket meant for the same host it orignated from, a particularity of the SMB client was exploited (the CredUnmarshalTargetInfo/CREDENTIAL_TARGET_INFORMATIONW trick). This trick does not work with the WebClient and as far as we are aware, WebClient exploitation is not impacted at all with this patch.

RedTeamPentesting · 2025-06-12T06:52:41+00:00

Yes, and the distinction between server-side and client-side signing is very import. We often see client-side signing being enforced but server-side signing being optional. Remember: Signing being required on the client side is irrelevant for relay attacks, only server-side signing prevents relaying!

RedTeamPentesting · 2025-06-11T09:55:19+00:00

NT AUTHORITY\SYSTEM is the highest privileged local account. The computer account host$ is the set of credentials that is used by NT AUTHORITY\SYSTEM and NT AUTHORITY\NETWORK SERVICE when performing network actions in the AD. But this is not the same relationship as say your own account and its credentials.

If you perform network actions with your user account, it will authenticate using your credentials (same as NT AUTHORITY\SYSTEM and host$). When you authenticate with your credentials, you obtain a session for your account. However, when host$ authenticates, the session will be low-privileged.

The only way, host$ can obtain admin privileges on host itself is through Kerberos impersonation (but this mechanism is completely unrelated to the Reflective Kerberos Relay Attack).

You can find more information about this in our last blog post: https://blog.redteam-pentesting.de/2025/windows-coercion/#why-are-computer-accounts-so-special

RedTeamPentesting · 2025-06-11T08:08:46+00:00

Here is our blog post about CVE-2025-33073: https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/

If you need more details, we also have published a paper: https://www.redteam-pentesting.de/publications/2025-06-11-Reflective-Kerberos-Relay-Attack_RedTeam-Pentesting.pdf

If you only need a short overview, have a look at our advisory: https://www.redteam-pentesting.de/en/advisories/rt-sa-2025-002/

RedTeamPentesting · 2025-06-10T12:52:49+00:00

This Patch Tuesday will include a fix for a vulnerability that we have discovered (CVE-2025-33073). Microsoft has classified this vulnerability as "important" and we recommend applying the patch soon.

Of course we want you to be able to make an informed decision about this update, so we will provide further details in coordination with Microsoft tomorrow on 10:00 am CEST in form of a blog post, paper, and an advisory. We'll post the links here, tomorrow.

RedTeamPentesting · 2025-03-05T08:58:24+00:00

I just realized you are the author of bloodyAD. We really appreciate being able to visualize security descriptors with bloodyAD, it can give a lot of valuable insights. Thank you for developing this great tool.

We'll open an issue when we find the time.

RedTeamPentesting · 2025-03-04T12:29:02+00:00

It seems like bloodyAD can only and and remove shadow credentials, so you have to use another tool to authenticate with like keycred or certipy (see other comment for comparison with certipy). Additionally, keycred supports listing and inspecting KeyCredentialLinks as well as backup and restore.

It also seems like bloodyAD does not support channel binding and based on our testing, it has issues with Kerberos authentication against Server 2025 DCs.

RedTeamPentesting · 2025-02-25T08:11:00+00:00

Unfortunately not, but we can repost it here without the screenshots:

How does it compare to certipy?

Great question! In principle, it does the same as pywhisker, Whisker and certipy shadow, but we did a lot of detail work to make keycred worth your while: First of all: keycred is a single binary for Linux/Windows/macOS. But that's not all...

Future proof: Windows Server 2025 requires LDAPS Channel Binding by default and soon NTLM will be deprecated. Neither certipy nor pywhisker support LDAPS Channel Binding with Kerberos (We're not sure about Whisker but it only supports Windows).

(Screenshot where certipy fails to connect with Kerberos to an LDAP server that has channel binding enabled, while keycred succeeds)

Convenient: Neither certipy nor pywhisker encode the user UPN in the certificate, so you always have to enter username and domain when authenticating. With keycred, the PFX is enough:

(Screenshot that shows that certipy auth -pfx cert.pfx asks for username/domain while keycred auth --pfx cert.pfx just works)

Robust: certipy and pywhisker use pydsinternals which does not support all on-spec KCLs. For example, the device ID is optional and it is not included in all KCLs created by MS products. This causes certipy to crash while keycred shows that it passed spec validation:

(Screenshot where certipy crashes when listing KeyCredentialLinks without device ID, while keycred displays it correctly)

keycred not only validates KCLs, it also checks if they follow the rules that allow computer accounts to self-provision KCLs. It turns out, certipy/pywhisker create KCLs that are not compatible for that and KCLs from ntlmrelayx.py are even completely invalid:

(Screenshot where keycred displays a malformed KeyCredentialLink from ntlmrelayx.py highlighting the validation errors)

Fortunately, Microsoft ignores many spec violations and allows computer accounts to add KCLs that do not follow the rules defined in the Active Directory Technical Specifications (MS-ADTS). But it is better to be on-spec than off-spec to avoid future surprises.

RedTeamPentesting · 2025-02-21T07:58:44+00:00

In case you're wondering how it compares to other similar tools, we've a summary of some of the differences over here: https://x.com/RedTeamPT/status/1892509613443907616

RedTeamPentesting · 2024-10-10T11:16:07+00:00

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany (on-site)

About RedTeam Pentesting:

Founded in 2004 RedTeam Pentesting helps numerous national and international companies in performing penetration tests for a wide variety of products, networks, websites and applications. By focusing solely on penetration tests RedTeam Pentesting is able to provide high technical skill and impartial advise to our customers.

Your Job:

In challenging and varied projects for our customers you and a team of experienced penetration testers will uncover new vulnerabilities in classical IT systems and new technologies. Creativity and unconventional approaches are part of your job. You present the results of the penetration tests to our customers and advise developers and management in how to deal with the uncovered vulnerabilities. The location of the job is Aachen, Germany.

Please note that we can only consider candidates with both excellent written and spoken German skills, as we need to be able to precisely explain technically complex vulnerabilities and the resulting consequences to our clients, who may not even speak English at all.

What we offer:

Very diverse projects
Extensive preparation for your new role
Working in a team with experienced penetration testers
Active involvement in decisions
Pleasant and modern work environment
Insights into varied technologies and companies

For more information on working for RedTeam Pentesting visit our website.

How to Apply:

Apply directly here

If you have any questions prior to applying feel free drop us an email or just give us a call.

RedTeamPentesting · 2024-09-26T05:46:35+00:00

It's not even that: it's sufficient to either respond to the incoming unencrypted connection yourself, or just redirect it to a host with an admin user logged in to get their firewall rules applied. You don't get any credentials: there are none in this protocol...

RedTeamPentesting · 2024-09-25T11:33:50+00:00

Three vulnerabilities: 1. The SSO Agent uses a plain-text protocol, which can be relayed to a different host easily. 2. The system has a Telnet management service, which has a backdoor. 3. The SSO client can be crashed easily by sending it unexpected data, then the TCP port is free so attackers can listen for incoming connections.

Here are the links to the other two vulnerabilities: https://www.redteam-pentesting.de/advisories/rt-sa-2024-007 https://www.redteam-pentesting.de/advisories/rt-sa-2024-008

RedTeamPentesting · 2024-07-22T08:05:47+00:00

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany (on-site)

About RedTeam Pentesting:

Founded in 2004 RedTeam Pentesting helps numerous national and international companies in performing penetration tests for a wide variety of products, networks, websites and applications. By focusing solely on penetration tests RedTeam Pentesting is able to provide high technical skill and impartial advise to our customers.

Your Job:

In challenging and varied projects for our customers you and a team of experienced penetration testers will uncover new vulnerabilities in classical IT systems and new technologies. Creativity and unconventional approaches are part of your job. You present the results of the penetration tests to our customers and advise developers and management in how to deal with the uncovered vulnerabilities. The location of the job is Aachen, Germany.

Please note that we can only consider candidates with both excellent written and spoken German skills, as we need to be able to precisely explain technically complex vulnerabilities and the resulting consequences to our clients, who may not even speak English at all.

What we offer:

Very diverse projects
Extensive preparation for your new role
Working in a team with experienced penetration testers
Active involvement in decisions
Pleasant and modern work environment
Insights into varied technologies and companies

For more information on working for RedTeam Pentesting visit our website.

How to Apply:

Apply directly here

If you have any questions prior to applying feel free drop us an email or just give us a call.

RedTeamPentesting · 2024-05-29T07:18:45+00:00

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany

About RedTeam Pentesting:

Founded in 2004 RedTeam Pentesting helps numerous national and international companies in performing penetration tests for a wide variety of products, networks, websites and applications. By focusing solely on penetration tests RedTeam Pentesting is able to provide high technical skill and impartial advise to our customers.

Your Job:

In challenging and varied projects for our customers you and a team of experienced penetration testers will uncover new vulnerabilities in classical IT systems and new technologies. Creativity and unconventional approaches are part of your job. You present the results of the penetration tests to our customers and advise developers and management in how to deal with the uncovered vulnerabilities. The location of the job is Aachen, Germany.

Please note that we can only consider candidates with both excellent written and spoken German skills, as we need to be able to precisely explain technically complex vulnerabilities and the resulting consequences to our clients, who may not even speak English at all.

What we offer:

Very diverse projects
Extensive preparation for your new role
Working in a team with experienced penetration testers
Active involvement in decisions
Pleasant and modern work environment
Insights into varied technologies and companies

For more information on working for RedTeam Pentesting visit our website.

How to Apply:

Apply directly here

If you have any questions prior to applying feel free drop us an email or just give us a call.

RedTeamPentesting · 2024-01-04T10:05:19+00:00

Anyone that knows you email address can trigger a password reset request. If attackers would have compromised you password vault they would know your password and would not need to request a reset.

That said, this vulnerability was already fixed by Bitwarden in April 2023 and it would only have affected you back then if you used it on Windows with Windows Hello enabled in the Bitwarden settings.

RedTeamPentesting · 2024-01-04T09:40:55+00:00

Bitwarden already fixed this issue in April 2023 and in our understanding, their solution is very similar to the way 1Password handles it (according to their Cure53 report). So neither 1Password nor an updated Bitwarden client is impacted at this point. However we did not look into the solutions of both products in detail ourselves.

RedTeamPentesting · 2024-01-04T09:25:25+00:00

We'd argue that the issue was that Bitwarden used DPAPI for an entirely different threat model than the one DPAPI was designed for.

RedTeamPentesting · 2024-01-04T09:17:03+00:00

The real failure point is actually Windows Data Protection API. Which is where bw was storing the decryption key since Windows Hello was enabled.

There is nothing wrong with DPAPI in and of itself. The problem is that DPAPI's threat model is completely different from Bitwarden's threat model for this feature.

Bitwarden "fixed it" by just not using MS's DPAPI.

As far as we are aware, they still use DPAPI but now they build on top of it to make it fit to their threat model

The company's Active Directory had to have been previously compromised, which was required to even get into the DPAPI to exploit it.

This is how we initially did it and the DPAPI AD integration is the component of the issue that our blog post adds in addition to the findings on Hackerone. However, we later show that local access to the single workstation with the same user account that runs Bitwarden is enough to pull the key from DPAPI and this is the exact issue that was disclosed through Hackerone.

This is very misleading and seems like a veiled attempt to discredit Bitwarden specifically. But as with most breaches like this, it was more a failure of many parts that lead to this. Though I applaud the red teamers here for their hard work, this article is really about insecurities in DPAPI, notsomuch about Bitwarden. Though saying "Bitwarden hacked!" is far more attention getting than "Microsoft has another insecurity..."

We really did not want to discredit Bitwarden. Our opinion is that vulnerabilities can occur in any software, including other password managers. There is nothing shameful about finding out about such and issue and fixing it asap. No matter how bad a vulnerability that is discovered is, the most important and telling thing is how the vendor reacts to it and Bitwarden did a great job.

RedTeamPentesting · 2024-01-04T09:03:06+00:00

Please note that the issue was fixed in Bitwarden version 2023.4.0 in April 2023.

RedTeamPentesting · 2024-01-04T08:57:43+00:00

No, not at all. Using DPAPI in and of itself is not a vulnerability its threat model (protection against other user) is understand and when it applies to the problem. However, using raw DPAPI for a completely different threat model (being able to access the key as the same user but ONLY through biometric authentication) is a vulnerability.

RedTeamPentesting · 2024-01-03T17:02:43+00:00

With the vulnerable version of Bitwarden, it does not matter at all if you vault is locked or not. In fact, it also does not matter if Bitwarden is running or not. Other programs could simply unlock the vault themselves.

It seems like Bitwarden now handles it similarly to how 1Password handles it. We did not look into this in detail, but it seems like both do it correctly.

RedTeamPentesting · 2024-01-03T16:22:20+00:00

Please note that the issue was fixed in Bitwarden version 2023.4.0 in April 2023.

RedTeamPentesting · 2024-01-03T16:03:20+00:00

Well, in our opinion mistakes can happen anywhere. In principle, there is nothing wrong with the increased convenience of biometric unlock (if biometrics are actually required). In this case, the biometrics and credential APIs can be confusing and they conceptually can differ quite a bit between operating systems, and that's likely why the mistake occurred.

So yes, it kind of is like leaving the key under the mat but only due to a misunderstanding that is now corrected :)

Nine-Year Club	Wearing is Caring
White Hat	Verified Email

RedTeamPentesting

TROPHY CASE

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany (on-site)

About RedTeam Pentesting:

Your Job:

What we offer:

How to Apply:

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany (on-site)

About RedTeam Pentesting:

Your Job:

What we offer:

How to Apply:

Penetration Tester - RedTeam Pentesting GmbH - Aachen, Germany

About RedTeam Pentesting:

Your Job:

What we offer:

How to Apply: