We're in 2022, and the human factor is still found in 82% of breaches, according to the latest DBIR released in June.

Among the incident where humans play a substantial role, compromised credentials are the first. Employees still choose terrible passwords often found in compromised credentials lists. No matter how often we tell users not to use the same password for sensitive assets and services and external sites with weak security, they continue to do so.

I know, this isn't news. Compromised credentials or passwords have played an important part in data breaches for years.

Organizations are increasingly implementing security controls to prevent users from choosing bad passwords (including the previously compromised ones) at their creation. But this check is limited by essence. It first only represents a point in time, and secondly, it doesn't forbid the user to register an already chosen password, sometimes personal.

Beyond the initial need for a strong password, there are always potential events that can lead to the loss or theft of passwords or even credentials (i.e., the password and the identification). In this case, the password or the pair forming the credentials could appear on compromised lists days or months later, sold by hackers on the dark web, or released publicly.

Your organization needs to know that because the impact of a compromised password can be dramatic and is nothing compared to the potential impact of a compromised credentials pair.

But this is the first part. Even when you know that one or more credentials have been compromised, how should you react?

The first thing coming to mind is "disable the account altogether." Nowadays, disabling an account needs to consider that more and more users are working remotely., which complexities the process. You need a flexible response for today's workforce, and the SOAR comes to help all along the process like we've been talking about recently.

This is what we're going to see below:

• Why are your credentials so valuable

• The need for constant monitoring and SOAR's role in it

• Beyond monitoring, determining your incident response plan with the SOAR

Why attackers are targeting the acquisition of credentials

Passwords, especially passwords with privileged access to organizational systems and networks, are targets for hackers since they can get so much information from just one source.

Back in 2009, the Verizon Data Breach Report reported on this matter. Many intrusions reported already exploited the basic (mis)management of user identity. 

Unauthorized access via default, shared, or compromised credentials constituted more than a third of the Hacking category and over half of all compromised records! 

Besides the many breaches stemming from default and/or shared credentials, we need to understand why attackers target credentials. 

In short, legitimate and, most of all, legitimate and privileged credentials open are the sesame to your network. Should these keys be mismanaged because of an insufficient password policy, not enough awareness on the part of the employees, undefined privilege policy, for instance, an attacker could have the potential to access your most precious assets and use them for a malicious purpose (reselling, ransom, wiping).

Let's take the example of Basic Web Application Attacks (BWAA) via web servers. There are two entry points: the use of compromised credentials or the exploit of a vulnerability. Vulnerabilities like an RCE being somewhat rare (well, I said somewhat!), compromised credentials are sought after when accessing these internet-facing assets.

Indeed, over 80% of the breaches can be attributed to compromised credentials (stolen). A confirmation that compromised credentials are increasingly attractive to the attacker's eyes is the 30% increase in stolen credentials since 2017. For the past four years, it has been one of the most tried-and-true methods to gain access to an organization, and every sign points toward its continuation.

Paradoxically, compromised credentials aren't only used by criminals scanning and spraying the internet looking for weak credentials. APTs (Advanced Persistent Threats, states-backed actors) have also been leveraging this low-cost and high-payoff strategy. Over 20% of BWAA breaches are attributed to Espionage, which isn't what you might expect at first glance. 

When thinking about it, it's rather clever and logical. Why bother developing expensive techniques when there's a more effortless and cheaper way to do it.

Constant monitoring for compromised credentials

Considering what we've said above, detecting the use of compromised credentials is a top priority for any SecOps.

You should run checks against databases of compromised credentials or passwords. Securely checks against a proprietary database of compromised credentials or passwords and full credentials at both password reset and continuously after that. For this checking not to intrude on the user's time, it must be nearly instantaneous— measured in milliseconds rather than minutes.

Even in ordinary circumstances, the hash is regularly checked against newly compromised credentials or password lists. Because the password check isn't just a point in time, passwords can be identified as compromised long after they are set. Passwords are regularly audited against a continuously updated list of compromised passwords and full credentials.

A response plan should look to provide flexible features depending on a credential pair or only if a password is discovered as compromised. This is a risk-focused approach to both detection and remediation. Compromised credentials pairs (username and password combination) represent a higher risk than just a password.

Beyond monitoring: active and tailored remediation

When detecting a compromised credentials pair in your network, you need fast and flexible response options that teams of any size should appreciate. It means that you need speed, options, understandability, and accessibility. All of these elements are brought by next-generation SOARs via automation, orchestration, and no-code.

Disabling an account has always been a high-friction response action, but there's a substantial difference with remote workers. The remote worker is physically unable to walk to your desk to re-enable their account. The re-enablement process of an account remotely can open the doors to social engineering attacks which constitute a risk for SecOps.

