Credential harvesting: Monitoring event 4673

The cybersecurity world is moving at a fast pace, with more sophisticated attacks getting executed lately. Irrespective of the type of attack, compromised user credentials have been a constant feature in most of the attacks. And, attackers use different techniques to steal these credentials and infiltrate an organization's network.
In this e-book, we talk about one such technique- credential harvesting. You will learn how a credential harvesting attack is executed and what you can do to prevent such attacks.

Credential harvesting

Credential harvesting primarily aims at stealing user credentials and then use the stolen credentials to launch attacks on enterprises. This technique involves usage of attack vectors such as Man-In-The-Middle (MITM), phishing, and more. Often phishing is considered as the only credential harvesting technique. Undoubtedbly, it's one of the most common techniques used to steal credentials, but it's not the only one. Depending on what credentials are being targeted and how the adversaries intend to steal the data, credential harvesting can take many form including hackers trying out thousands of username password combination within short span of time (credential stuffing), they relying on credentials available in the dark web, man-in-the-middle (MITM), social engineering, using malware or weaponized documents, and more. Once the credentials are harvested, attackers can use these to launch highly devastating attacks or breaches on enterprises.

How does credential harvesting occur?

The first step in this process of credential harvest is extracting user credentials. And this is where credential harvesting is often confused with phishing. Phishing is a technique used to steal credentials from unsuspecting users. Although, credential harvesting may involve phishing as a method to steal credentials, phishing is just one of the techniques used to accomplish the purpose. Other techniques include social engineering, weaponized documents, and sniffing network packets for sensitive information.

Attackers use a wide variety of tools and techniques to extract huge quantities of credentials from users. Once the credentials are stolen, attackers use these credentials to break into other enterprises, banking on the fact that some users might have used the same credentials across multiple websites.

Once the attacker has compromised the credentials of one user, the attacker can then enter the network using the stolen credentials and execute other ways such as the use of malicious software to harvest more credentials with higher privileges which will allow them to cause greater damage.

One such tool that is often used by attackers is Mimikatz.

Post exploitation tools: Mimikatz

Mimikatz is an open-source tool that can be used to harvest passwords, pins and kerberos tickets from Windows environments. This tool can also exploit elements of Windows authentication, if it is run with administrator privileges once installed on a system. Using Mimikatz an attacker can break into other domain accounts and escalate privileges.

Once an attacker has local admin privileges, Mimikatz needs be run with administrator privileges. Mimikatz can be used for:

  • Extracting Kerberos tickets
  • Executing Pass-the-hash
  • Extracting plain-text passwords

LSASS

Local Security Authority Subsystem Service (LSASS) is a security process in Microsoft Windows operating systems, that verifies user credentials during sign in and enforces security policies. When a user logs into their account, the system stores the credentials in the process memory.

Using credential dumping tools such as Mimikatz, an attacker can attempt to access the process memory to extract these users' plain-text passwords. This can be done by manipulating the Windows Security Support Provider (SSP) configuration. Windows SSP Dynamic-Link Library can be loaded into LSASS process during system boot. Once loaded into the LSA, SSP DLLs can be used to access encrypted and plain-text passwords stored in the Windows process memory.
When the attackers use Mimikatz to execute such critical events with restricted access, eventID4673 is triggered. This event relates to sensitive privileges.

Event ID 4673

Event ID4673 indicates that a privileged service was called. This might refer to a user exercising a right that is specified as a privilege. Privileges are granted to perform specific sensitive operations within the network to user accounts in a Windows environment. If audit policies relating to privileges are configured, the event ID 4673 is raised, whenever a user performs a privileged operation.
Listed below are few sensitive operations for which event ID 4673 is triggered.

  • Act as part of the operating system
  • Back up files and directories
  • Create a token object
  • Impersonate a client after authentication
  • Load and unload device drivers
  • Manage auditing and security log
  • Restore files and directories
  • Take ownership of files or other objects

The following table displays the information supplied when a privileged service is called and event 4673 is raised.

Event ID 4673
Category Privilege use
Description Privileged Service Called
Subject Security ID
Account Name
Account Domain
Logon ID
Service Server Name
Service Name
Process Process ID
Process Name
Service Request Information Privileges

During a credential harvesting attack, the event 4673 is raised when Mimikatz is executed and the process tries to access the SeTcb Privilege, which refers to a process trying to act as part of the system.

Further, if Mimikatz is used for manipulating the LSASS process to inject a skeleton key remotely, all the domain controllers in the network, accept the skeleton key's master password as a user's valid credentials. When this occurs, another event 4673 is raised.

If you happen to see the event 4673, you need to know that a sensitive service was being executed by a user with high privileges. This can sometimes turn out to be an administrator backing up the files present in the server, or an Indicator-of-Compromise (IoC). Hence, event 4673 can potentially make-or-break your enterprise, depending on whether you have proper systems in place. A centralized log management system that can collect logs from every device in your network and alert you about malicious activities can help you monitor such events and mitigate threats at the earliest.

Best practices to prevent credential harvesting attacks

