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
Since mid-June 2022, AT&T Managed Extended Detection and Response (MXDR) Security Operations Center (SOC) observed an enormous number of attacks from Mirai botnet-C2 attempting to gain access to SSH servers instead of Telnet.
Due to the various tactics, techniques, and procedures (TTP) observed, this attack has been associated with RapperBot botnet (Mirai variants.) RapperBot’s goal is still undefined.
According to the analysis that was published by FortiGuard Labs, while the majority of Mirai variants can naturally brute force Telnet servers that use default or weak passwords, RapperBot in particular scans and attempts to brute force SSH servers that are designed to require password authentication.
A large part of the malware is executing an SSH 2.0 client which is able to connect and brute force any SSH server using Diffie-Hellman key exchange with 768-bit or 2048-bit keys and data encryption using AES128-CTR. A unique characteristic of brute forcing in RapperBot is the use of SSH-2.0-HELLOWORLD in order to identify itself to the targeted SSH server during the SSH Protocol Exchange phase.
One of the malicious Mirai botnet IP addresses had allowed network traffic with an asset in an organization over SSH port 22. After some data transferring, the session closed with the client-reset action. The MXDR SOC team quickly identified and recommended mitigation steps to prevent lateral movement and the attacker going further.
Investigation
Initial alarm review
Indicators of Compromise (IOC)
The alarm initiated with the multiple Open Threat Exchange (OTX) pulses (Miraibotnet-C2- CDIR Drop List) and an OTX indicator of a known malicious IP. There was network traffic between the known malicious IP and a public IP of an internal asset in an organization. The network traffic was over SSH port 22, and the security system (firewall) action was a deny. The security system (firewall) deny action was evidence of the auto-mitigation. In this case, auto-mitigation means the attack is prevented by firewall rules and threat intelligence by denying the connection from malicious IP.
However, further analysis of the events showed that the traffic was allowed from the malicious IP to another internal asset. In addition to this, there were signs of data transfer from source IP with “sentbyte=1560, rcvdbyte=2773, sentpkt=15, rcvdpkt=13”
** Risk mitigation in Cybersecurity is the reduction of the overall risk/impact of cyber-attacks. Detection, prevention, and remediation are three components of risk mitigation in cybersecurity.
Expanded investigation
Events search
After checking events associated with the alarm, the team always checks the environmental security to see if the malware had further penetrated the environment or attempted any lateral movement.
The team searched events by pivoting on the indicator IP, filtering the past 90 days of events, and the security system (firewall) allowed action types. It was determined that there were a few connections from malicious IP to different internal assets with the client-rst, server-rst, timeout, and closed events.
Client-rst – Session reset by client, Server-rst – Session reset by server
These are usually session end reasons that show who is sending TCP (Transmission Control Protocol) reset and the session terminates – so this does not mean that a security system (firewall) is blocking the traffic. It means after a session is started between client-to-server, it is terminated by (client or server), depending on who sent the TCP reset. Session-end results can be found in traffic logs.
The team suspected that the system might be compromised because the session was reset from the client side (which is the adversary side.) It was then observed that the session was closed (terminated) with a large amount of packet transmissions.
Event deep dive
After further examination of the allowed connections, the malicious IP showed traffic with the customer security system (firewall) over SSH port 22. SSH port 22 uses a TCP connection. Therefore, before transferring data it needs to establish a reliable connection with the 3-way handshakes.
In order to handshake the header (first two packets), TCP uses approximately 24 bytes and for normal transmission of packet about 20 bytes. Establishing a reliable connection with 3-way handshake needs just three packets to be transmitted. Establishing a connection: ~ 128-136 bytes.
Another observation is that the sent and received bytes with the packet size are indicators of data transferring due to the packets and bytes being bigger than normal packets and bytes of TCP 3-way handshake. This is believed to be an indication of a payload or compromised credentials.
Rapperbots work like an SSH brute-forcing campaign. After it has gained access on a device, it sends its architecture to the C2 server – the device’s IP, and the credentials used. Then the adversary tries to load the main payload binary on the compromised device via binary downloader or software like ftpget, wget, curl, or tftp, that is installed on the device.
Reviewing for additional indicators
At this point, the attacker tried to get “Initial Access (tactic)” into the network by using “Exploit Public Facing Application” technique based on the Mitre Att&ck Framework.
Exploit Public Facing Application is a technique which is used by adversaries to take advantage of vulnerabilities/weaknesses in a program or internet facing computer to gain Initial access to a network. In this case, even though there was evidence of data transfer, evidence of payload or lateral movement activity were not seen.
Response
Building the investigation
An investigation was created by following the incident response process. The investigation included identifying the incident, finding the root cause of the incident and Indicators of compromise. Then we made recommendations to the customer on mitigation/remediation steps. We communicated with the customer to ensure necessary actions are executed. Recommended mitigation steps were:
Blocking the malicious IP
Disabling SSH password authentication (if possible)
Changing passwords to stronger passwords for the device.
Incident response is an organizationed approach and process to manage cybersecurity breaches/incidents or cyberattacks. It includes multiple steps:
Identifying an incident/attack
Minimizing damage
Eradicating the root cause
Minimizing recovery cost and time
Learning lessons from the incident
Taking preventative action
According to the analysis that was published by FortiGuard Labs, Rapperbot developers improved their code to maintain persistence, which differentiates it from other Mirai variants. Even after rebooting infected assets or removing malware, intruders can continuously access infected assets via SSH. Therefore, rebooting the device or removing malware Is not a permanent mitigation option.
The Rapperbot’s primary threat is brute forcing the credentials of SSH. By disabling SSH password authentication (if possible), or changing passwords to stronger passwords for the device, the Rapperbot mitigation can easily be done.
Customer interaction
The customer wanted to be kept in the loop and informed if the attack continues.
Limitations and opportunities
Limitations
In this investigation, MXDR was unable able to see inside the transmitted packets. As a result of the lack of visibility into the network flows in the environment, MXDR has limited access to the customer environment. However, MXDR suspected the data transfer could include the main payload binary on the compromised device.