To limit the use of this radical solution, any incident response plan should provide configurable delays and temporary containment measures to notify the end-user and advise them to take action with this delay. Should they fail to do so, radical action should be undertaken.

With this need for flexibility in mind, we're going to look up the typical incident response plan you can design and where the SOAR acts as its orchestrator and its automation between the different actions and steps prescribed.

Monitoring

Today, monitoring of passwords mainly operates in two ways. Most password manager services include breach watch services in their purchasing plans or as addons. 

These services perform periodic scans on the dark web or data breach reports for an element of the credentials pair. Some companies do this manually or go on well-known bases such as Haveibeenpwnd.

Once the enterprise identifies a compromised credentials pair, the incident response plan is set in motion.

Identification

As disposed of by many official frameworks, after the preparation phase and entering the proper response stance is the identification step.

Here you need to perform an investigation to determine the root cause of the incident. This step is crucial because it's going to impact subsequent ones. Subsequent steps won't be similar according to your root cause analysis results. This means:

• Identification of the incident (material, people-based?) by interrogating involved persons and identifying risky behavior that could have led to compromised credentials,

• Data collection (basically your enrichment phase where you harvest potential IOCs, email, IP, URL)

• Associating causal factors: putting all the pieces together to depict the scenario: action/lack of action, causality, incident

• Determine the criticality of the incident based on your findings: assets targeted, time to discover

Then you move on to the containment phase, according to the criticality of the incident exposed.

Containment

Containment is when your incident response team starts interacting with the infected system and keeps the damage from expanding among your network. 

Here, the confirmed incident contains various ways to limit its potential virality. There are multiple solutions to harness, such as account suspension and deprovisioning before enforcing a password reset.

Suppose malware has been detected in the prior stage. In that case, the containment step should look to isolate the infected system(s), preserve eventual samples for future forensics, and analyze discovered malware (by triggering it in a sandbox to monitor its behavior and record evidence).

Eradication (mitigation) and recovery

The eradication step is built on the process of understanding the cause of the incident. The goal is to reliably clean the system and restore it to operational status later with relative certainty (nothing worse than realizing that you weren't looking at the whole picture and have to go back at it).

Why? Because a common occurrence is to remove the most prominent piece of malware affecting the system and start the recovery process. This piece of malware may only be a symptom, and the cause may still be undiscovered, an emerged part of the iceberg, if you will. You thus have to look at additional IOCs, block them, and understand the complete picture, look at the whole iceberg.

Once the cause and symptoms are eradicated, the system needs to be restored to a clean state from scratch or a clean backup. As you know, certainty doesn't exist. Even if you're confident about your eradication process, you cannot do without the possibility of missing something that the infection or attacker might have persisted through the eradication step. Because of this, the initial scan restored machine and temporary monitoring of the system after it returns to production is an absolute necessity.

Finally, when it comes to compromised credentials, the process of enforcing the setting of a new password upon the next login. Again, this can be easily automated from your SOAR by pulling your IAM solution and sending the notification to the end-user on your communication channel.

Reporting

This step covers the whole process. Facing a compromised credentials incident, the reporting of its handling spans throughout the process, starting from the detection that happens in the Identification step.

Reporting fulfills two goals: information and legal. According to this, there are two areas of focus: technical and non-technical.

On the technical side, teams and agents in charge of the process must report the technical specifics of the incident as they start the handling process. This can be tedious and prone to errors. Automating the gathering of elements and their reporting in predetermined reports can save time and ensure proper standardization of incident reports.

The same goes for non-technical. Numerous stakeholders (business and mission owners, third parties) must be notified of severe incidents and kept updated as the process follows its course. Also, from a legal point of view, you want to leave no holes behind and do things by the book to avoid any sanctions. Here, tools that promote collaboration like SOAR can automatically notify appropriate agents, even outside the security scope, to ensure that everyone listed on the incident response plan is duly notified and working together towards its successful handling.

Lessons learned

Circle back to the root cause. How could the incident have been prevented? The goal is to provide a final report on the compromised credentials incident, which will be delivered to management and used to implement improvements.

I know this can't be done for each incident. But the fact is that compromised credentials are a significant incident since, as we said above, it opens the doors wide for the attackers into your network as legitimate users. Potential consequences are enormous; thus, should this incident occurs, this step should be mandatory.

It should include details about our company's shortcomings that led to the compromise of credentials (actions to be taken about software or hardware or people). Then, details about the possible caveats in initial detection and how we could have identified the compromised credentials sooner. And also how our response could have been quicker or more effective. Finally, general recommendations for improvements.

Conclusion

At every stage, whether you're talking about preparation, monitoring, or post-incident, from identification to mitigation and lessons learned, the SOAR benefits your compromised credentials handling processes, notably in their orchestration and automation.