Stories from the SOC -SSH brute force authentication attempt tactic

May 18, 2021 | Todd Luft

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.

IOC for brute force authentication attack

SSH login

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.

brute force attack recommendation

Customer Interaction

customer interaction brute force attack

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.                                                                                                                                    

Todd Luft

About the Author: Todd Luft

Senior Specialist Todd Luft joined the Managed Threat Detection and Response (MTDR) team as a tier 1 analyst in October 2020. Todd's previous experience includes network and security engineering for one of the United State's largest healthcare systems. Having witnessed firsthand the devastating effect cyberattacks can have on an organization, Todd takes great pleasure in serving as the first line of defense for MTDR customers across numerous industry verticals. Always interested in tackling new challenges and learning new tools and technologies, Todd's favorite part of the job is investigating unique alarms and researching new cyber threats.

Read more posts from Todd Luft ›

‹ BACK TO ALL BLOGS

Get price Free trial