Employee awareness and training:

Since a major step in credential harvesting involves replaying stolen credentials from other websites into your enterprise, users must be made aware of the importance of adhering to password best practices such as.

  • Avoiding password reuse
  • Avoiding commonly used passwords
Cautious online habits:

Employees can be trained to identify phishing emails and refrain from opening links and attachments from unknown sources. They can also be trained to spot fraudulent login pages and report such incidents immediately to competent authority.

Enforcing Multi-Factor Authentication(MFA):

Regardless of the method used to compromise credentials from users, MFA can ensure that the compromised credentials aren't of much use since they do not have access to the second factor to authenticate a user.

Monitoring logs:

Collecting and constantly monitoring logs from network devices such as firewalls, databases, endpoint solutions, domain controllers, and more. Also proactively look for security events such as 4673, to look for similar Indicators-of-Compromise.

Deploy a SIEM solution:

A properly configured Security Information and Event Management (SIEM) solution can help you detect suspicious user activity and provide you with actionable insights on the specifics of the events happening in your network.

Tools such as Mimkatz can be used to cause a lot of damage to your network environment. However, since several processes are executed, it becomes hard to hide the traces. Even if Mimikatz is used to disable event log tracing, and uses tools to clean the event log traces, the use of tools themselves will also leave their own traces.
Hence, it can be seen that if appropriate audit policies are enabled and a centralized logging system such as a SIEM solution is used, you can ensure that malicious activities in your network are detected immediately, enabling you to take necessary remedial measures.

Log360 is a robust SIEM solution that centrally collects and manages all your network logs to provide you with actionable insights and help you devise a proper incident response strategy.

 

Golden Ticket and Silver Ticket attacks explained

Unlike pass-the-hash and pass-the-ticket techniques, which involve stolen credentials, Golden Ticket and Silver Ticket attacks involve forgery of tickets to gain legitimate access to a network. These incursions can have devastating long-term consequences. Since these are post-exploitation attacks, you can protect your network by observing the recommended practices to prevent infiltration. Steps should be taken to educate your employees, enforce the principle of least privilege, and install endpoint protection software. While it's essential to take preventative measures, you also need to know how to detect them.

Golden Ticket attacks

What is a Golden Ticket attack?

A Golden Ticket attack is a technique used to take control of the Active Directory Key Distribution Service Account (KRBTGT) and issue ticket-granting tickets (TGTs) for any resource or service in the domain. The golden ticket itself is the Kerberos authentication token for the KRBTGT account, which is a hidden account that encrypts all the authentication tokens for the domain controller (DC). Attackers with control over the KRBTGT account via the golden ticket have unchecked access to all domain resources and might remain inconspicuous for a long time.

How is a golden ticket forged?

After gaining the initial foothold, the attacker performs reconnaissance to gather necessary domain information and locate a DC. This is followed by the acquisition of local-administrator-level access to the DC. The KRBTGT password hash is then harvested from the DC using tools such as Mimikatz or techniques such as pass-the-hash and DCSync. With access to the DC and the KRBTGT password hash, the attacker can obtain a Kerberos TGT for a validity period of their choosing. This gives them network access for an indefinite period.

Telltale signs of a Golden Ticket attack

Golden Ticket attacks are notoriously difficult to detect since the attacker has already infiltrated the network and obtained legitimate access. However, there are a few telltale signs that can help you identify a Golden Ticket attack.

  • Higher life span of tickets The default life span of tickets in Active Directory is usually 10 hours. When tools such as Mimikatz are used, the life span may be set up to 10 years.
  • Domain-field irregularities Tickets forged by attackers typically do not have properly populated domain fields. For example, the domain field may be left blank, could be filled with a random value, or could be populated with a fully qualified domain name instead. These irregularities can be observed in Windows security event logs.
  • Weak encryption Another sign of this attack is when the service tickets are encrypted with weaker ciphers, such as Rivest Cipher 4 (RC4) or Data Encryption Standard, rather than the more secure Advanced Encryption Standard. These ciphers can be detected when the Ticket Encryption Type field is anything other than “0x11” or “0x12”. This can be found in Event ID 4769 and is indicative of both Golden Ticket and Silver Ticket attacks.

Detecting a Golden Ticket attack

First, you should be parsing and collecting critical logs from servers, VPNs, firewalls, IDPSs, and workstations. And remember, a Golden Ticket attack is a post-exploitation attack. Security admins should always watch out for suspicious user activity and software installations, application misconfigurations, and other vulnerabilities so these do not become an entry point in a Golden Ticket attack.

To spot the telltale signs of a Golden Ticket attack, here are a few useful event IDs:

Event ID 4768 A Kerberos authentication ticket was requested.
Event ID 4769 A Kerberos service ticket was requested.

Event ID 4769 logs are generated when a TGT is used to request a ticket-granting service (TGS). It records crucial information such as the account name that requested the service, corresponding domain name, SID, service name, client address, and ticket encryption type. Log360 provides a comprehensive threat database of malicious IP addresses with their reputation score, and an advanced threat analytics module that detects communication with any of these URLs. The database is preconfigured and auto-updated, enabling you to detect the first sign of an intrusion and preventing the attacker from gaining a foothold in your network.

