Windows

• Network Analysis: Viewing Named-Pipes

  • Named-pipes are a method used by the Operating System to perform inter-process communication. Named-pipes can be either local or network-based.
  • List network-based Named-pipes, which can indicate processes communicating with another host (I.e. a file share or file upload).
• System Resource Usage Monitor (SRUM)

  The SRUM is a Windows feature that tracks the last 30 to 60 days of resource usage, such as:

  • Application and service activity
  • Network activity, such as packets sent and received
  • User activity (I.e. launching services or processes).

  In a database (SRUDB.dat) on the host, this can be found at C:\Windows\System32\sru\SRUDB.dat.
• Windows Firewall Logs

  • By default, Windows Firewall will log to C:\Windows\System32\LogFiles\Firewall.

  
• Host Files

  • Attackers use the hosts file to redirect traffic to something they control, as the host will take preference from the hosts file before reaching out to a DNS server.
  • For example, an attacker may be able to tell the host to send all traffic destined to http://exampledomain.com  (which is owned by the business) to the attacker's servers instead...whilst all the user will see is http://exampledomain.com.
• Querying WinRM Sessions

  • Windows Remote Management (WinRM) administers a system over the command line. This is useful for automated scripts (and the such) by the network administrators.
  • However, Attackers can abuse this same functionality in a stealthier way than connecting to a device over, say, RDP, to execute PowerShell commands remotely.
  • Querying WindowsRM sessions is essential, especially as sessions can persist (i.e. backdoors).
• Local User Accounts

  • Local user accounts are specific to a single computer, allowing users to access its resources and applications without the need for a network.
  • These accounts are managed directly on the computer, enabling users to log in, modify settings, and work independently.
  • Local accounts often have weaker password requirements, making them susceptible to brute-force attacks. They may be unnecessarily granted administrative rights, increasing the risk of misuse by allowing users to alter system settings, install unauthorized software, or access sensitive data
• Local User Accounts

  • Additionally, the lack of centralized control can lead to inconsistent security settings, exposing systems to risks due to irregular application of updates, patches, and antivirus definitions. Moreover, without centralized logging, monitoring local user activities is more difficult.
• Domain Accounts

  • Domain accounts are centrally managed through a domain controller, facilitating easier user access administration, security policies, and resource sharing.
  • These accounts allow users to log into any computer within the domain using the same credentials, simplifying access to network resources and applications.
  • Domain accounts are crucial for organizations operating in networked environments. However, they have their own security risks. If the domain controller is compromised, attackers can gain access to all connected systems and sensitive data
• Domain Accounts

  • Domain accounts are often targeted by phishing campaigns aimed at stealing credentials.
  • A single compromised domain account can lead to significant breaches, allowing attackers to move laterally across the network, accessing other systems and escalating privileges.
  • The centralized nature of domain accounts also means that insider threats can have a more substantial impact, as malicious insiders with domain credentials can cause widespread damage.
• System and Service Accounts

  • System and service accounts are special accounts within the Windows operating system and various applications, designed to ensure that software services and system processes function securely and efficiently
  • System accounts, such as Local System, Network Service, and Local Service accounts, are default accounts that interact with system resources to carry out essential system tasks.
• System and Service Accounts

  • Service accounts, on the other hand, are used by applications or services to interact with the operating system and can be set by the software or created by administrators for specific services, like SQL Server using a service account for operations.
  • Service accounts with excessive privileges can be exploited to gain unauthorized access or escalate permissions within the system. If not configured properly, they can allow attackers or malicious software to execute commands, access sensitive information, or disrupt essential services.
• Account Lifecycle

  • Account Creation: Creating new user accounts can serve legitimate needs or be a method for attackers to infiltrate a system. Logged events provide details such as the account's origin, creator, timestamp, and initial settings.
  • Account Modification: Changes to accounts, such as password updates, privilege changes, or attribute alterations, are logged. Examining these records helps identify unauthorized modifications.
  • Account Deletion: Deleting user accounts may be routine after an employee leaves, or it can indicate an attacker attempting to cover their tracks.
• User Artefacts in Windows Event Logs

  • Event ID 4720: A user account was created.
  • Event ID 4722: A user account was enabled.
  • Event ID 4738: A user account was changed, detailing modifications to an account's properties.
  • Event ID 4740: A user account was locked, indicating repeated failed login attempts or potential unauthorized access.
  • Event ID 4726: A user account was deleted, documenting when and by whom an account was removed from the system.

  These events are logged on individual Windows systems for local accounts and on domain controllers for domain accounts.
• User Artefacts in the Security Account Manager (SAM)

  • The Security Account Manager (SAM) is a Windows database storing user and system account information, holding critical forensic data about account activities such as creation, alteration, and deletion.
  • The SAM file, located at %SystemRoot%\system32\config\SAM, is locked while Windows runs but can be accessed from offline systems or forensic backups
• User Artefacts in the Security Account Manager (SAM)

  The SAM provides forensic data, including:

  • Account names of local users
  • Unique identifiers for each user
  • Local groups users are part of
  • Hashed representations of user passwords (not in plaintext)
  • Account activity status (active, disabled, or expired)
  • Last login timestamps
