5 from ransomware

The strategies of the attackers:

Cybercriminals rely on a combination of different techniques to achieve their goals. The main strategies include:

• Mail bombing: A flood of emails to overwhelm the victim and bypass security mechanisms.
• Impersonation of IT staff: Deceptively real identities to trick employees into installing malicious software.
• Installation of a fake patch: An alleged update for the existing mail-bombing problem, which in reality triggered an infection with malware.

Once access is gained, a series of malware tools are executed. These were unknown at the time of analysis based on signatures and each incident had additional and previously unrecognized features. After compromising the first system, the attackers attempted to gain access to the domain controller in order to take over the entire company domain. The attack methods varied depending on the existing security measures of the affected organizations. Despite these sophisticated attack strategies, in none of the cases investigated by the CDC did the cybercriminals succeed in taking complete control of the company's IT. This was due, among other things, to the automated countermeasures that slowed down or limited the attackers, the rapid responses (e.g. system quarantine) by security modules (EDR, SIEM...), manual interventions by corporate IT or the initiation of incident response, which limited the attackers. 
Due to the countermeasures taken, no definitive conclusions could be drawn about the attackers' intentions. However, several public sources and findings from the CDC Threat Intelligence Service indicate that this was a known ransomware group.

Graphically simplified attack sequence:

The steps shown in the graphic below are referenced and described in more detail in the following analysis.

_{Fig.: Graphically prepared sequence of the attack}

Initial infection:

The attackers launch their attack with a combination of spam emails (1) and direct contact via Microsoft Teams. They pretended to be IT support and offered supposed help to fix the "email problem" (spam emails).

It was noticeable that the attackers used their own Microsoft tenants, including:

• Fastsecurity.onmicrosoft.com
• securepointsupport.onmicrosoft.com
• supporthelpdeesk.onmicrosoft.com

The attacker's chosen usernames also reflected country-specific names where the victim company is located.

Social engineering and persistence:

These communication attempts (2), can be easily traced via central SIEM (CDC LOG Module) using O365 Unified Audit Logs. In the image below, it can be seen that several chats were opened between the attacker and the victim.

_{Fig.: Teams social engineering analysis via UAL logs}

The behavior patterns of the attackers varied slightly between the cases investigated. In some scenarios, they initiated Teams calls between attacker and victim, providing links to download a Remote Monitoring & Management (RMM) tool. In other cases, they conducted remote sessions with the victims in which they actively searched for internal company RMM tools via the user system. In some cases, these were even identified and installed via company-internal sharepoint systems in order to bypass any firewall/proxy rules. In all cases, the attack ended with the execution or installation of one or more RMM tools, which gave the attackers access to the victim system.

Multiple malware executable downloads

In some scenarios, employees were sent on a "coffee break" because the "IT employee" (attacker) needed time to fix the alleged spam mail problem. Depending on the RMM used (Teamviewer, Anydesk), the attacker downloaded further malware tools (3) onto the victim's system and executed them to create further persistence on the system.

An excerpt from the Teamviewer connection logs confirmed remote sessions between the attacker (e.g. name: Lily Fox) and the victim system:

Lily Fox 08:29:48 08:34:48 <VictimUserName> RemoteControl{redacted}
Lily Fox 08:36:33 08:41:32 <VictimUserName> RemoteControl {redacted}

_{Fig.: Teamviewer connection log / remote connection of the attacker}

The malware samples downloaded per case varied by signature and name, but their functionality and naming sense was similar. Below is an example of the tool used by the attackers (EDR):

In later detected cases, the attacker increasingly abandoned AntiSpam.exe and instead relied on DLL files (e.g. AntispamModule.dll), which had the same functionality but was executed with rundll32.exe to make detection by security solutions more difficult (evasion).

In addition, various enumeration commands were executed via cmd.exe, including

• ipconfig /all
• route print
• systeminfo

The malware tools mentioned were largely detected by EDR systems, even if their signatures were initially unknown. A more detailed analysis and continuous monitoring was necessary, as in every case at least one of these tools was not detected as malicious. It was also noticeable that most of these tools were launched via Explorer.exe - an indication of manual interaction by the attacker or the victim, which was also confirmed in the analysis.

A correlation of the infected system with the logging or SIEM (domain controller logs) quickly revealed that the extent of the attack was greater than initially assumed. The attacker attempted to generate a machine account in the Active Directory (EventID 4741) using the executables mentioned and the infected user (SubjectUserName) -(6).
Monitoring the creation of machine accounts that are not created by IT staff can be easily implemented with a SIEM and is an effective measure for detecting such attacks.