Anomalies in any of these fields are indicative of suspicious activity and should be investigated. Event ID 4768 is generated when a TGT is requested. A missing Event ID 4768 before a service ticket request indicates the presence of a golden ticket. There are other important event IDs, such as Event ID 4627 (that indicates an account was successfully logged on) to identify group membership, and Event ID 4624 to identify the computer IP address. These are useful when conducting further investigations.

Silver Ticket attacks

What is a Silver Ticket attack?

A Silver Ticket attack is a technique used to forge a Kerberos TGS ticket and obtain access to a service on an application. The scope of a silver ticket is limited to only the compromised service, unlike the golden ticket which gives power over an entire domain.

How is a silver ticket forged?

To forge a service ticket, the attacker needs to compromise the service account. By harvesting credentials from the computer's Security Account Manager, they obtain the service account password hash. This can be used to forge tickets by deploying tools such as Mimikatz. The attacker obtains direct access to the service without contacting the DC.

Detecting a Silver Ticket attack

Silver tickets are generated on the compromised hosts without any communication with the DC, so spotting them can be tricky. However, you can begin by collecting logs from all workstations.

A TGS event is logged as Event ID 4769. These logs should be monitored for anomalies, such as new user names, RC4 encryption, blank fields, and the number of times they are generated. Too many accesses from the same account indicate a possible attack.

Additionally, watch out for blank fields in Windows logon and logoff events, such as Event IDs 4624, 4634, and 4672. All these signal the presence of suspicious actors in your network.

Detecting Golden Ticket and Silver Ticket attacks with Log360

Log360, ManageEngine's comprehensive SIEM solution, can help you spot indicators of Golden Ticket and Silver Ticket attacks.

Intrusion detection

Both are post-exploitation attacks, which means the attacker has to establish a base in the network first. Log360 reduces the time taken to detect compromises by detecting the initial signs of an attack.

Extensive firewall and IDS/IPS auditing:

Log360 audits firewall logs, including changes in firewall policies and firewall management, and logs from IDPSs. It can alert you about these events through email and SMS notifications. Log360 successfully detects any intruders and helps you identify potential sources of account compromise.

Preconfigured, auto-updated threat database:

Log360 provides a comprehensive threat database of malicious IP addresses with their reputation score, and an advanced threat analytics module that detects communication with any of these URLs. The database is preconfigured and auto-updated, enabling you to detect the first sign of an intrusion and preventing the attacker from gaining a foothold in your network.

User and entity behavior analytics (UEBA):

Log360's UEBA module detects account compromise by observing and identifying unusual user behavior on the network. By watching for signs including odd logon times, unusual file access, and connection from a remote system, UEBA flags any uncharacteristic user action as "risky." When a user's risk score exceeds a designated threshold, the security admin is alerted and can investigate further to determine if the user's account is compromised.

Investigation of critical events

Log360 features a powerful search engine that can perform high-speed searches across the length and breadth of your network. The search console provides an advanced point-and-click query building option that enables you to create queries quickly.

The search engine is optimized for simple searches, such as event ID or phrases from the log, or complex queries built using boolean, comparison, and wild-card operators.
To detect indicators of Golden Ticket and Silver Ticket attacks, you can look for Event ID 4768, 4769, and 4770. Log360 lets you add these searches as alerts so that similar sequences are automatically spotted and the security admin is proactively notified.

 

Credential stealing: Pass-the-hash and pass-the-ticket

Nearly all damaging cyberattacks involve privileged account compromise. While brute-forcing a privileged account password takes time, credential stealing techniques are simple and less time-consuming. Pass-the-hash (PtH) and pass-the-ticket (PtT) are two such techniques that circumvent the use of passwords for authentication. Once attackers gain a foothold in an organization's network, they move laterally using these techniques, eventually compromising privileged accounts.

Pass-the-hash

What is the pass-the-hash technique?

In this technique, the attacker captures a password hash and uses it to authenticate as the user, bypassing the need for the account password. As long as the password is unchanged, the attacker has access to the system. Pass-the-hash attacks can occur on Linux, Unix, and other platforms, but they are most prevalent on Windows systems.

How do attackers obtain password hashes?

In Windows, hashed passwords can be found in the Security Accounts Manager, Local Security Authority Subsystem process memory, and the Credential Manager store, which is an ntds.dit database in Active Directory. Hackers use hash dumping tools such as fgdump and pwdump to obtain hashes from any of these places. Using the harvested user account and password hashes, they then move laterally to all possible systems and resources with the goal of hacking into privileged user accounts

Detecting pass-the-hash attacks

Pass-the-hash attacks can be detected by constantly monitoring all logon and credential use events. For Windows, certain event log patterns can reveal the use of this technique.

For example, NTLM Logon Type 3 authentications that are not associated to a domain login and are not anonymous logins are indicators of non-authenticated logins. These events are followed by event IDs 4768 and 4769, which are generated when a user requests a new ticket granting ticket and service ticket, respectively.

