{"vulnerability": "cve-2024-2620", "sightings": [{"uuid": "e3360259-8bc1-45aa-a740-17276e14fc65", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-26204", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/14660", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-26204\n\ud83d\udd25 CVSS Score: 7.5 (cvssV3_1, Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:C)\n\ud83d\udd39 Description: Outlook for Android Information Disclosure Vulnerability\n\ud83d\udccf Published: 2024-03-12T16:58:14.361Z\n\ud83d\udccf Modified: 2025-05-03T00:47:11.390Z\n\ud83d\udd17 References:\n1. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26204", "creation_timestamp": "2025-05-03T01:18:11.000000Z"}, {"uuid": "98333536-30e8-4c84-a88a-f5745b5ceeb7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-2620", "type": "seen", "source": "https://t.me/ctinow/211109", "content": "https://ift.tt/QwGmSq7\nCVE-2024-2620", "creation_timestamp": "2024-03-19T02:26:26.000000Z"}, {"uuid": "fd85a106-1fee-4289-920f-4327a4ccbf06", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-2620", "type": "seen", "source": "https://t.me/ctinow/211115", "content": "https://ift.tt/QwGmSq7\nCVE-2024-2620", "creation_timestamp": "2024-03-19T02:26:35.000000Z"}, {"uuid": "0d302d91-2dfa-44b9-8bad-7432576bdd05", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-26209", "type": "seen", "source": "https://gist.github.com/whindsaks/aefcf83af87e1d56d8eb42147e26d9f0", "content": "# LSA Whisperer\n\n> Thank you to [SpecterOps](https://specterops.io/) for supporting this research, to [Elad](https://twitter.com/elad_shamir) for helping draft this blog, and to [Sarah](https://www.linkedin.com/in/sarah-miles-81ab6a41/), [Daniel](https://twitter.com/hotnops), and [Adam](https://twitter.com/_xpn_) for proofreading and editing!\n> Crossposted on the [SpecterOps Blog](https://posts.specterops.io/).\n\nWhat follows is the culmination of two years of research with funding by [SpecterOps](https://specterops.io/) and contributions from many of my coworkers.\n\nSpecial thanks are needed to [Elad](https://twitter.com/elad_shamir), [Lee](https://twitter.com/tifkin_), [Will](https://twitter.com/harmj0y), [Daniel](https://twitter.com/hotnops), and [Kai](https://twitter.com/mhskai2017).\nElad, Lee, and Will have contributed several ideas to the project, which are documented here, and have each spent multiple days testing the tool.\nDaniel has answered all of my inevitable questions about AzureAD (whoops, now Entra ID! It was AzureAD when I started \ud83d\ude42) and OAuth 2.0.\nKai helped both research LSA\u2019s cloudap authentication package (AP) and add kerberos package support to the tool.\nTo each, thank you!\n\nThe LSA Whisperer project focuses on interacting with \u201cAuthentication Packages\u201d using their individual message protocols.\nAPs are Security Support Provider (SSP) DLLs that LSA loads to implement a specific authentication logic design (e.g., local logons).\nAn SSP may also be called a Security Package (SP) if it implements a security protocol (e.g., NTLM), but any use of the word \u201cpackage\u201d in this blog will only be referring to the AP functionality of an SSP.\n\n## Diary of a Developer\n\nThe project that is about to be described has been a journey to completion, so please allow me to explain how it all began.\n\n### Summer, 2022\n\nSpecterOps does a series of internal technical talks presented by coworkers and hosted by [Cody Thomas](https://twitter.com/its_a_feature_).\nDuring one of these talks, [Lee Chagolla-Christensen](https://twitter.com/tifkin_) showed some work he did to trace how browsers requested SSO cookies from an LSA package named cloudap.\nHe was interested in making the same request programmatically, but he had not had an opportunity yet to investigate how.\n\nThe idea of requesting an SSO cookie directly was enticing, so I offered to help.\nDuring the break times while teaching [SpecterOps\u2019s Tradecraft Analysis course](https://specterops.io/training/tradecraft-analysis/), we managed to get some interaction occurring with cloudap via the `LsaCallAuthenticationPackage` Win32 API.\nWe had figured out how to request cloudap to refresh a primary refresh token (PRT) for a user, but we had not yet figured out how to recover a user\u2019s SSO cookie.\nThe successful interaction was exciting nonetheless.\nAuditing cloudap in Ghidra also allowed us to stumble on a wealth of functionality, known as \u201ccalls\u201d, that we could use to interact with the package in other ways.\n\nAfter that, I started working on a command-line interface (CLI) utility to interact with the cloudap calls we found interesting.\nThere was no consideration of the potential offensive use case for a tool at that time.\nI was simply interested in what calls cloudap offered and being able to call the useful ones myself.\nDaniel Heinsen was extremely helpful during this process, answering my many questions regarding all things Entra ID and OAuth 2.0.\n\n### Fall, 2022\n\nSoon after Elad Shamir rejoined SpecterOps.\nHe had heard I was doing some work with LSA, so we talked about an authentication flow he was investigating with the kerberos package.\nSpecifically, when the kerberos package recovers an NT OWF hash from a decrypted PAC, kerberos will store the hash in a logon session managed by the msv1_0 package using msv1_0\u2019s internal `CacheLogon` call.\nHe was interested to see if we could make the same `CacheLogon` call ourselves to Pass-the-Hash (PtH) with on-host tooling.\nThe only alternative with on-host tooling is to use Mimikatz or a similar tool to modify LSASS\u2019s memory.\n\nThe idea was fantastic and I began auditing `CacheLogon` to see how to make the call.\nWe found that the approach is indeed possible, but we ultimately encountered the roadblock in that msv1_0 restricts the `CacheLogon` call to only clients that are the LSASS process itself.\nWe noticed several other msv1_0 calls that seemed intriguing, though, and I started working on an equivalent msv1_0 CLI utility for interacting with the calls we were interested in.\n\nDuring this time we discovered the fact that the `GetCredentialKey` call for msv1_0 would return a subset of the primary credentials for an msv1_0 managed logon session.\nThese are derivations of a user\u2019s plaintext password (such as an NT hash) that msv1_0 stores to allow it to later perform various actions for the user.\nWe did not fully understand the implication of these credentials at the time, but we knew they were used in some way with the [Data Protection API (DPAPI)](https://en.wikipedia.org/wiki/Data_Protection_API).\nWe also could not find _anyone_ documenting this same call which was surprising and encouraged us to keep going and investigate other packages as well.\n\n> NOTE: \u201cCredential Keys\u201d is Microsoft's term for a one-way function (OWF) hash or a secure credential hash of a user\u2019s password.\n> The appropriate key may be used to decrypt a DPAPI master key.\n> Will Schroeder has added cred key support to [SharpDPAPI](https://github.com/GhostPack/SharpDPAPI) to weaponize this output.\n> Thank you, Will!\n\nAround this time Lee joked:\n\n> \u201cWhy don\u2019t you make a CLI utility for kerberos?\n> Actually, why not make one for all the packages?\u201d\n\nThe idea did not seem too far-fetched to implement, so the utilities got merged and additional work began on making kerberos calls.\nElad came up with a name that everyone liked, and thus LSA Whisperer was born.\n\n### Spring, 2023\n\nThe whole company met for our yearly retreat in early 2023.\nBy this time, I had reversed the names of all the calls for all packages that currently ship with Windows.\nI had identified that cloudap loaded plugins, that these plugins supported calls as well, and had reversed the names of each of those calls.\nI had also reversed the Security Package Manager (SPM), which manages LSA packages overall, identified that it too supported calls, and identified their names.\n\nThe full list of available calls was overwhelming.\nI sat down with Elad, Lee, and Will during the retreat to prioritize it into a smaller list of calls we wanted to learn more about.\nKai Huang also joined the project around this time to help research calls in the larger packages, namely cloudap and kerberos.\nThe prioritized list and extra help made the project much more manageable.\n\n### Fall, 2023\n\nIn Q4 of 2023, SpecterOps funded me to work the entire quarter on developing LSA Whisperer.\nAlthough it's common for SpecterOps to give employees work time and other resources for their personal projects, I understand this is uncommon for the industry and I am grateful to SpecterOps for your support.\n\nBy the start of Q4, the project was well organized.\nThe tool could already make many calls to several packages, all research was documented in a project wiki, and the work plan and milestones for the quarter were outlined in a formal research plan.\nProgress accelerated during this time, and the tool gained partial or full support for 12 cloudap calls, 10 cloudap AzureAD plugin calls (Microsoft uses Entra ID\u2019s previous name for the plugin), 21 kerberos calls, 1 livessp call, 1 msv1_0 call (many were previously implemented), 4 negoexts calls, 2 pku2u calls, 2 schannel calls, and 2 spm calls.\nLee and Will graciously spent many days at the end of the quarter testing each of these new calls to confirm or disprove our ideas for their potential use cases.\n\nThree bugs were also identified during this time, which were all responsibly disclosed to the Microsoft Security Response Center (MSRC).\nTwo were arbitrary pointer dereference issues with the LSASS process for NT 6.4 and higher.\nThese require the `SeTcbPrivilege` privilege, which reduces the potential for abuse, and MSRC ultimately considered both to be by design.\nThe third was a memory leak in LSASS triggerable by any logged-on user for at least NT 5.1 and higher.\nThe third bug was assigned [CVE-2024-26209](https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-26209), was fixed on April 9th, 2024, and is now available via security updates to all end users.\nMSRC was quick to respond and pleasant to work with for all of these issues which I appreciate.\nFor those interested, a description and proof of concept (POC) for each of these issues may be found [on a GitHub project where I share various POCs that I author](https://github.com/EvanMcBroom/pocs).\n\n### Spring, 2024\n\nI had the opportunity [to present LSA Whisperer](https://github.com/SpecterOps/presentations/tree/master/SO-CON%202024/Evan%20McBroom%20-%20LSA%20Whisper) at the annual [SpecterOps Conference (SOCON)](https://specterops.io/so-con/) in Arlington, VA.\nThere was a large attendance and the feedback afterwards made us feel that everything went well! Thank you to everyone who was able to attend the talk.\nYour presence and interest made presenting a joy!\n\nI would like to thank my colleagues for all of the support leading up to and during the presentation.\nThe talk would not have gone as smooth without it.\nLastly, the presentation was a combination of my own ideas and those of many of my colleagues including Elad, Lee, and Will.\nIt was an honor to be able to present the culmination of everyone\u2019s work, thank you!\n\nNow that brings us to the present: April, 2024.\nThe security update has been released and with that, we may release our tooling. \n\n## Project Overview\n\nIf you would like, you are welcome to skip this guide and go directly to [the main page for the project](https://github.com/EvanMcBroom/lsa-whisperer).\nThe main page describes how to build our tooling - LSA Whisperer, while the project wiki describes [how to use the tool](https://github.com/EvanMcBroom/lsa-whisperer/wiki/Usage), [how it works](https://github.com/EvanMcBroom/lsa-whisperer/wiki), and what authentication package functionality it supports.\nThe wiki is large so here we provide a more gentle introduction to these same topics.\n\n### Security Support Providers\n\nAs described in the blog\u2019s introduction, SSPs are DLLs loaded by LSA that implement a specific authentication logic design (e.g., local logons) or security protocol (e.g., NTLM).\nThe below table provides a summary of the SSPs that have been released by Microsoft over the years.\nLSA Whisperer supports interacting with a subset of shown SSPs that are marked as being an authentication package (AP).\nMany of these SSPs implement a security protocol and, as such, may also be referred to as a security package (SP) but for the purposes of this blog we will only be focusing on the AP functionality of these SSPs.\n\n| Dll       | Common Name                               | SP            | AP                 | RPC ID | RPC Authn       |\n|---        | ---                                       | ---           | ---                | ---    | ---             |\n| cloudap   | Cloud AP                                  | OAuth 2.0     | :heavy_check_mark: | 36     | `CLOUD_AP`      |\n| credssp   | Credential Delegation SSP                 | TLS+SPNEGO    | :heavy_minus_sign: |        |                 |\n| kerberos  | Kerberos                                  | Kerberos      | :heavy_check_mark: | 16     | `GSS_KERBEROS`  |\n| livessp   | Live SSP                                  | ?             | :heavy_check_mark: | 32     | `LIVE_SSP`      |\n| msapsspc  | DPA Client                                | RPA           | :heavy_minus_sign: | 17     | `DPA`           |\n| msnsspc   | MSN Client                                | NTLM          | :heavy_minus_sign: | 18     | `MSN`           |\n| msv1_0    | Microsoft Authentication Package v1.0     | NTLM          | :heavy_check_mark: | 10     | `WINNT`         |\n| negoexts  | Negotiate Extender                        | NEGOEX        | :heavy_check_mark: | 30     | `NEGO_EXTENDER` |\n| lsasrv    | Negotiate                                 | SPNEGO        | :heavy_check_mark: | 9      | `GSS_NEGOTIATE` |\n| pku2u     | Public Key User to User                   | PKU2U         | :heavy_check_mark: | 31     | `NEGO_PKU2U`    |\n| schannel  | Secure Channel                            | SSL/TLS       | :heavy_check_mark: | 14     | `GSS_SCHANNEL`  |\n| tspkg     | Terminal Services Package                 |               | :heavy_check_mark: | 22     | ?               |\n| wdigest   | Windows Digest                            | Digest Access | :heavy_check_mark: | 21     | `DIGEST`        |\n\n### Package Calls\n\nEach AP has the option to support receiving, processing, and responding to arbitrary requests from other software.\nThese requests are referred to as \u201cpackage calls.\u201d\nMaking a package call is officially supported for both user mode and device driver software through the use of the `LsaCallAuthenticationPackage` API.\n\nAside from wdigest, all APs that currently ship with Windows support handling package calls.\nAPs use this feature to support custom functionality that is not otherwise available through the standard SSP function table that an AP must implement.\nFor years, red teams and threat actors have abused some of this custom functionality (e.g., to recover Kerberos tickets).\n\nDespite a few of these package calls being well known, we noticed that the overwhelming majority of them have not been documented.\nOur interest is in identifying _all_ of the custom functionality that each AP supports through making package calls because we theorized that more would be abusable during an offensive operation.\nIf that has piqued your interest, read on!\n\n## Techniques\n\nDuring our research, we documented the package calls that are available for all APs that currently ship with Windows.\nWe narrowed these down to a subset which we believe to be useful and implemented support for the majority of this subset into LSA Whisperer.\n\nHere are the highlights of the package calls that may be made on a given host.\nAll package calls not mentioned in these highlights may be found on the project wiki.\nIf you are interested in a package call that is not implemented or you see an area of the wiki that can be improved, please submit an issue on GitHub or consider making a pull request (PR) for the project.\n\n### Kerberos\n\nWe will begin with the kerberos package as its package calls are more well-known in the industry.\nThe first thing of note, as with many APs, is the ability to use package calls to gather host enumeration data.\nWith the kerberos package you can show currently cached Kerberos tickets, domain extended policies (e.g., \u201cIs FAST Armouring enabled?\u201d), and how Kerberos is configured on that host.\n\nOf most interest to people is likely the package\u2019s ability to recover Kerberos tickets for active logon sessions or possibly its ability to cache a given Kerberos ticket to use on the host: a technique known as [\u201cPassing the Ticket\u201d (PTT)](https://attack.mitre.org/techniques/T1550/003/).\nOf less importance, but still of interest to offensive operations, is the package\u2019s ability to purge tickets, bind a domain name, and a pin domain name.\n\nTicket purging is helpful if you have done the PTT technique, the ticket you used is no longer operationally useful, and you need to remove it from your cache.\nAlthough most red team tools only support purging all tickets in your cache, we identified that the package allows you to selectively purge tickets, which provides the potential for a significant quality of life improvement for these red team tools.\nDomain name binding can help with performing the Golden Ticket technique as identified by [Martial Puygrenier](https://twitter.com/mpgn_x64/status/1241688547037532161) while domain name pinning has been shown by [James Forshaw and Nick Landers](https://www.youtube.com/watch?v=GM1PxZPiLMk) to allow for logical abuses of Kerberos.\nIn their case, they showed a local privilege escalation (LPE) to `SYSTEM` but people should look for other potential abuses of domain pinning as well \ud83d\ude42\n\nAll kerberos package calls are documented [on the kerberos page of the wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki/kerberos).\nThe relevant calls for the techniques presented in this section include:\n\n- `AddBindingCacheEntry`\n- `PinKdc / UnpinAllKdc`\n- `PrintCloudKerberosDebug`\n- `Query/Purge BindingCache`\n- `Query/Purge KdcProxyCache`\n- `Query/Purge TicketCache[Ex|Ex2|Ex3]`\n- `QueryDomainExtendedPolicies `\n- `QueryS4U2ProxyCache`\n- `Retrieve[Encoded]Ticket`\n- `SubmitTicket`\n\n### Cloud AP\n\nNext up is cloudap which manages Entra ID, AD FS, and Microsoft account logons.\nAs with kerberos, cloudap offers functionality for gathering basic information about the host and logon sessions managed by cloudap, such as if a partial TGT, also known as the \u201ccloud to on-premises TGT\u201d, is present in a local cache.\n\nWhile this information is helpful for troubleshooting logon issues, what is more interesting are the individual plugins that cloudap loads.\nCloudap currently has two plugins.\nThe first, known as AzureAD or AAD, manages Entra ID and AD FS logons.\nThe second, known as Windows Live ID or MSA, manages Microsoft Account logins.\n\nThe main thing of interest with these plugins is that they can be used to request a single sign-on (SSO) cookie to authenticate to an identity provider (IDP) as a target user.\nThe AAD plugin allows you to request an SSO cookie for Entra, AD FS, and an SSO cookie for your current device itself.\nAlthough we have not made a successful request yet to MSA, we are confident we will be able to request an SSO cookie for Microsoft Accounts from it as well because we have successfully done so with the legacy livessp AP that it is based on.\n\nOf less immediate impact but still of importance are the additional host enumeration options that the AAD plugin specifically offers.\nRed team tools typically gather cloud information using the `NetGetAadJoinInformation` Win32 API but this function notably lacks SSO information that can be gathered from other CLI tools such as `dsregcmd`.\nThe missing SSO information from this API may be gathered using the AAD plugin.\n\nAll calls for cloudap and the AAD plugin are documented [on the cloudap page of the wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki/cloudap).\nThe relevant calls for the techniques presented in this section include:\n\n- `GetAuthenticatingProvider`\n- `GetDpApiCredKeyDecryptStatus`\n- `GetPwdExpiryInfo`\n- `GetUnlockKeyType`\n- `IsCloudToOnPremTgtPresentInCache`\n- AAD -> `CreateSSOCookie`\n- AAD -> `CreateDeviceSSOCookie`\n- AAD -> `CreateEnterpriseSSOCookie` (Enterprise refers to AD FS)\n- AAD -> `DeviceValidityCheck`\n\n### Microsoft Authentication Package V1.0\n\nThe last package that we will cover in this post is the msv1_0 but more are covered on the wiki!\nMsv1_0\u2019s main purpose as an AP is to facilitate local machine logons.\nBeing the oldest of the APs, it has gathered other responsibilities such as managing DPAPI credentials, sending Netlogon requests, and generating data for NTLM messages to support its 2nd role as the security package for NTLM.\n\nDue to these additional responsibilities, msv1_0 was as fruitful in our findings as cloudap was in recovering credential material.\nThe first thing we identified is that msv1_0 allows you to recover the DPAPI \u201ccredential key\u201d of a logged-on user.\nThe term credential key is [described on the wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki/msv1_0#credential-key) and we plan to cover it further in a future blog, but if you recover a user's credential key you can decrypt their DPAPI master key file.\n**This process works even when Credential Guard is enabled.**\n\nThe next thing we identified is that msv1_0 allows you to generate an NTLMv1 response with a chosen server challenge value.\nThat works regardless of NTLMv1 being disabled using the `LmCompatibilityLevel` key in the registry (as needed by similar attacks such as [Internal Monologue](https://github.com/eladshamir/Internal-Monologue)) but we believe it to not work if Credential Guard is enabled.\nThe importance of being able to acquire an NTLMv1 response, especially with a chosen server challenge, is that it is trivial to crack to a usable NT hash for pass the hash (PtH) techniques and other tradecraft.\nSome online resources such as [crack.sh](https://crack.sh/) will even [crack these responses for free if the response has a specific server challenge](https://crack.sh/netntlm/) which we can guarantee.\nThe cracking process will also be instant for crack.sh due to its use of a rainbow table for these free requests.\n\nAll calls for msv1_0 plugin are documented [on the msv1_0 page of the wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki/kerberos).\nThe relevant calls for the techniques presented in this section include:\n\n- `GetCredentialKey`\n- `GetStrongCredentialKey`\n- `Lm20GetChallengeResponse`\n\n## Dead Ends\n\nSecurity researchers often celebrate their successes and hide the setbacks.\nI thought that, for a change, it would be good to share what didn\u2019t work out as we had hoped.\nMost research efforts are unsuccessful and if we start sharing those as well, maybe it will encourage more people to try, and maybe others will be able to build on our unfinished work and ideas to overcome the obstacles that hindered our progress.\n\n### Transferring Credentials as an Alternative to Token Theft\n\nSeveral packages have a `TransferCreds` call, which, as the name suggests, either transfers or duplicates the credential material from one logon session managed by the package into another one.\nOur idea for these calls was to use them as a new, alternative technique for [Access Token Theft](https://attack.mitre.org/techniques/T1134/001/).\n\nToken theft was introduced back in 2008 by [Luke Jennings](https://twitter.com/jukelennings) with the [release of Incognito](https://www.exploit-db.com/docs/english/13054-security-implications-of-windows-access-tokens.pdf).\nIt was a game-changing technique that allowed attackers to use the credentials of other logged-on users without targeting LSASS.\nNowadays, many EDRs can detect this technique and its variants, but more importantly Windows will purge any credential material that is no longer being used by a process or thread after a user logs off, limiting the window of opportunity for this attack.\nIn 2022, [Will Schroeder](https://twitter.com/harmj0y) released [Koh](https://posts.specterops.io/koh-the-token-stealer-41ca07a40ed6), a tool that can force Windows in some circumstances to maintain credentials past when a user logs off to extend this window of opportunity.\n\nWe believed that the `TransferCreds` call had a similar potential for abuse.\nOur idea was for an attacker to either create a new logon session or use an existing \u201csacrificial\u201d logon session they controlled, then transfer the credentials of a logon session for a target user into the attacker controlled session.\nThat would allow an attacker to use a user\u2019s credentials well after they logged off and without generating token duplication and impersonation activity which may be viewed as suspicious.\n\nThis call is available in the msv1_0, kerberos, cloudap, and in negotiate APs. The msv1_0 package prevents any process other than LSASS itself from making the call. Supporting this is outside the scope of the project because if you can execute code inside LSASS to make this call, then you already have the ability to directly recover credentials from LSASS\u2019s memory and makes this call unnecessary.\n\nThe kerberos package allows other processes to make this call but it will remove all Kerberos tickets and Kerberos keys from the source logon session.\nThat should not disrupt the user\u2019s experience when accessing services that use Negotiate to authenticate because their logon session will fallback to using NTLM, but it would disrupt their ability to use services that only use Kerberos to authenticate.\nOnce you transfer tickets to another session, you _can_ transfer them back.\nSo it may still offer value to attackers by allowing them to temporarily transfer tickets to a controlled logon session to use, possibly bypassing any token stealing, ticket dumping, or PTT tradecraft telemetry that would normally occur when stealing a user\u2019s Kerberos tickets.\nIf you have other ideas on how this call may be used, we would love to hear it!\n\nWe did not have time to investigate the behavior of cloudap\u2019s implementation, but we believe it will have the same effect as the kerberos package.\nLastly, the negotiate package\u2019s implementation will simply forward the `TransferCreds` call to whichever package was used for a negotiated logon session making the previously mentioned issues all issues for the negotiate package as well.\n\n### Passing the Hash\n\nNTLM is a built-in challenge-response authentication protocol on Windows.\nIn the protocol, a client will prove their possession of a password by using a derivation of it, the NT hash, to either encrypt or generate an HMAC of a challenge given by the server they are attempting to connect to.\nThe NT hash\u2019s use as a key exposes the authentication flow to Pass-the-Hash (PtH) attacks in which an attacker may craft a valid response to a server challenge by knowing a user\u2019s NT hash without knowing their cleartext password.\n\nWith the exception of Mimikatz, all the tools that implement the PtH attack do so by implementing an NTLM client to allow for client responses to be generated using an NT hash instead of a user\u2019s password.\nMimikatz offers the only alternative solution.\nMimikatz\u2019s approach is to create a new logon session on a Windows host, identify the location of that session\u2019s NT hash in LSASS\u2019s memory, then overwrite it with a specified NT hash.\nThat forces any process that uses that new session to use the specified NT hash when authenticating to another host using NTLM.\nMimikatz takes this approach because there are no Windows APIs that allow a logon session to be created using a specified NT hash.\nThe approach may make LSASS unstable because it is modifying its memory but is the only on-target option when a networked based tool cannot be proxied on.\n\nThe msv1_0 package offers the `CacheLogon` call that allows a user to cache a specified NT hash into an active logon session.\nIf a logon session has a cached NT hash, it will be used for NTLM authentication instead of the actual NT hash for the session\u2019s user account.\nThe kerberos package, as an example, uses this call in passwordless authentication scenarios.\nDuring these scenarios, such as smartcard logons or Windows Hello for Business, the PKINIT authentication scheme will be used and the domain controller (DC) will send an encrypted copy of the user\u2019s NT hash to the kerberos package.\nThe kerberos package will decrypt the user\u2019s NT hash then use msv1_0\u2019s `CacheLogon` call to store it for the newly created logon session to use.\n\nWe wanted to use the `CacheLogon` call in the same way the kerberos package does to have a logon session use a known NT hash for NTLM authentication.\nDoing so should provide a more stable solution than Mimikatz to do a PtH attack with on-host or non-proxied tooling because it does not require overwriting LSASS memory.\nThere are also complementary calls that you can pair with `CacheLogon`, such as `CacheLookup`, which can inspect the current msv1_0 cache for a logon session, and `ClearCachedCredentials`, which you can use to remove a cached NT hash for a logon session when you are done using it.\nUnfortunately, just like the `TransferCreds` call, msv1_0 only allows the `CacheLogon` call to be made from the LSASS process itself.\nWe are still interested in supporting these features for hosts where LSASS does not run as a PPL, such as a user-controlled VM that is proxied into a target network for a red team assessment, but we have not implemented them yet.\n\n### Bypassing \u201cLSA Only\u201d Checks with Passthrough Calls\n\nWe have mentioned three calls so far that can only be made by the LSASS process itself; namely the `CacheLogon`, `CacheLookup`, and `TransferCred` calls for msv1_0.\nWhen any of these calls are made, they will check whether the information for the client request is zero, which will only happen if the client is LSASS itself and, if the information is not zero, return with an error code of \u201caccess denied.\u201d\n\nWe can implement a solution when LSASS is not running as a PPL by injecting code into LSASS that will make these calls from within the process, but we wanted to know if there was an alternative solution that would not require code injection.\nIndeed, there almost was!\n\nIn our investigation, we looked at an msv1_0 package call named `GenericPassthrough`.\nThe `GenericPassthrough` call takes an arbitrary AP request and sends it using Netlogon to a DC for processing.\nThe kerberos package, as an example, supports a `VerifyPac` call and domain joined hosts will send `VerifyPac` requests to a DC using a `GenericPassthrough` call to have the DC verify a Kerberos ticket\u2019s PAC information.\n\nAn interesting thing we noticed is that when a host is not domain joined, msv1_0 will reissue any AP request it receives via `GenericPassthrough` back to the local LSA instance itself.\nThat is done to support certain workgroup activities, but the important thing is that msv1_0 will view the final reissued AP request as coming from the LSASS process.\nWe also believe msv1_0 can be tricked into believing the host is not domain-joined to reissue an AP request for us by temporarily stopping the Netlogon service and unsetting a specific named event that is set when the service is started.\n\nUnfortunately, we found that even if we implemented the code to trick msv1_0 into reissuing an AP request for us to bypass the \u201cLSA only\u201d check that some calls make (e.g., msv1_0\u2019s `CacheLogon`), we found that the final request would be considered a \u201cpassthrough request.\u201d\nAPs typically restrict passthrough requests from clients to only a small subset of the full list of AP requests a client could normally make.\nAs an example, kerberos only allows `VerifyPac` as a passthrough request and msv1_0 only allows the `SubAuth` request to facilitate its \u201csub-authentication package\u201d concept.\n\nThe key takeaway is that although it may be possible to trick msv1_0 into reissuing an AP request to bypass an \u201cLSA only\u201d check, we would not be able to use this approach to make any of the calls we are interested in: msv1_0\u2019s `CacheLogon`, `CacheLookup`, and `TransferCred` calls.\nWe still like to support these calls but currently plan on implementing a solution that requires injecting code into LSASS to do so.\n\n### Dumping NT Hashes\n\nThe `GetCredentialKey` and `GetStrongCredentialKey` calls for msv1_0 return a DPAPI \u201ccredential key\u201d for a logon session.\nAs mentioned in the technique section on msv1_0, we plan to cover credential keys more in a future blog.\nWhat is important to know, though, is that in some not-so-common situations the credential key is actually just the user\u2019s NT hash!\n\nWhen we first implemented these calls, we actually ran into this situation pretty reliably and kept getting the NT hash for our target user.\nWe had no clue what a credential key was, that it had anything to do with DPAPI, and that it is uncommon for these calls to give a user\u2019s NT hash.\nInstead, we thought we had found the ideal way to dump credential material from LSASS and we were excited.\n\nOur initial understanding turned out too good to be true, but with more investigation these calls became exciting to us in a different way.\nWe soon found that these calls instead produce the DPAPI credential key, which in those not-so-common edge cases happens to be the NT hash, but in all cases will be key material that you can use to decrypt the user\u2019s DPAPI master key file.\nWhen this key is also the NT hash, one of the requirements for this edge case is that the account is local.\nThat makes its recovery less important due to many alternative methods of extracting the same value from the local SAM.\n\nEither way, we decided to take the recovery of a DPAPI credential key as a win and later, almost by happenstance, we identified msv1_0\u2019s ability to generate NTLMv1 responses with a chosen server challenge value which, as described in the msv1_0 tradecraft section, is trivially crackable to an NT hash for the user.\nSo with more work we eventually got to our goal, but it was not as straightforward as we originally thought.\n\n### Dumping Kerberos Keytabs\n\nA keytab file stores Kerberos authentication keys for an account and they are typically used to automate user authentication without requiring user interaction.\nWhen we were investigating the kerberos package, we noticed it supported the RetrieveKeytab call.\n\nWe were hopeful we could use this call to generate a keytab file with Kerberos authentication keys for an account similar to Mimikatz\u2019s `sekurlsa::ekeys` command.\nHowever, this call requires the caller to supply a password.\nThe resultant keytab file will be populated with keys that are derived from that password instead of a password for an existing user account, making the call not too valuable to an attacker from our perspective.\n\n### Solving the Double Hop Problem\n\nWhen a user logs on to a remote host (the first hop) and then from that remote host attempts to log on to yet another remote host (the second hop), authentication to the second hop normally fails.\nThat is the Double Hop Problem.\n\nThe Double Hop Problem results from how authentication in Windows environments works, and it affects not only offensive operations but also legitimate system administration.\nThe logon session to the first remote host (the first hop) is a \u201cnetwork logon\u201d established using Kerberos or NTLM rather than with reusable credential material, such as a password or smartcard data.\nTherefore, the first hop host is not able to authenticate the user to the second hop.\nThe first hop simply does not have reusable credential material to perform that action.\n\nThere are several legitimate solutions to this problem, including Kerberos Delegation, Credential Delegation (supported by CredSSP), and Remote Credential Guard.\nAlthough not originally designed to solve the Double Hop Problem, the two approaches that are typically used in red teams include the [Kerberos Pass the Ticket (PTT)](https://posts.specterops.io/koh-the-token-stealer-41ca07a40ed6) technique and [creating a new logon session with explicit credentials](https://posts.specterops.io/koh-the-token-stealer-41ca07a40ed6).\nThe first approach is already achieved through an AP package call, specifically the `SubmitTicket` call for kerberos.\nThe second is not.\nInstead, it is achieved by using one of the `LogonUser` Win32 APIs which is what the Cobalt Strike\u2019s `make_token` command and its derivatives use.\n\nWhen investigating the package calls we could make, we noticed the `ChangeCachedPassword` call for msv1_0 and the `AddExtraCredentials` call for kerberos.\nWe thought that either could potentially allow us to apply a known password to an existing logon session.\nDoing so would solve the Double Hop Problem when using known passwords without requiring the `LogonUser` APIs to be called.\nThat would allow us to use a known password on a host without generating an event for a new logon session being created.\nBut that, too, turned out to be unviable.\nFrom testing, `ChangeCachedPassword` appeared not to apply to network logons and the `AddExtraCredentials` package did not appear to affect subsequent authentication attempts.\n\nEventually we found msv1_0\u2019s `CacheLogon` call, which may still achieve the same goal for us; namely, solving the Double Hop Problem when using a known password without generating a new logon session.\nThat call is described further in the \u201cPassing the Hash\u201d section, but we believe that on a host without LSASS running as a PPL we can pre-convert a known password to an NT hash and pass it to a `CacheLogon` call to use in an existing logon session.\nThe downside to this approach is that we would need to execute code in LSASS, which would likely create more telemetry than a single event for a new logon session.\n\n### Making Remote Calls\n\nThe SSP Interface (SSPI) RPC server that facilitates everything that LSA Whisperer does was designed to be used locally.\nThe server itself only registers an ALPC port to listen on for its endpoint which is only locally accessible.\nA core design of RPC, though, is that the RPC runtime allows you to send RPC requests for any RPC interface registered by a process to any RPC endpoint the process is currently listening on and the runtime will fulfill that request.\n\nAlthough the SSPI RPC server only registers a single ALPC port for an RPC endpoint, the LSASS process itself listens to many RPC endpoints, some of which are remotely accessible.\nWe wanted to make these SSPI RPC requests to one of these endpoints on a remote host.\nDoing so would allow LSA Whisperer to do things such as dump Kerberos tickets, DPAPI credential keys, and SSO cookies on a remote host.\n\nWouldn\u2019t that be nice?\nWell, (un)fortunately the SSPI RPC interface is registered with the `RPC_IF_ALLOW_LOCAL_ONLY` flag which forces the RPC runtime to only allow local RPC clients to interact with the interface.\nSo, if you have ever wondered if you can dump Kerberos tickets on a remote host, as far as we know it is not possible\u2013but we would be happy to be proven wrong! \ud83d\ude42\n\n## Mitigations\n\nThere are almost no built-in options for an administrator to prevent the package calls that LSA Whisperer makes.\nLSA Whisperer only uses intended functionality for Windows, and blocking its package calls from succeeding would prevent normal Windows authentication processes from succeeding.\nThat being said, enabling Credential Guard does block some of the DPAPI credential recovery commands and we believe also prevents NTLMv1 response generation using the primary credentials of an active logon session.\nOne DPAPI credential recovery command is still available with Credential Guard enabled, but blocking the NTLMv1 response generation prevents attackers from easily recovering a usable NT hash for the user.\nCredential Guard may affect commands that we did not observe during testing.\nIf you observe Credential Guard affecting a command which we missed please consider making [a PR to the wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki/Usage#known-limitations).\n\nThere are also almost no built-in options for administrators to monitor for LSA Whisperer and similar tools.\nThe largest potential is with monitoring via Event Tracing for Windows (ETW) which is used throughout all packages but not in a consistent or documented way.\nAdditional assistance from Microsoft with guidance on which ETW providers to monitor for and with publishing the message schemas for each would go a long way toward enabling Administrators to monitor these calls.\n\nPackage calls are now facilitated by the SSPI RPC server, so we also investigated using RPC features as a method to monitor for or prevent specific package calls.\nThere is an ETW provider named \u201cRPC Events\u201d that gives some insight into all RPC activity, including activity facilitating a package call, but in our opinion it does not provide enough insight to effectively monitor this activity.\nWe investigated using Windows\u2019s built-in RPC filters mechanism but it does not provide the granularity needed for effective monitoring or prevention of package calls.\nLastly, we investigated using the [RPC firewall](https://github.com/zeronetworks/rpcfirewall), a popular FOSS third-party solution maintained by [Zero Networks](https://zeronetworks.com/).\nAlthough the solution appears to be a promising solution for administrative needs, it does not prevent local RPC traffic and it is not compatible with LSA running as a PPL.\nThe SSPI RPC server only allows local RPC traffic so the RPC firewall is not applicable for this need.\nEven if it did, allowing LSA to not run as a PPL would offer attackers the ability to use Mimikatz and related tools to directly recover credentials from LSASS\u2019s memory, making the alternative approach that LSA Whisperer takes debatably unneeded.\n\nUltimately, our recommendations for administrators include:\n\n1. Enable LSASS to run as a PPL\n2. Enabling Credential Guard\n3. Log off machines when you are through using them\n4. Use [Privileged Access Workstations/Devices](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices) and follow the [Clean Source Principle](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-success-criteria#clean-source-principle)\n\nEnabling LSASS to run as a PPL does not affect LSA Whisperer but does make it more difficult for attackers to use other tools that directly recover credentials from LSASS\u2019s memory.\nCredential Guard largely unaffected LSA Whisperer but we believe it will block LSA Whisperer\u2019s ability to generate an NTLMv1 response with a primary credential for an active logon session.\nThat prevents attackers from easily gaining a usable NT hash for a user.\nLastly, a large portion of LSA Whisperer\u2019s functionality is only usable when there is an active logon session in the first place for it to request credentials from.\nBy fully logging off machines that you are done with, you will remove the resource that a large part of LSA Whisperer\u2019s functionality uses.\nThe last recommendation is a general architectural best practice for securing access to end user devices in the first place.\n\nThis summarizes our recommendations to administrators for what we believe directly affects LSA Whisperer but there are settings you may enable to further strengthen Credential Guard.\nThese settings are documented on a [dedicated page on Microsoft\u2019s learning portal](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/additional-mitigations).\nNot all of these settings may be feasible for your organization to enable but we do recommend the ones that are.\n\n## EDR Recommendations\n\nEndpoint Detection and Response (EDR) vendors, including Microsoft themselves, are likely in the best position to monitor for and prevent the use of LSA Whisperer and similar tools. These are what we recommend EDRs monitor for:\n\n1. Calls to the `LsaCallAuthenticationPackage` Win32 API\n2. Interaction with ALPC port `lsasspirpc`\n\nOur belief is that most EDR vendors already monitor calls to `LsaCallAuthenticationPackage` but only for detecting Keberos ticket recovery and PTT techniques.\nVendors should instead view this as an API that facilitates all of the functionality LSA Whisperer offers.\nSome attackers may choose to circumvent this API by interacting with the SSPI RPC server directly.\nThe intended RPC endpoint for the SSPI RPC server is the `lsasspirpc` ALPC port. So we recommend that EDRs monitor for processes that interact directly with that endpoint instead of using the Win32 API.\nLSA Whisperer itself may be used to test this as it will interact with the ALPC directly by default.\nLastly, we recommend that EDRs prevent the following activity:\n\n1. Calls to LSASS RPC endpoints _other than_ `lsasspirpc` for interface `4f32adc8-6052-4a04-8701-293ccf2096f0` (SSPI)\n\nA well known technique to circumvent the monitoring of a specific RPC endpoint is to send the same RPC requests to any other endpoint hosted by the process running the RPC server.\nThat works because the RPC runtime allows you to send RPC requests for any RPC interface registered by a process to any RPC endpoint the process is currently listening on and the runtime will fulfill that request.\nAttackers may use this approach to bypass additional monitoring of the `lsasspirpc` ALPC port but legitimate software will never do this.\nInstead, legitimate software will only interact with the `lsasspirpc` ALPC port using the documented Win32 API.\nSo preventing all SSPI RPC requests to any RPC endpoint other than the `lsasspirpc` ALPC port should be safe to do and provide a true positive detection.\n\n## Conclusion\n\nWe touched on several topics in this post, but what I want you to take away is that most (and possibly all) of the credentials an attacker needs to accomplish their objectives on a Windows operation can be achieved without accessing LSASS\u2019s memory.\nYou do not even need to open a handle to LSASS.\nIn the right situation, you can get what you want if you ask LSA nicely.\n\nDo you need Kerberos tickets?\nWait for the target user to login, impersonate the user or `SYSTEM`, and then ask LSA to give them to you using normal \u201cticket dumping\u201d tradecraft.\nDo you instead need an NT hash for PtH tradecraft?\nAssuming Credential Guard is disabled, impersonate `SYSTEM`, request an NTLMv1 response for a logon session of the target user with a chosen server challenge, then crack it to a usable NT hash for the user.\nDo you instead need access to the plethora of user data encrypted with DPAPI?\nImpersonate `SYSTEM`, request the DPAPI credential key for a logon session of the target user, then use it with [SharpDPAPI](https://github.com/GhostPack/SharpDPAPI) to decrypt their DPAPI master key file.\nDo your red team assessments now include cloud-based objectives?\nImpersonate a cloud-based user logon session then request LSA to give you a SSO cookie for that account.\n\nIf you like this work, please checkout the [LSA Whisperer project on GitHub](https://github.com/EvanMcBroom/lsa-whisperer)!\nThe project also includes [an extensive wiki](https://github.com/EvanMcBroom/lsa-whisperer/wiki) for all of the research that was done.\nYou can use the [building guide](https://github.com/EvanMcBroom/lsa-whisperer?tab=readme-ov-file#building) in the project\u2019s readme file and the [usage guide](https://github.com/EvanMcBroom/lsa-whisperer?tab=readme-ov-file#building) on the project\u2019s wiki to get started.\nFor the SOCON presentation, [the slides are available on Github](https://github.com/SpecterOps/presentations/tree/master/SO-CON%202024/Evan%20McBroom%20-%20LSA%20Whisper) and video will be available for free on [SpecterOps\u2019s YouTube channel](https://www.youtube.com/@specterops) once it is released.\nIf you have a question, you can reach out to me in the [BloodHoundGang Slack team](https://ghst.ly/BHSlack) or by [starting a discussion on GitHub](https://github.com/EvanMcBroom/lsa-whisperer/discussions).\nI will do my best to respond to questions as I am able to.\nIf you see an area where the project or wiki can be improved, please submit an issue on GitHub or consider making a pull request for the project.\nYour contributions are appreciated!\n\nLastly, thank you - the reader - for taking time to check out this work.\nIt was a pleasure to do and I hope you enjoyed reading it.\n\n## Updates\n\n- Apr 19, 2024: Our original understanding for the purpose of the `CacheLogon` call was incorrect which [Alex Short](https://twitter.com/alexsho71327477) reached out to help clarify.\nKerberos does not decrypt data before caching it.\nThe data is only stored in the registry under `HKLM\\Security\\Cache` for later recovery by using the `CacheLookup` call.\nThis is the same cache used by `LsaApLogonUserEx2` to store user data for future logon attempts when Netlogon is unavailable.\nLastly, the cached data is not used for NTLM authentication which removes these calls as a possibility for performing Pass the Hash.\nThank you Alex for the help understanding these calls!", "creation_timestamp": "2026-05-17T09:21:53.000000Z"}, {"uuid": "777d2149-ed4d-496a-abe6-7ff738b24bdb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-26201", "type": "seen", "source": "https://t.me/ctinow/206064", "content": "https://ift.tt/3hMuoN2\nCVE-2024-26201 | Microsoft Intune Company Portal on Android Intune Linux Agent unknown vulnerability", "creation_timestamp": "2024-03-12T19:52:26.000000Z"}]}