_{Fig.: A machine account (SRVVSSKL) was created by the attacker}

This machine account was identical in all attack patterns and thus provided an easily recognizable indicator (SRVVSSKL) for detecting these attacks. Depending on the configuration and patch level of the domain controller, the attack was successful to varying degrees. However, the default values are frequently encountered, where, put simply, authenticated domain users are authorized to create up to ten machine accounts. If the attacker succeeded in creating such an account, he could continue to use it - even if the originally infected user account was quarantined or blocked. If this step in the attacker's movement is overlooked, it can have serious consequences and leave the company in an unclean state or leave the attacker in the company.

In cases where the attacker was able to successfully create a machine account, kerberoasting (7) was then carried out. This technique is used to extend the rights of a low-privileged user to service level, among others. However, its success depends largely on the password complexity of the attacked Service Principal Names (SPNs).

The run key created referred to AntiSpamUpdate.exe, which also acted as a command-and-control service.

Command and Control (C&C):

_{Fig.: C&C Communication via DNS Tunneling}

It is noteworthy that the C&C communication took place partly directly via port 443 and partly via DNS tunneling (SystemBC/Socks5) -(5). With DNS tunneling, the attacker hides the C&C communication within the DNS protocol (e.g. data is packaged as a subdomain). This makes it difficult to automatically detect malicious network traffic using firewalls, for example.

Blocking outgoing connections from the client at the perimeter is not sufficient in this case, as DNS tunneling also works via internal DNS servers, which forward the DNS queries - and therefore the C&C communication - on behalf of the client. However, reliable detection is possible if DNS server logs are saved and monitored. In this case, the CDC log module (DNS data) can be used to alert and respond to DNS tunneling.

Containment and sweeping:

The analysis included company-wide sweeping for the attacker's techniques and Indicators of Compromise (IOCs) to identify whether other users had been attacked. This was the case in some analyses with regard to Teams communication and e-mail bombing. However, these users did not start a session with the attacker, but recognized this as an attack from the outset, ignored the alleged IT support or were on vacation at the time of the attack. Countermeasures and education for these users were then taken to prevent reinfection.

In none of the cases investigated by the CDC did a domain or enterprise breach occur, thanks to swift countermeasures. However, public analyses and threat intelligence (TI module) revealed the potential extent of the attack (full company breach / company-wide ransomware).

Countermeasures taken in the short term depended on the progress of the attacker and the progress of the analysis and included, among other things

• Quarantining the user system
• Blocking the initial user
• As well as changing the user's 3rd party passwords
• Deletion / blocking of the machine account created by the attacker
• Changing the SPN passwords (Kerberoasting)
• Blacklisting of attacker tenants (alternatively whitelisting of legitimate tenants)
• Temporary restriction of O365 remote sharing options
• Company-wide restriction of RMM tooling (if possible)
• Blocking of the C&C domains
• Rolling out an EDR
• Customization of default values for machine account generation
• Extended monitoring / extended logging
• Restriction of the use of RMM tools.

Recommended organizational and long-term measures

Detection and response:

• Attackers act extremely quickly (<1h for initial infection, privilege escalation and lateral movement).
• Rapid detection and response are essential.
• Recommended:
  ✅ Proactive monitoring by a Security Operations Center (SOC) or security modules.
  ✅ Automated prevention measures to block attacks at an early stage.
  ✅ Rapid incident response to effectively contain threats.

Endpoint Detection & Response (EDR)

• Most attacker tooling was detected by common EDR solutions, even if it was unknown based on signatures.
• BUT: Not all tools were detected → analysis remains essential.
• Recommended:
  ✅ Continuous EDR monitoring to detect attacker activities at an early stage.
  ✅ Extended analyses to identify undetected activities (privilege escalation, persistence, lateral movement).

Security Information & Event Management (SIEM)

• If a SIEM with appropriate detection was in place, it enabled:
  Detection of lateral movement, domain privilege escalation, persistence and C&C communication (DNS tunneling).
• Important finding:
  Cleaning up the employee system would have been insufficient in many cases.
  ➡ Attackers had often already created their own machine accounts on the domain controller or compromised service user credentials (e.g. through Kerberoasting).
• Recommended:
  ✅ Correlate domain controller logs with SIEM to detect suspicious activity.
  ✅ Monitor machine account creation and service principal names (SPNs).