Watch this video to see how Log360 detects PtH attacks.

Pass-the-ticket

What is the pass-the-ticket technique?

In the pass-the-ticket technique, the attacker steals an authenticated user's valid Kerberos tickets and passes them between systems to gain legitimate access to resources. Depending on the level of access in a system, the attacker steals the user’s service tickets or ticket granting ticket (TGT). While the TGT can be used to get the required service tickets from the ticket granting server, the service tickets are used to access a specific service in the domain. This attacker's activity can last as long as the ticket is valid—usually for 10 hours.

How is a pass-the-ticket attack carried out?

A pass-the-ticket attack is also a post-exploitation attack, which means an attacker has already compromised a system. They then try to elevate privileges to gain access to cached memory. With elevated privileges, they can extract tickets using a variety of techniques. A notable technique is using tools such as Mimikatz and Rubeus to harvest and pass the tickets to request Kerberos service tickets or gain illegal access to a service elsewhere in the network. The MITRE ATT&CK framework lists additional techniques by which passing the ticket attacks take place.

Detecting pass-the-ticket attacks

Pass-the-ticket attacks can be detected by carefully monitoring logon, credential use, and remote authentication events. Unusual remote logins that correlate with other suspicious activity, such as writing and executing binaries, may also indicate malicious activity. One pattern of pass-the-ticket attacks is when event ID 4768 or 4769, followed by event ID 4770, is logged on the domain controller.

  • Event ID 4768: This event generates every time the Key Distribution Center issues a Kerberos TGT.
  • Event ID 4769: This event generates every time the Key Distribution Center gets a Kerberos ticket granting service (TGS) ticket request.
  • Event ID 4770: This event generates for every TGS ticket renewal.

Mitigating pass-the-hash and pass-the-ticket attacks

Change passwords periodically:

Password hashes are valid only until the passwords are changed. Periodic password changes render the previous hashes invalid and are one way to cut off hacker's access.

Implement multi-factor authentication:

Pass-the-hash attacks typically exploit single sign-on authentication in Windows, so multi-factor authentication is a good measure to nip these attacks in the bud.

Follow the principle of least privilege (POLP):

Lateral movement can be greatly restricted if the POLP is put into practice. Practices such as separating the domain admin and standard accounts for day-to-day work, restricting server and workstation logon access, and enforcing local account restrictions for remote access can go a long way.

Restrict inbound traffic using a firewall:

This is a simple and robust mitigation technique that greatly reduces the attack surface of your organization. By restricting traffic in your network, the chance of captured hashes or tickets being used is highly reduced.

Detecting and mitigating pass-the-hash and pass-the-ticket attacks with Log360

Detecting PtH and PtT attacks is easier with security information and event management solutions such as ManageEngine Log360. Here's how Log360 detects these attacks in your network.

Intrusion detection through extensive firewall and IDS/IPS auditing

Log360 extensively audits firewall logs including changes in firewall policies, firewall management, and logs from intrusion detection and prevention systems (IDPS). It even offers email and SMS notifications to alert you about these events to help successfully detect any intruders and identify potential sources of account compromise.

Block malicious connections with a preconfigured threat database

Log360 comes preconfigured with an auto-updated threat database of malicious IP addresses along with reputation scores and an advanced threat analytics module that detects communication with any of these URLs. By detecting the first sign of intrusion, Log360 prevents the attacker from gaining any sort of foothold in your network.

Detect lsass.exe access through file integrity monitoring

Log360's file integrity monitoring system monitors all accesses, modifications, create, and delete actions on all critical and non-critical files and folders across your network. It also lets you set up alerts to detect critical file accesses or modifications, such as lsass.exe, in real time.

Investigate critical events with forensic analytics

Log360 has a powerful search engine that can perform high-speed searches across the length and breadth of your network. This helps you quickly look for critical events such as event IDs 4768, 4769, and 4770, and sequence events together during investigation. You can even save the searches or add them to alerts so similar sequences are spotted quickly in the future.

Discover complex attack patterns in time with the correlation engine

Log360 has a powerful correlation engine that can link specific events when they occur one after the other. By leveraging the custom correlation rule builder, you can set up a rule to detect log patterns such as event ID 4768 or 4769 followed by event ID 4770, which is an indicator of a pass-the-ticket attack. If detected, Log360 notifies you by email or SMS in real time.

source
 

Attack detection and mitigation: Kerberoasting

What is Kerberoasting?

Kerberoasting, one of the most common attacks against domain controllers (DCs), is used by adversaries to steal credentials and move laterally within the network. Since Kerberoasting doesn't exploit any security loopholes, detecting this attack is difficult.