• User Artefacts in the NT Directory Services Database (NTDS.dit)

  The NT Directory Services (NTDS) database, or NTDS.dit, stores detailed information about domain user accounts, groups, and other directory service data within a networked domain environment. The NTDS provides information such as:

  • Usernames and full names of domain users
  • Security Identifiers (SIDs) for each user
  • Detailed group memberships, including global, domain local, and universal groups
  • Hashed representations of user passwords for domain accounts
• Analyzing the NTDS.dit for User-Related Artefacts

  • To analyze user-related data on a domain controller, the NTDS.dit file can be exported and examined using the DSInternals PowerShell module, designed for interacting with Active Directory databases in a forensic context.
  • ntdsutil.exe: Command-line tool for Active Directory database management.
  • "activate instance ntds": Specifies the 'ntds' instance for activation.
  • "ifm": Creates a full installation media set in the C:\Exports\ directory, including system state data and the NTDS database.
  • quit quit: Exits the ifm context and the utility.

  
• Boot key

  • The SYSTEM hive contains the system's boot key, essential for decrypting specific data within the NTDS.dit file. Without the boot key, security-related information like password hashes remains encrypted.
• Extracting the Boot Key

  Use DSInternals PowerShell to extract the boot key:

  • C:\> $bootKey = Get-BootKey -SystemHivePath 'C:\Exports\registry\SYSTEM'

  This command uses the Get-BootKey cmdlet from DSInternals to extract the boot key from the specified SYSTEM hive and stores it in the $bootKey variable.
• Authentication in Network Environments

  • Authentication is crucial for verifying user or entity identities before granting access to resources, ensuring that only authorized users or systems can access specific data or services.
  • Windows environments commonly use protocols like Kerberos and NTLM, which authenticate entities without transmitting sensitive information, such as passwords, in plaintext over the network.
  • These protocols use encryption to protect authentication processes, which generate extensive logs and forensic data.
• User Artefacts in Authentication Protocols

  Each authentication attempt, whether successful or not, generates specific event logs stored in domain controller logs.

  • Event ID 4624: An account was successfully logged on.
  • Event ID 4625: An account failed to log on.
  • Event ID 4768: A Kerberos authentication ticket (TGT) was requested.
  • Event ID 4771: Kerberos pre-authentication failed

  For instance, a series of failed logins (Event ID 4625) followed by a successful login (Event ID 4624) could suggest a brute-force attack.
• User Artefacts via Network Traffic Analysis

  • IP Addresses and Hostnames: Identify the entities involved in authentication, tracing the request's origin and target.
  • Authentication Protocols: Provide insights into the used authentication mechanisms, such as Kerberos or NTLM, including fields that show the authentication type and security implications.
  • Timestamps: Help establish the sequence of events and the timing of authentication attempts.
• User Artefacts via Network Traffic Analysis

  • Success and Failure Indicators: Codes and messages in network packets indicate the outcome of authentication attempts, distinguishing between successful and failed attempts.
  • Payload Data: Though usually encrypted, payload data can sometimes provide extra context about the request, particularly in unsecured transmissions.
• NTLM authentication relies on a 3-way handshake:

  1. The first stage of this handshake is Negotiation, which can be seen in Frame 11
  2. The second stage is the Challenge in Frame 12
  3. The third stage is Authentication, which can be seen in frame No. 13.

  
• Group Policy Objects (GPOs)

  • Group Policy Objects (GPOs) are a powerful tool for managing settings for users and computers within a network domain. They provide extensive control over network resources, which can make them an attractive target for threat actors.
• Group Policy Objects (GPOs): Common Uses for Attackers

  • Privilege Escalation: Attackers can modify GPOs to alter user rights or group memberships, granting themselves elevated privileges across the network.
  • Persistence and Lateral Movement: By using GPOs to deploy malware or tools, attackers can maintain persistent access to a system or facilitate lateral movement within a network.
  • Security Policy Modification: Attackers may tamper with GPOs to weaken security settings, such as disabling firewall rules, antivirus software, or other security controls, making systems more vulnerable to attack.
• Group Policy Objects (GPOs): Common Uses for Attackers

  • Reconnaissance: Attackers can embed scripts in GPOs to execute malicious activities, such as reconnaissance scripts that gather sensitive network information.
• User Artefacts in Group Policies

  When GPO policies are changed or exploited, specific artefacts are left behind that can help analysts detect unauthorized changes, evaluate the security state, and comprehend policy execution. Essential GPO enforcement artefacts include:

  • Custom User Settings: Direct modifications to user-specific settings, such as desktop configurations, startup programs, and security configurations, leave traces in HKEY_CURRENT_USER registry keys and within user profile directories.
• User Artefacts in Group Policies

  • Login Scripts: GPOs can dictate scripts to execute when a user logs in. These actions generate artefacts, including script files in the SYSVOL folder and execution logs within user profiles, found under the User Configuration settings of a GPO.
  • User Rights Assignments: Unauthorized alterations in user rights and permissions generate detectable changes within the Security database at %SystemRoot%\security\database\secedit.sdb, offering insights into access control adjustments.