How does LSA authentication on Windows work?

Question

I'm trying to understand the security protocols on Windows from a high level as part of legal research into cybercrime, and I'm having difficulty figuring out where to focus my research.

I've already gone down the LSA authentication model path, because that is what the Flame virus used (somehow) to get itself access to services. At least according to this security firm. However, and I know I'm missing something, it looks like programs can just grant themselves access to the system.

I read through this post on Live ID, and Windows Authentication, but that's not what I'm interested.

Kerberos seems solely concerned with interactions between different boxes. Similarly, NTLM doesn't seem concerned with local activity on the computer. Which brings me back to LSA authentication.

I know that I'm missing some steps here, because it looks like you can just call LsaLogonUser(), and assuming you have the credentials (do you have to steal these?), do whatever you want. I found this image from this article, but to be honest, I'm only vaguely sure of what I'm looking at:

Answer 1

That diagram is very accurate for XP and previous. The reason it is so complicated is the several levels of abstraction involved.

There are two primary (as in, "most used") ways of logging into Windows - as a standalone workstation user, and as a member of a domain. In both cases, on XP those credentials pass through the LSA client and its server.

At the backend, then, LSA must determine "who to ask" to determine if the credentials are indeed valid. That's where the "negotiate" block comes in - which will do one of two things:

• If the system is configured as a workstation, use the NTLM scheme as configured on the box and talk to the SAM database.
• If the system is configured as part of a domain, talk to the server to see what it supports, and give it what it needs.

In essence, this process isn't all that different from negotiating what sort of hashing to use for say a HTTP authentication method: the server says what it wants (PLAIN, DIGEST, MD5) and I send the password as needed.

There is an allusion to other credential types fitting in here in the form of "msgina.dll". This is the component responsible for talking to the user after Ctrl+Alt+Delete and can be replaced to provide new UI such as fingerprint and smart card logon. In each of these cases, LSA must still talk to the backend database (whereever that is) to get an authentication token of some form.

You can also add extra authentication protocols to LSA via LSA providers. This is the corresponding "talk to the authentication database to determine if this is a valid user" component and you can read about these components here and directions for how to write one here.

Now, once this process is complete, the user is handed an authentication token called an access token. UAC aside, presenting this token is how processes indicate to the system they are already authorised to act on behalf of the user.

This is what is going on and how LSA and the various components fit together.

Now, part two of my answer. Flame targeted LSA for two reasons:

• It is estensible. You can register new authentication protocols, new GINA/Credential Providers (XP/Vista+ respectively).
• It runs on boot of the system, with NT AUTHORITY\SYSTEM privileges.

This makes it a marvellously good place from which to launch your malware and remain persistent on the system. See this analysis

As you can imagine, there are checks and balances preventing any old program from installing itself there and even being run there, by means of Authenticode. However, Flame used a stolen certificate to bypass this, which is where things got interesting. The information, specifically the Common Name, contained in the authenticode certificate is displayed as part of the authenticode warning dialog. So in this case, the malware would actually appear to be authored by "Microsoft Corporation". Once they click OK and run Flame with elevated privileges, it then has all the access it wants. It can then register itself as an LSA provider and will then be run automatically each time the system starts.