Kerberos, the default protocol used by the Active Directory (AD), allows users to access services on the network by using tickets instead of passwords. The tickets are generated for every session and are used for a specific, short period. Users can access remote services by requesting a service ticket from the DC. The ticket requests include unique identifiers called the service principal names (SPNs). To use Kerberos authentication in your environment, the SPNs should be registered in AD with at least one service logon account, which is an account that is dedicated to running the service. A valid domain user is allowed to request a ticket-granting service (TGS) ticket for any SPN, and parts of the TGS may be encrypted with the Rivest Cipher 4 (RC4) encryption algorithm using the password hash of the service account assigned to the requested SPN as the key.

Kerberoasting abuses the workings of the Kerberos protocol. Threat actors need only obtain a valid domain user account—not a local admin account or an account having privileged permissions—to monitor SPN accounts and associated tickets.

These tickets can then be cracked offline to obtain the password hashes. Let's take a deeper look at how this attack is being executed.

How is a Kerberoasting attack carried out?

Attack stages

Listing SPNs of AD service accounts

Scanning the network for the service accounts and then detecting the required service account is the first step. Then, the adversary acquires the SPN of the required service account using different techniques, like SPN scanning or LDAP querying.

Requesting TGS tickets

The attacker then requests TGS tickets to the domain controller for the extracted SPNs. The TGS validates the use of a ticket for a specific purpose.

Extracting hashes from the memory

The AD domain controller would respond by sending a ticket for the requested service. TGS tickets are often encrypted with NT hashes. So adversaries dump the New Technology Local Area Network Manager (NTLM) hashes from memory using tools such as mimikatz and PWDump X, and the ticket is used to crack the plain text password.

Decrypting the hashes

Upon obtaining the hash, the attacker uses brute-force techniques to retrieve clear text passwords. Attackers usually carry out this process outside the victim's environment. This allows them to use powerful graphics processing units (GPU) to reduce the decryption time and eliminates the possibility of documenting failed logon events since the hashes are decrypted offline.

Lateral movement

Once the attacker has obtained the required password, they can move laterally across the network and gain access to sensitive data.

Detection and mitigation

Detecting Kerberos is one of the most difficult tasks since the attack doesn't violate any rules. It just exploits the operation of Kerberos authentication method. Moreover, among the numerous legitimate Kerberos requests, identifying an anomalous one is tough. The user SPNs can be easily retrieved and cracked offline. There wouldn't be any trace as the password hashes are cracked offline. As a result, account lockouts don't take place.
It's difficult to detect this attack, but it's not impossible. Security analysts can use signature-based detection techniques and behavioral analytics to spot and thwart a Kerberoasting attack.

It is also highly recommended that you use strong encryption algorithms for service accounts, such as AES-128 and AES-256. Changing the passwords of service accounts frequently can also help secure the accounts from being compromised.

Using signature-based techniques

To detect a Kerberoasting attack, look out for these indicators or events :

Monitoring user accounts with suspicious TGS request activities:

In the initial stages of a Kerberoasting attack, a hacker raises several TGS requests (event id=4769) from a single user account to obtain access to the network. It is important to monitor accounts that generate several requests in a short span of time.

Several failed logon attempts from a single user account:

Failed logons are common. However, when there are several failed logon attempts followed by a successful logon, it could be a sign of an attacker trying to compromise an account. Account activities should always be monitored closely.

Suspicious account changes for a source user:

Once an attacker gains access, they usually make critical account changes. This can be done either to draw the attention of the system administrator or to facilitate lateral movement across the network.

The accuracy of signature-based techniques are minimal and can lead to false positives. However, you can deploy a security information and event management (SIEM) tool that uses machine learning (ML) to learn attack patterns and help defend against known attacks.

Using a SIEM solution, you can filter out events with ID 4769, which is typically generated every time the Key Distribution Center (KDC) receives a Kerberos TGS ticket request. However, 4769 events are one of the most logged events in the DC. Therefore, it is advisable to use this filter during Windows Management Instrumentation fetches.

Using the powerful search engine, you can also filter out tickets with encryption type 0x17 and ticket with options and failure codes as 0x40810000 and 0x0 respectively.

You can also filter out requests from service accounts. Kerberoasting attacks are usually initiated from the service accounts. You can also filter out requests for service names with a “$” which typically indicates computer accounts.

By restricting domain accounts from being used as service accounts, attackers can be restricted from moving laterally across the network.

How Log360 helps defend against attacks

ManageEngine Log360, a powerful SIEM resource, accomplishes this by identifying signatures associated with an attack and using its correlation feature to interrelate the events and identify the patterns.

The UEBA capability of the solution can detect threats based on the behavior of users. The solution uses ML and artificial intelligence (AI) to understand and learn behavior patterns and to develop a baseline for each user, all from a single console. It then assigns risk score to users whenever there are deviations in the user behavior. You can identify malicious users based on their risk score.

With its ready-to-audit reports, you can gain in-depth insights on all your network activities. This helps you identify and mitigate threats at the earliest.

Log360 is a comprehensive SIEM solution that proactively combats internal and external security attacks with effective log management and in-depth AD auditing.

 

Attack detection and mitigation: Credential dumping

Most users will have trouble remembering their credentials. The easiest way to overcome this is to allow browsers and applications to remember their passwords. Do you know that these stored credentials can easily be stolen by adversaries using various attacking techniques—and, with the right resources, these malicious actors can easily be thwarted as well?

