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 Extended Detection and Response customers.
Executive summary
User account credentials are both a necessary component of normal operations and a critical vector for a malicious actor’s entrance into an enterprise environment. Compensating for the inherent risk of granting the end user access to corporate systems is a challenge in balancing usability with security. When a user with low-level privileges can have their credentials abused to gain increased levels of access, superior solutions to standard username-and-password schemes become necessary. The use of common multi-factor authentication (MFA) through mandating login approval via a mobile device can enable significantly heightened security without significantly compromising the user experience, while allowing security investigators better visibility into potential attempts to infiltrate infrastructure.
The AT&T Managed Extended Detection and Response (MXDR) SOC analyst team received an alarm for a rejected MFA challenge which was triggered by several login attempts from an unrecognized IP address. After investigating, the SOC discovered that this was the aftermath of a malicious actor attempting to gain access to the customer’s systems through this user’s compromised credentials. After communicating with the customer, it was determined that the user’s asset was lacking essential endpoint protection and security monitoring coverage, which may have caused the initial compromise and was remediated as a result of the SOC’s vigilance.
Investigation
Initial alarm review
Indicators of Compromise (IOC)
The initial alarm was triggered by a built-in USM Anywhere rule named “User Reported Suspicious Activity in Okta”. This rule was developed by the Alien Labs team to trigger when an Okta user rejects a login attempt from an unrecognized source. Okta, a popular multi-factor authentication and single sign-on service provider, incorporates this feature into their products to help detect malicious behavior.
Expanded investigation
Events search
In this case, the initial alarm lacked detail: the analyst could tell from where the user rejected the suspicious login, but no information about the suspicious login itself. Additionally, no other alarms had been generated as a result of the user’s activity: could this detection simply be a false positive, or a mistake by the reporter? Additional event information was needed to determine whether this was the case. To begin, additional information derived from the original event used to make the alarm was located.
The information gained from this event was invaluable: not only was the reported IP thousands of miles from the user’s location, but open-source intelligence (OSINT) indicated that the IP address in question was malicious. At this stage, it appeared likely that a malicious entity had gained access to the account’s credentials, but more information was needed to ascertain if any further damage had occurred to the customer’s environment. To locate more events, filters were applied in USM Anywhere to search specifically for events associated with both this malicious actor’s IP address and the user’s account.
Event deep dive
To determine the extent of the compromise, activity to and from the malicious IP was examined. Initially, little of note was found outside of the already-located login activity. However, when the event view was expanded to include events from the last 90 days, it was revealed that the malicious actor had initiated many connections to the customer’s Amazon Web Services (AWS) environment several months prior, perhaps as a form of surveillance. This finding made it clear that the attacker had been interested in the customer for some time but had only initiated clear action at the time of the alarm.
Further examination into user activities revealed shockingly little of note. Successful logins could be found, but no malicious activity after the fact was immediately visible. The user reported the suspicious activity six hours after it initially occurred: did any compromise occur in this time? The answer appeared to be no, but the combination of a seemingly determined, patient attacker and an apparent compromise of credentials made further analysis of the matter essential.
Response
Building the investigation
Utilizing the findings seen above, an investigation was created in the customer’s USM Anywhere instance detailing the activity. Shortly after receiving the investigation, the customer began to examine all information associated with the user’s account internally.
Customer interaction
Upon beginning their internal investigation, the customer escalated the severity of the investigation and confirmed that a true compromise of the user’s credentials had taken place. The customer also confirmed, fortunately, that MFA successfully prevented all logins from causing further harm. Not only did the company’s MFA solution result in the creation of the initial alarm, it also mitigated the impact of the attack. After confirming this, the customer reset the user’s credentials and set out to determine the root cause of their initial compromise as the SOC provided additional details relating to the attacker’s IP to aid in finding any malicious activity which the attacker may have conducted.
As a result of the SOC’s investigation, the customer uncovered a significant gap in security coverage on the affected user’s asset. The monitoring and endpoint protection software suites used by the customer were not properly functioning, creating a blind spot in the customer’s environment that potentially contributed to the initial compromise of the user’s credentials. Because of the SOC’s work, this issue was able to be remediated.
