Introduction
Organizations often rely on a layered defense strategy, yet breaches still occur, slipping past multiple levels of protection unnoticed. This is where compromise assessment enters the game. The primary objective of these services is risk reduction. They help discover active cyberattacks as well as unnoticed sophisticated attacks that occurred in the past by doing the following:
- Tool-assisted scanning of all endpoints;
- Host and network equipment log analysis;
- Threat intelligence analysis, including darknet search;
- Initial incident response to contain discovered threats.
In this article, we delve into the root causes of real-world cases from our practice, where despite having numerous security controls in place, the organizations still found themselves compromised. In all the cases in question, compromise assessment was the last line of defense that successfully detected incidents.
Patch management issues
The vulnerability patching process typically takes time for a variety of reasons: from actual patch release all the way to identifying vulnerable assets and “properly” patching them, considering any pre-existing asset inventory and whether the accountable personnel will learn about the vulnerability in time. There are multiple factors that may delay this process, including formality in business continuity requirements, e.g. inability to reboot the server without a downtime window.
That’s why insufficient patch management processes on the customer side are one of the most common root causes of incidents we observe in compromise assessment projects. Moreover, exploitation of a public-facing application was the root cause in 42.37% of cases investigated by the Kaspersky Global Emergency Response Team (GERT) in 2023.
During the investigation of one case, we identified that the web server was patched a month after the attacker infiltrated the network: this delay was a treasure trove for the threat actor, since the organization was left unprotected and the attack went unnoticed.
- Immediately after compromising the server, the attacker deployed a SILENTTRINITY C2 stager.
- They attempted to dump credentials via a custom packed version of Mimikatz on the first day, and by dumping the LSASS process memory to disk on the fourth day.
- During that month, they conducted internal reconnaissance of SMB shares until they obtained the credentials of the domain administrator.
Policy violations by employees
Most organizations focus on external threats; however, policy violations pose a major risk, with 51% of SMB incidents and 43% of enterprise incidents involving IT security policy violations caused by employees. An “employee” here is any person who has a regular employee’s level of access to the organization’s systems.
In one of our compromise assessments, we identified an incident whose root cause was traced to a contracted cybersecurity consultant. During an interim report meeting, we presented a list of compromised accounts (a result of darknet search playbook execution) to the customer’s board of directors along with statistics on the accounts on the list. Of all the compromised accounts, 71% belonged to the customer’s employees, with 63% of these being employees’ accounts in the services accessible from outside the company.
The list contained a C-level officer’s account, among others. Since this was a critical situation, with everyone suspecting that officer’s laptop had been compromised, we ran a quick investigation during the meeting and figured out that credentials had been leaked from a third-party consultant’s machine. The chairman created an account in an external system with his own corporate email and shared the credentials with the consultant. Since it was clear that consultant’s laptop might contain other confidential data, we developed the following tactical response plan.
- Collect a forensic triage package from the consultant’s laptop.
- Analyze the package to identify all leaked credentials.
- Check the consultant’s laptop for malware.
- Run a keyword-based search to identify potential leaked documents.
- Review email/VPN/other logs of likely affected services available from outside the organization to detect any abnormal activity by compromised accounts.
- Double-check if multi-factor authentication was enabled for the compromised accounts at the time of compromise.
- Update the incident response plan based on the findings. Reset the password and install a new OS image on the laptop at a minimum.
This incident could have been prevented by ensuring that employees and any third party with access to the network followed the policies. This is easy to say but it sometimes gets tricky and requires time, effort and deep technical knowledge in practice.
MSP/MSSP issues
Usually, MSSPs are more focused on continuous monitoring and alerting, ignoring detection gaps identification and visibility enhancements: a periodic review of the customer’s event audit policy, enabling a disabled log source or highlighting a poorly configured log source. For example, the X-Forwarded-For HTTP header is often not enabled on web servers. As a result, the SOC can’t see the original IP of the connection and determine the attack source, which complicates incident investigation.
In our compromise assessment practice, we frequently identify incidents that external SOCs have missed. During one project, we reviewed third-party antivirus logs and identified multiple webshell detections on the same server for several days.
Day from first exploit attempt | File path | Verdict | Message |
Day 1 | C:Windows[redacte d for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
Day 2 | C:Windows[redacte d for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
Day 3 | C:Windows[redacte d for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
Day 4 | C:Windows[redacte d for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
Day 7 | C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions16TEMPLATELA YOUTS[redacted for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
Day 9 | C:Windows[redacte d for privacy].aspx |
Backdoor.ASP.WEBS HELL.SM |
Malicious software deleted successfully |
The MSSP SOC analysts had failed to raise an alert, because the malware was deleted by the antivirus each time. This is a textbook example of a junior’s mistake. If a motivated adversary has access to the server via a vulnerability, they would try a range of techniques and tactics to try to bypass security. This is where the human analyst’s attention is needed to add an additional layer of protection and prevent this from happening.
This was exactly our case: the Kaspersky experts initiated deep forensic analysis and found out that the attacker tried different webshells over a few weeks. They finally found one that was not detectable by the AV vendor at the time, so they were able to get into the network. Further investigation revealed that the entire domain remained compromised for several months.
Monitoring and verifying the quality of service from your MSP or MSSP is often challenging. Contractual agreements typically prevent clients from accessing the provider’s internal systems for a thorough review. Additionally, customers may lack the technical expertise or time required to oversee every action taken by their subcontractors.
MSPs and subcontractors might not have enough cybersecurity awareness, which poses a challenge, where they might inadvertently expose the network to a cybersecurity risk by misconfiguring some security control or not following the best practice.
Incomplete incident response
Post-breach eradication of a threat actor requires planning of multiple actions to ensure complete removal of the attacker from the network or systems:
- Removal of malware, scripts, tools, and backdoors installed by the attacker.
- Changing the passwords for the compromised accounts and deleting any unauthorized service accounts that attackers might have created
- Rolling back system configurations that might increase the attack surface or introduce new vulnerabilities
Even after the malware is deleted, certain forensic artifacts remain in the system. Therefore, it is common to identify past attacks during compromise assessment. Intentional misconfiguration introduced by an attacker is a rarer case, but we occasionally find that enterprise incident response teams fail to eradicate these procedures.
As part of the Active Directory configuration review playbook, Kaspersky analysts identified a Group Policy with several suspicious properties.
- A modification to the AllowReversiblePasswordEncryption property of each AD account, which made domain controllers store passwords in decryptable form (without using the one-way hash function). This configuration would enable the attacker to dump credentials in plaintext via attacks like DCSync.
- Disabling the audit of operations related to Kerberos Tickets. This configuration would hide attacker logons on all endpoints managed via Active Directory.
False sense of security
It’s crucial to remember that the effectiveness of even top-tier products is at its highest when these are properly installed, configured, and integrated. Without proper configuration, organizations cannot fully harness the potential of their cybersecurity solutions, which hinders their ability to create a robust defense.
In our compromise assessment practice, we have witnessed several cases, listed below, which were detected because specialized scanners were deployed alongside an existing AV/EDR solution, providing a second layer of detection capabilities.
- Absence of detection rules. The customer’s antivirus was unable to detect a pivotnacci webshell because the vendor did not have a defined detection rule.
- Outdated malware signatures. The client antivirus was unable to detect malware because the network port listening to the central update server was blocked by a firewall, preventing the antivirus from receiving the latest updates.
- Shadow IT. The customer’s antivirus was not deployed on certain servers because those servers were not part of Active Directory, which left them unprotected.
Conclusion
Compromise assessment has proven to be an indispensable component in the broader cybersecurity strategy of these organizations. The cases discussed above underscore that no security measure, no matter how advanced, is entirely foolproof. From internal policy violations to patch management failures and overlooked misconfigurations by third-party service providers, the risks are manifold and often hidden in plain sight. These examples highlight that a false sense of security can be more dangerous than no security at all, as it leaves organizations vulnerable to threats that might have otherwise been detected with thorough, periodic assessments.
By integrating compromise assessment into the security framework, organizations can uncover these hidden threats, address vulnerabilities that slip through the cracks, and ultimately strengthen their overall security posture. In a world where cyberthreats are constantly evolving, the proactive identification and mitigation of potential compromises is not just advisable but also necessary. This approach ensures that organizations are not only reacting to breaches but are continuously verifying the effectiveness of their defenses, thereby reducing the risk of undetected compromises and safeguarding their assets more effectively.