This webpage elaborates on the attack technique credential dumping that involves obtaining user credentials (username and password), and determining where it is stored in the form of either hash or clear text. The stolen credentials enable malicious actors to move laterally in the network to access restricted information, poach business-critical resources, or install malware.

How do they do it? There are different strategies, but one way is to lure administrators to login to a compromised machine and dump their credentials from the cache memory.

This isn't the only way. As attack techniques get more sophisticated, adversaries automate the process of dumping credentials by using different tools, such as mimikatz. Dumped manually or using tools, hackers must access the folder or database where the credentials are stored.

Locations that store password hashes

Security Accounts Manager (SAM)

In Windows, the local account credentials are stored in the SAM database and are used to authenticate local and remote users. SAM is part of the registry and can be found on the hard disk of a system. The user must have system-level access to enumerate the SAM database. The file can be retrieved through in-memory execution tools such as:

  • mimikatz
  • gsecdump
  • pwdumpx.exe
  • secretsdump.py

Once the adversaries acquire system privilege they can dump all the credentials from the SAM database of a compromised machine by executing the commands below:

  • reg save HKLM\sam sam
  • reg save HKLM\system system
LSA secrets

The Local Security Authority (LSA) manages authentication details of users on a Windows system. It also manages the local security policy for a computer and the data that this subsystem uses is stored in a protected area called LSA secrets. From LSA secrets, attackers can dump sensitive data, such as cached domain password, encryption key, SQL passwords, system account passwords, account passwords for scheduled tasks, and details about un-activated copies of Windows.

WDigest

The WDigest is an authentication protocol that works on a challenge and response method for LDAP and web-based authentication. This uses hypertext transfer protocol (HTTP) and simple security authentication security layer (SASL) protocols for authentication exchanges. The client requests the authenticating server to grant access to a resource or process. The authenticating server then challenges the client, and the client responds to the challenge by encrypting its response with a key derived from the password. This encrypted key is compared against the stored response on the authenticating server to validate the user password. This WDigest stores credentials as plain text (in Windows versions up to 8 and Windows Server 2012) or stores secrets as plain text. Adversaries can exploit WDigest to dump these credentials and secrets.

Proc filesystem

In Unix-like operating systems, the proc filesystem stores useful information about the processes that are currently running and acts as a control and information center for the kernel. An attacker can run a process with root privileges to scrap live memory from other applications and any credentials stored as hashes or plain texts can be extracted.

Further, if the attacker manages to gain access to the domain controller, they can retrieve credentials from additional repositories, such as NTDS and DCSync.

Best practices to spot and stop credential-dumping techniques

  • Monitor who is accessing the local security authority subsystem service (LSASS) and security account manager (SAM) databases.
  • Disable or restrict the New Technology Local Area Network Manager (NTLM) so that adversaries don't have access to NTLM hashes.
  • Monitor the logs for unauthorized activities on a domain controller.
  • Watch out for events that provide information about the execution of commands and that dump credentials to a file or external resource.
  • Do not blend the admin domain accounts with the local administrator groups.

Using Log360 to detect and mitigate credential dumping

ManageEngine Log360, a comprehensive SIEM solution, offers various resources to spot and stop credential-dumping attack techniques. This includes:

  • Security analytics and a real-time alerting console that implements the MITRE ATT&CK framework
  • Signature-based credential-dumping detection using real-time correlation techniques
  • Machine learning (ML)-driven user and entity behavior analytics (UEBA) module

Security analytics implementing the MITRE ATT&CK framework for detecting credential dumping

Credential dumping is listed as one of the techniques (ID: T1003) under Credential Access tactic in the MITRE ATT&CK framework. Log360 implements this framework using its real-time event response console and security analytics module. The solution can alert security analytics in real-time whenever there's an attempt to dump credentials from SAM registry, syskey registry, remote services, and more.

Further, the solution gives better insights into credential-dumping activities by providing real-time security analytics widgets for:

Credential Access attacks

  • Network sniffing
  • Brute-force attacks
  • Man-in-the middle
  • Unsecured credentials
  • OS credential-dumping

Signature-based credential-dumping detection using real-time correlation engine

Let's now discuss how Log360 provides visibility into an attempted credential-dumping attack using its powerful Correlation feature.

Log360 provides a list of events you can select to indicate the possible result from an attack. For instance, one way to carry out a credential-dumping attack is using a tool such as mimikatz.

You can create a custom correlation to identify password harvesting tools and removable media, as well as events such as suspicious deployment of executable files, and remote access. You can then check for suspicious activities around Administrative profiles to identify unauthorized changes. You can configure alerts based on activities so you can detect threats proactively.

ML-based UEBA module to spot credential dumping

