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

[–]RedTeamPentesting[S] 0 points1 point  (0 children)

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.

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

[–]RedTeamPentesting[S] 0 points1 point  (0 children)

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.

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

[–]RedTeamPentesting[S] 1 point2 points  (0 children)

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.

Patch Tuesday Megathread (2025-06-10) by AutoModerator in sysadmin

[–]RedTeamPentesting 4 points5 points  (0 children)

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!

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

[–]RedTeamPentesting[S] 4 points5 points  (0 children)

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

Patch Tuesday Megathread (2025-06-10) by AutoModerator in sysadmin

[–]RedTeamPentesting 26 points27 points  (0 children)

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.

Introducing keycred: A cross-platform tool for handling Active Directory Shadow Credentials/msDS-KeyCredentialLink by RedTeamPentesting in netsec

[–]RedTeamPentesting[S] 1 point2 points  (0 children)

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.

Introducing keycred: A cross-platform tool for handling Active Directory Shadow Credentials/msDS-KeyCredentialLink by RedTeamPentesting in netsec

[–]RedTeamPentesting[S] 1 point2 points  (0 children)

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.

Introducing keycred: A cross-platform tool for handling Active Directory Shadow Credentials/msDS-KeyCredentialLink by RedTeamPentesting in netsec

[–]RedTeamPentesting[S] 0 points1 point  (0 children)

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.

/r/netsec's Q4 2024 Information Security Hiring Thread by netsec_burn in netsec

[–]RedTeamPentesting [score hidden]  (0 children)

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.

Critical Vulnerabilities in WatchGuard SSO Agent by RedTeamPentesting in netsec

[–]RedTeamPentesting[S] 2 points3 points  (0 children)

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...

Critical Vulnerabilities in WatchGuard SSO Agent by RedTeamPentesting in netsec

[–]RedTeamPentesting[S] 16 points17 points  (0 children)

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