Terms

An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token signing certificate.(Citation: Microsoft SolarWinds Steps) The default lifetime of a SAML token is one hour, but the validity period can be specified in the <code NotOnOrAfter</code value of the <code conditions ...</code element in a token. This value can be changed using the <code AccessTokenLifetime</code in a <code LifetimeTokenPolicy</code .(Citation: Microsoft SAML Token Lifetimes) Forged SAML tokens enable adversaries to authenticate across services that use SAML 2.0 as an SSO (single sign on) mechanism.(Citation: Cyberark Golden SAML)

Adversaries may attempt to extract credential material from the Security Account Manager (SAM) database either through in memory techniques or through the Windows Registry where the SAM database is stored. The SAM is a database file that contains local accounts for the host, typically those found with the <code net user</code command. Enumerating the SAM database requires SYSTEM level access.

An adversary with root access may gather credentials by reading ’s memory. is a service/daemon responsible for implementing security protocols such as encryption and authorization.(Citation: Apple Dev SecurityD) A privileged adversary may be able to scan through 's memory to find the correct sequence of keys to decrypt the user’s logon keychain. This may provide the adversary with various plaintext passwords, such as those for users, WiFi, mail, browsers, certificates, secure notes, etc.(Citation: OS X Keychain)(Citation: OSX Keydnap malware)

Single sign on (SSO) allows a user to authenticate once and access multiple services without re authenticating.

An adversary may steal web application or service session cookies and use them to gain access to web applications or Internet services as an authenticated user without needing credentials. Web applications and services often use session cookies as an authentication token after a user has authenticated to a website.

Adversaries may perform sudo caching and/or use the sudoers file to elevate privileges. Adversaries may do this to execute commands as other users or spawn processes with higher privileges.

Adversaries may attempt to identify the primary user, currently logged in user, set of users that commonly uses a system, or whether a user is actively using the system. They may do this, for example, by retrieving account usernames or by using OS Credential Dumping. The information may be collected in a number of different ways using other Discovery techniques, because user and username details are prevalent throughout a system and include running process ownership, file/directory ownership, session information, and system logs. Adversaries may use the information from System Owner/User Discovery during automated discovery to shape follow on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.