When the attacker leaves no trace, such as from dumping the credentials and cracking it offline, signature-based attack detection is not the best defense to use to stop them. In such cases, behavioral analytics comes handy to spot and immediately stop the hackers before the actual damage is done.
Log360's ML-driven UEBA module spots suspicious and unusual user behaviors in real time. To spot the malicious behaviors accurately, this module is tied to the integrated risk management system that validates every anomaly and associates a risk score with it. With this, detecting the lateral movement of adversaries from legit activities becomes easier.

How Log360's UEBA can detect credential dumping:

Log360 helps you monitor user behavior and identify anomalies. For instance, after an attacker succeeds in extracting the credentials, they can use it to move laterally across the network and access files or folders. However, Log360 understands user behavior and identifies anomalies based on the deviations from the preset baselines.

If an attacker tries to access certain files or folders from a particular department using the credentials of an administrative account of a different department, Log360 recognizes this and lets your administrator know that this particular event could be a potential attack. You can then use the solution's powerful search engine to drill down into incidents and identify the impact of the attack.

Mitigating credential-dumping attacks using Log360's incident management system

With Log360's UEBA capability, the solution can identify malicious user activities that can be associated with credential-dumping events.

Say a user logs in at an unusually wee hour after multiple failed attempts. The user then accesses files from a different department, copying certain files to a different folder. This could be a potential threat actor who has gained access to a user account. Log360 monitors the user's activities and alerts IT administrators who can then investigate the incident. The solution enables users to design a custom workflow to mitigate such incidents by halting the processes or logging out the user from the network.

ManageEngine Log360 is the comprehensive SIEM solution that enables you to combat or proactively mitigate internal and external security attacks by providing out-of-the box reports and real-time alerts for incidents and events that happen in your network.

 

Credential harvesting: Monitoring event 4673

The cybersecurity world is moving at a fast pace, with more sophisticated attacks being executed recently. Irrespective of the type of attack, compromised user credentials have been a constant feature in most of the attacks. According to Verizon's 2021 Data breach investigations report, 61% of all breaches involve stolen credentials.

Attackers use different techniques to steal these credentials and infiltrate an organization's network. In this e-book, we talk about one technique, credential harvesting. You will learn how a credential harvesting attack is executed and what you can do to prevent it.

Credential harvesting

Credential harvesting focuses on stealing user credentials and then using them to launch attacks on an organization. This technique involves using attack vectors such as man in the middle (MitM), phishing, and more.

Considered by some to be the only credential harvesting technique, it's undoubtedly one of the most common techniques used to steal credentials, but it's not the only one. Depending on what credentials are being targeted and how the adversaries intend to steal the data, credential harvesting can take many forms, including hackers trying out thousands of username-password combinations within a short span of time (credential stuffing), exploiting credentials obtained from the dark web, MitM, social engineering, and using malware or weaponized documents. Once credentials are harvested, attackers can use them to launch highly devastating attacks or breaches.

How does credential harvesting occur?

The attackers employ a wide variety of tools and techniques to extract large quantities of user credentials. These stolen credentials can be used to crack other applications, banking on the tendency of many users to recycle passwords across multiple websites.

Credentials can be harvested in multiple ways, such as password filtering, dynamic link library (DLL) attacks, and exploiting privileged services. The latter can be executed using tools like Mimikatz. Such privileged service-based attacks can be detected by monitoring event ID 4673.

Credential harvesting tools: Mimikatz

Mimikatz is an open-source tool that can be used to harvest passwords, pins, and Kerberos tickets from Windows environments. Once installed on a system, this tool can also exploit elements of Windows authentication if it is run with administrator privileges. Using Mimikatz, an attacker can break into other domain accounts and escalate privileges.

Once an attacker has obtained local admin privileges and Mimikatz is run with them, it can be used for:

  • Extracting Kerberos tickets
  • Executing pass-the-hash attacks
  • Extracting plain-text passwords

LSASS

Local Security Authority Subsystem Service (LSASS) is a security process in the Microsoft Windows operating systems that verifies user credentials during sign in and enforces security policies. When a user logs into their account, the system stores the credentials in the process memory.

Using credential dumping tools, such as Mimikatz, an attacker can attempt to access the process memory to extract these users' passwords. This can be done by manipulating the Credential Windows Security Support Provider, or Cred SSP, configuration. The Windows SSP DLL can be loaded into the LSASS process during a system boot. Once loaded into the Local Security Authority, SSP DLLs can be used to access encrypted and plain-text passwords stored in the Windows process memory. When the attackers use Mimikatz to execute such critical events with restricted access, event ID 4673 is triggered. This event relates to sensitive privileges.

Event ID 4673

Event ID 4673 indicates that a privileged service was called. This might refer to a user exercising a right that is specified as a privilege. Privileges are granted to perform specific sensitive operations within the network to user accounts in a Windows environment. If audit policies relating to privileges are configured, the event ID 4673 is raised whenever a user performs a privileged operation.

Listed below are few sensitive operations that triggers an event ID 4673.

  • Serve as part of the operating system
  • Back up files and directories
  • Create a token object
  • Impersonate a client after authentication
  • Load and unload device drivers
  • Manage auditing and security log
  • Restore files and directories
  • Take ownership of files or other objects

