SSPs are DLLs that either implement a security protocol (security packages - SPs) and/or authentication logic (authentication package - APs). The LSA Whisperer project largely focuses on the authentication logic contained in an SSP. As such, the project will refer to SSPs that support both a security protocol and authentication logic as an authentication package (AP).

The below table provides a summary of the SSPs that have been released by Microsoft over the years. LSA Whisperer supports interacting with a subset of the below SSPs that are marked as APs. Please refer to the individual wiki page for each SSP to see which commands the project supports for each AP.

Livessp, msapsspc, and msnsspc are legacy SSPs that have been removed from Windows. The components for the distributed computing environment (DCE), kernel, and message queue (MQ) RPC authn options could not be identified for auditing. Lastly, the DEFAULT RPC authentication method, RPC ID -1, is intended to be used as an alias for an NTLM SP (e.g., msv1_0); though, the sfapm AP also reports its RPC ID as -1.

A table of common 3rd party SSPs is provided below. LSA Whisperer does not provide support for these SSPs.

An authentication package (AP) is any SSP that implements the LSA_AP_ prefixed function types in its SECPKG_FUNCTION_TABLE function table during the package’s initialization by LSA. Of these, LSA whisperer focuses on the set of "call package" functions which allows 3rd party code to interact with an AP’s custom functionality. These functions are named CallPackage, CallPackageUntrusted, and CallPackagePassthrough.

A client will normally use these functions when calling LsaCallAuthenticationPackage. That Win32 API will be facilitated by an AP’s CallPackage or CallPackageUntrusted function depending on if the client has the TCB privilege or not, respectively. LSA whisperer itself is a client application and almost every command the tool implements will interact with one of these two functions.

A client will be required to specify a package ID when making this call. LSA Whisperer will obtain these IDs automatically for the user using LsaLookupAuthenticationPackage. Clients may alternatively use a special package ID, SECPKG_ALL_PACKAGES or -2, which LSA will handle by issuing the call to all loaded APs. There is a small set of calls that are intended for this feature which each AP may choose to process or ignore. These intended calls and the APs that support them are provided below. These commands may be issued with LSA Whisperer using the all command (ex. all PinDC).

The CallPackagePassthrough function is only used when a request is encapsulated in a GenericPassthrough message and sent as a package call to msv1_0. For a domain joined host, msv1_0 will send the encapsulated request via NetLogon to the LSA on the DC for processing. For a workgroup host, msv1_0 will issue the encapsulated request itself within LSA. Once an LSA receives the request it will be processed by the requested AP’s CallPackagePassthrough function.

An AP may not support passthrough requests and the ones that do will typically limit clients to a small set of request types. The current list of allowable passthrough requests is provided below. LSA Whisperer does not currently support issuing passthrough requests.

Windows does not specify a security callback function when registering the SSPI RPC interface. It does however register the interface with the flag RPC_IF_ALLOW_LOCAL_ONLY. That prevents LSA Whisperer from interacting with a remote host using this interface.

The only additional check the RPC server performs is to verify that a client is local if it requests the SspirGetInprocDispatchTable operation. This check is redundant and does not affect LSA Whisperer. For other operations, no client verification is done by the server and the SSPI server passes execution in almost all cases to an equivalently named function in the LsapSspiExtensionFunctions table inside lsasrv (the internal function will be prefixed with the name SspiEx). The lsasrv will then pass execution to the original LPC handlers (ex. LpcHandler). Please refer to the SPM page if you would like more information about these LPC handlers.

It is also worth noting that the RPC runtime has a hardcoded list of interfaces that are exempt from multiple security mitigations that have existed since NT 5.2. The list is named RpcVerifierExemptInterfaces and may be found by viewing its use in the rpcrt4.dll!IsInterfaceExempt function. The list includes multiple RPC servers that have been previously abused such as MS-DFSNM, MS-EFSR, MS-SRVS, and MS-WKST.

Interestingly, Microsoft has only added 2 interfaces to this list since NT 5.2. One is the Remote Management interface and one is SSPI. Microsoft has also added 1 additional mitigation bypass which has only been applied to SSPI (flag 0x8). Each mitigation bypass that Microsoft may specify is provided below. All of these bypasses have been applied to the SSPI interface. Microsoft’s need for doing this has still not been determined.