Multiple types of Windows logons add to our knowledge about successful or failed logons of a user. Logon types let us know whether a user was in front of a computer, connected remotely, unlocked a save screen, or perhaps a service rather than a person. Knowing the way a user connected gives us a tool to separate suspicious logons from benign ones.
Interactive logon processes begin either when a user enters credentials in the entry dialog box, when the user inserts a smart card into the smart card reader, or when the user interacts with a biometric device. Users can perform an interactive logon by using a local user account or a domain account to log on to a computer.
- Type 2 - Interactive
- Type 3 - Network
- Type 7 - Unlock
- Type 10 - RemoteInteractive (Terminal services, RDP)
________________________________________
| local computer |
----------------
| Winlogon |
^^
||
vv
| GINA | _(GINA: Graphical Identification & Authentication, LSA: Local Security Authority)_
|
(LsaLogonUserfunction) -----> | LSA | ---> | Auth pkg |
__________________________________________
GINA is a DLL loaded by the Winlogon process that implements the authentication policy of the interactive logon model, performs all identification and authenticates user interactions.
Non-interactive user Logon is performed by a client app or an OS component on behalf of a user. These logons do not require the user to supply an Authentication factor. Instead, the device or client app uses a token or code to authenticate or access a resource on behalf of a user. These logons happen in the background of the user’s activity.
_______________________________
| Auth pkg | <---> | LSA |
^
|
v (_SSP(I): Security Support Provider (Interface)_)
| SSP | <---> | SSPI | <---> | Client app | (_i.e. Outlook Express_)
________________________________
Domain logons combine necessary elements for a local logon, such as account name and password or certificate, as well as Active Directory domain information.
The Logon Process field in a Windows security event log provides a hint at how a user tried to access the system: at its console, through Server Message Block (SMB – for shared files) or Common Internet File System (CIFS - network filesystem protocol used for providing shared access to files and printers) for shared-folder access, or through IIS. Some logon processes are authentication-protocol specific.
| Process | Explanation |
|---|---|
| Winlogon | Windows Logon Process |
| Schannel | Secure connection such as SSL/TLS |
| Secondary Logon Service | "runas" - SecLogo |
| IKE | Internet Key Exchange protocol process |
| Advapi | Web-based logon: IIS logon processes |
| PKU2U | User-2-User Public Key Cryptography |
| Kerberos | Ticket-based, for secure node communication over non-secure network/domain |
| NtLmSsp | NT LAN Manager; hash-based - used locally |
An SSP is a software module that performs security validation.
Negotiate – SSP that acts as application layer between SSPI (interface) and other SSP. When an application calls into SSPI to log on to a Network, it calls Negotiate, that can choose the best SSP to handle the request based on customer-configured security policy.
KERBEROS protocol security package - industry-standard security package. Has 3 parts: Client, Server and Key Distribution Center with 2 components: Authentication service and Ticket-granting-Ticket service.
NTLM Security Package* - This was the primary security package for NTLM (NT (New Technology) LAN Manager) networks. Uses Hashes. Two parts: Client and Host. Works with generated hashes sent over a Network.
SCHANNEL SSP - implements the Microsoft Unified Protocol Provider security package, which unifies SSL, private communication technology (PCT), and TLS into one security package. Schannel is primarily used for Internet applications that require HTTPS communications.
WDIGEST - a challenge/response protocol that was primarily used in Windows Server 2003 for LDAP and web-based authentication. It utilizes HTTP and Simple Authentication Security Layer (SASL) exchanges to authenticate.
Logging in on a local computer, typing in the username and password. User logs in with a local or domain account. This type will appear only when a user authenticates in the domain (by a domain controller). If the DC is not available, but the user provided valid domain credentials cached in the local PC, Windows will log an event with Type 11 (CachedInteractive). A local logon grants a user permission to access Windows resources on a local computer. A local logon requires that the user has an account in the Security Accounts Manager (SAM) on the local machine.
Authenticators: Password, Smartcard
A computer is accessed from the network. Mostly involves connecting to shared resources (shared folders/printers). A network logon grants a user permission to access Windows resources on the local machine in addition to any resources on networked computers, as defined by the credential's access token, after local authentication. Most logons to Internet Information Services (IIS) are Type 3, with the exception of basic auth (type 8). Because IIS is a service for website hosting that can be put on on a Windows machine, it is like accessing a machine from a Network.
Authenticators: Password, Kerberos ticket, NT hash
This logon type concerns scheduled tasks. When Windows executes a scheduled task, the scheduled task service first creates a new logon session for the task so that it can run under the authority of the user account specified at the time of task creation. Logon type 4 are usually benign but a malicious user could try to guess the password of an account via scheduled tasks. Such attempts would generate a logon failure event (4625) with a logon type = 4. Logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation, or from the password being changed without modifying the scheduled task.
Authenticators: Password (usually LSA secret)
Each service is configured to run as a specified user account (i.e. running Apache Tomcat as Administrator). When a service starts, Windows creates a logon session for the specified user account which results in an event with logon type 5. Failed logon events with type 5 usually indicate the password of an account has been changed without updating the service.
Authenticators: Password (usually LSA secret)
Type 7 occurs when a user returns to a computer and unlocks it. Type 7 failures indicate entering a wrong password into an unlock window. Successful logons to domain controllers with type 7 should be monitored.
Similar to logon type 3, but the password was sent over the network in clear text. Windows servers do not allow connection to shared files or printers with clear text authentication. Cleartext logons can come from within an ASP script, using Advanced Windows Base API (ADVAPI), or when a user authenticates to IIS using IIS basic authentication mode. In both cases, the logon service will be ADVAPI. This authentication is dangerous if not communicated over HTTPS/SSL.
Using the RunAs command to start a program under a different user account, and specifying the /netonly switch. Using runas /netonly allows a user to run an application locally as themselves while authenticating over the network as another user. With the /netonly flag, Windows will run the the program on the local computer and on the network as the same user, and records the logon event as Type 2.
runas /user:<user-to-impersonate> /netonly <cmd>
When accessing a computer via Terminal Services, Remoted Desktop (RDP), or Remote Assistance, Windows will log the attempt as Type 10. Remote Interactive logins to the domain controllers should be monitored.
Windows supports a feature called Cached Logons which facilitate mobile users. When a user is not connected to the organization's network and authenticates to their laptop with a domain account, there is no DC available to the laptop to verify the identity. To solve this issue, Windows caches a hash of the credentials of the last 10 interactive domain logons. Windows uses these hashes to verify the user's identity when no DC is available.
Authentication packages are DLLs that perform authentication checks
- MSV1_0
- Kerberos
- NTLM
- LogonUI.exe - credential provider process, collects creds from the user (name/password/PIN) and passes to the system
- winlogon.exe - handles logon/logoff, launches LogonUI, intercepts logon requests from keyboard
- winlogon.exe calls lsass.exe that contains authentication providers (default: MSV1_0, Microsoft ID Package)/Kerberos/NTLM. Once a package authenticates a user, Winlogon continues the logon process for that user. If none of the authentication packages indicate a successful logon, the logon process is aborted
- Username and hashed password are sent to local SAM (Security Account Manager), the DB file that stores passwords for account info and restrictions