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
An SSH Brute Force attack is a form of cybersecurity attack in which an attacker uses trial and error to guess credentials to access a server. Unlike a lot of other tactics used by cybercriminals, brute force attacks aren’t reliant on existing vulnerabilities. Instead, cybercriminals rely on weak or guessable credentials. Brute Force attacks are fairly simple and have a high success rate, with several tools and programs available for attackers to use. Once an attacker correctly guesses valid credentials, they may be able to view, copy, or delete important files or execute malicious code.
The Managed Threat Detection and Response (MTDR) analyst team team received 96 alarms for Brute Force Authentication – SSH Login Failure. The team conducted further analysis and discovered 8,114 failed login attempts involving different usernames in one minute, indicating a legitimate brute force attack. The analysts worked back with customer’s team to block SSH access to the host and prevent any additional logons.
Investigation
Initial Alarm Review
Indicators of Compromise (IOC)
The alarms for this indicator of compromise are part of the weaponization stage, or second stage, of the cyber kill chain. Each individual alarm contained different usernames in each event from a single source IP address. All the alarms originated from different source IP addresses, targeting a public facing host on port 22.
Expanded Investigation
Events Search
Searching for additional events was started by filtering all failed logon events to the effected host to validate no events were missed in the alarms. There were over 4,000 events when the research began and grew to over 8,000 in under a minute. Each “invalid user” error contained a different username.
Event Deep Dive
The attacker was using multiple IP addresses from different countries, indicating a botnet may have been utilized for this attack. The usernames used in the attack did not match any usernames associated with customer accounts, and there was no additional activity involving these usernames.
Reviewing for Additional Indicators
Any additional events during the time of the attack were reviewed to determine if any other indicators of compromise were detected. The SSH activity in the additional events followed the same pattern as the original alarms attempting to exploit port 22 on this public facing host. All SSH attempts were failed and the host was not compromised.
Response
Building the Investigation
As the alarms and events came into the queue, it was recognized it could be a potential dictionary attack. We reviewed the details of each alarm and events associated with that alarm and determined the usernames used did not match any of the known user accounts. There were no successful logins during this activity as all the usernames were not legitimate. A successful attack would compromise the bastion server and potentially provided access to the rest of the environment. While the alarms were incrementing in the queue, an investigation was created and a report outlining the events was provided to the customer. The event details were added to the Investigation and we provided a recommendation to the customer to review the firewall policy configuration.
Customer Interaction
The customer responded quickly to the investigation, confiming this was a brute force attack over SSH. They disabled access to the bastion server, preventing any further malicious activity. Once the investigation was concluded, the details of the destination bastion server were reviewed. Since this host is public facing and port 22 is opened, we informed the customer that best practice would be to close all unnecessary ports as we would likely see more scanning events in the future if it remained open.