The following table displays the information supplied when a privileged service is called and an event 4673 is raised.

Event ID 4673
Category Privileged service called
Subject
  • Security ID
  • Account Name
  • Account Domain
  • Logon ID
Service
  • Server Name
  • Service Name
Process
  • Process ID
  • Process Name
Service request information Privileges

During a credential harvesting attack, the event 4673 is raised when Mimikatz is executed and the process tries to access the SeTcb Privilege, which refers to a process trying to act as part of the system.

Further, if Mimikatz is used for manipulating the LSASS process to inject a skeleton key remotely, all the domain controllers in the network accept the skeleton key's master password as a user's valid credentials. When this occurs, another event 4673 is raised.

If you see an event 4673, you know that a sensitive service was executed by a user with high privileges. This can turn out to be an administrator backing up the files present in the server, or an indicator of compromise (IoC). Event 4673 can potentially make or break your organization, depending on whether you have proper systems in place. A centralized log management system that can collect logs from every device in your network and alert you about malicious activities can help you monitor suspicious events and mitigate threats before they cause significant harm.

Best practices to prevent credential harvesting attacks

User awareness and training: Create awareness about the importance of adhering to password best practices such as:

  • Avoiding password reuse
  • Avoiding commonly used passwords

Cautious online habits: Train users to identify phishing emails and refrain from opening links and attachments from unknown sources. Instruct them to report such incidences immediately.

Enforcing multi-factor authentication (MFA): Enforce MFA to ensure that the stolen credentials aren't of much use to attackers since it blocks access to the second factor to authenticate the users.

Monitoring logs: Collect and monitor logs from network devices such as firewalls, databases, endpoint solutions, and domain controllers. Also, proactively look for security instances, such as an event 4673, to spot similar IoCs.

Deploy a SIEM solution: A properly configured security information and event management (SIEM) solution can help you detect suspicious user activity and provide you with actionable insights.

Tools such as Mimikatz can be used to cause a lot of damage to your network environment. However, since several processes are executed, it becomes hard to hide the traces. Even if Mimikatz is used to disable event log tracing and uses tools to clean the event log traces, the use of tools themselves will leave their own traces. If appropriate audit policies are enabled and a centralized logging system, such as a SIEM solution is used, you can ensure that malicious activities in your network are detected, enabling you to take necessary remedial measures immediately.

Log360: A powerful SIEM solution

Log360 is an integrated log management solution that helps organizations overcome security challenges and ensures detection and mitigation of threats. It allows you to track Active Directory changes, firewall configurations, network device logs, Microsoft Exchange Server, and Azure AD, all from a single console.

How Log360 can help you mitigate credential harvesting attacks

Since event ID 4673 is an important indicator of a credential harvesting attack being executed against your organization, monitoring this event ID can help you detect the attack in its early stages and take necessary remediation measures.

  • Using Log360, you can generate custom reports based on criteria specified by you. Log360 also enables you to add multiple criteria and perform AND and OR operations between them.

This will track the event and generate a report when such an event is detected.

  • A report of this kind will help you quickly identify critical information regarding a privileged service being called. You can also view the report in the form of graphs, and charts as shown below.
  • You can also configure alerts for specific events, to ensure that you are informed whenever Log360 encounters the event.
  • Using Log360's advanced correlation engine, you can configure correlation rules to detect and identify seemingly unrelated events and notice attack patterns.

For example, a user logs in successfully into the organization's VPN network, after several unsuccessful attempts, and this is followed by the elevation of privileges associated with that user. The same user account then attempts to install a service, such as Mimikatz. All these events in isolation wouldn't mean much. However, when viewed together, this might indicate an attack is being executed.

With Log360's log correlation feature you can:

  • Edit existing correlation rules to fine-tune your alerts. If you notice a specific rule is generating too many false positives or fails to identify an attack, you can easily adjust the rule definition as needed.
  • Add a name, category, and description for each rule.
  • Drag and drop rules to rearrange which actions comprise a pattern, and in what order.
  • Restrict certain log field values with filters.
  • Specify threshold values for triggering alerts, like how many times an event has to occur or the time frame between events.

In addition, Log360 utilizes user and entity behavior analytics (UEBA) that leverage machine learning techniques to safeguard your network. With Log360's UEBA module, you can:

  • Map usage patterns of different users and establish a baseline.
  • Detect any deviation from regular usage patterns and raise an alert immediately. For example, if UEBA detects multiple unsuccessful logins attempts, followed by a successful login, this might indicate an attacker trying to brute-force their way into the network, with the idea of escalating privileges to eventually execute applications such as Mimikatz to cause greater damage to the organization.
  • Calculate risk scores based on the set patterns, and take necessary action.

Using a combination of the reports, alerts, correlation features, and UEBA, Log360 ensures that you are always prepared in case of a credential harvesting attack in your organization.

Detect and mitigate threats with ease. Explore Log360's free and fully-functional 30-day trial now. Or, schedule with our solution experts a free personalized demo to discover more about Log360's security features.

 
Welcome back  
 
×