Stories from the SOC is a blog series that describes recent real-world security incident investigations conducted and reported by the AT&T SOC analyst team for AT&T Managed Threat Detection and Response customers.
Executive Summary
During the Investigation of a Suspicious Security Critical Event alarm, we discovered credentials had been dumped from the NTDS.dit, which is a database that stores Active Directory data, including password hashes for all users in the domain. By extracting these hashes, it’s possible for an attacker to use tools to gain access to user’s passwords, which allows them to act as any user on the domain, including the administrator. If an attacker gains access to an administrator account, the opportunities are endless.
The team immediately dug deeper into the event and determined a username tied to the actions. In under an hour we had triaged this set of alarms, created the Investigation, and reached out to the customer in accordance with the Incident Response Plan (IRP) that was created in collaboration with the customer’s security team.
Investigation
Initial Alarm Review
Indicators of Compromise (IOCs)
The initial alarm surfaced as a result of multiple alarms with the method of Azure Security Center alert over a short period of time.
Expanded investigation
Alarm Detail
We received 11 low severity alarms with a method of Azure Security Center Alert. Ten of the alarms indicated Domain Name System (DNS) scanning and were all internal traffic. More concerning was the eleventh alert which indicated (by event name) that credentials had been dumped from the NTDS.dit file. The alarming source was a domain controller which added credence to the alarm and reduced the likelihood this was a false positive.
Response
Building the investigation
With the action taken being undefined, I had to assume the credential dump completed successfully. In a best-case scenario, it meant an encrypted file of hashed passwords was sent to an unknown destination. At that point, I determined the Investigation would be escalated to a high severity.
The next significant piece of information was contained in the event details which thankfully picked up a username involved in this activity. This customer had just recently moved to 24x7 monitoring with the MTDR SOC, so we did not have a long history to compare activity from this username or validate that it had an admin role. An administrative role and action by the account would be the only valid business explanation for credential dumping activity. Given the username did exist on the customer’s network and the alarm was preceded by ten other Azure alarms, I inferred that the company was active on their cloud infrastructure and decided to lower the Investigation severity to medium.
Customer interaction
Even though the alarm had originated as a low severity alarm, in under an hour we had triaged this set of alarms, created the Investigation, and made phone calls to the two point of contacts in accordance with the Incident Response Plan (IRP) requirements for a medium severity investigation. The admins were very quick to respond and confirmed that this was valid admin activity. The administrator was conducting password strength checks against all user passwords and needed the NTDS.dit file.
Although this was a false positive, the customer commended the efforts of our team to identify this potential threat and call it out.
Article Link: https://feeds.feedblitz.com/~/629858773/0/alienvault-blogs~Stories-from-the-SOC-Credential-Dumping