(By Naveen and KS threat research)

Introduction

“Why hack into a system when you can politely just ask for it?”

Since early October 2024, Kudelski Security has observed an ongoing campaign in which threat actors employ a notably human interactive social engineering approach to infiltrate targeted networks. These attackers use Microsoft Teams to impersonate IT support personnel (vishing), where they contact employees directly, aiming to manipulate them into installing remote-access software, specifically AnyDesk, under the pretense of providing technical assistance.

The attack itself, with the exception of this initial phase, has the classical cybercrime techniques. It begins with a method known as registration bombing, where attackers register the victim’s corporate email address across hundreds of online platforms simultaneously. This tactic floods the victim’s inbox with spam from multiple legitimate domains, which bypasses standard spam filters and overwhelms the target’s email with what appears to be legitimate, unsolicited messages. Seeking help for this sudden influx of spam, the victim may then reach out to or be approached by the fake “IT support” team.

At this point, the threat actor initiates contact through a Microsoft Teams call, presenting themselves as an IT professional ready to assist. Speaking in the local language (in this case, German), they persuade the victim to install AnyDesk, ostensibly to resolve the email issue. Once granted access, the attackers quickly deploy a range of malicious binaries and begin laying the groundwork for broader network compromise.

Other security vendors have attributed this activity to affiliates of BlackBasta. Based on the techniques we’ve observed, we see strong similarities with cases we’ve previously worked on. That said, the attacks were detected and mitigated early, successfully preventing both data exfiltration and any disruption from potential encryption events. As a result, the only actions carried out by the threat actor were the initial steps, which are shared among most cybercriminal operations.

The key takeaway from this post is that while organizations typically have measures in place to defend against email threats—thanks to the wide range of vendor solutions available—it’s much harder to tackle side-channel threats via phone calls or messaging apps like WhatsApp, Signal, or Microsoft Teams. While sending an email to millions of recipients is relatively easy, making phone calls to that many individuals is far more complex. Despite this challenge, recent cyberattacks that combine email with follow-up phone calls have proven effective, and this technique could become more widespread among cybercriminal groups in the future. Shifting from a mass, opportunistic attack to a more targeted strategy that leverages human interaction creates a new threat landscape that is difficult for organizations to monitor and protect against. While phone-based social engineering may be one of the oldest hacking tactics, the rise of chat apps and mobile phones has made it even harder for organizations to gain visibility into these threats. The fact that cybercriminals are adopting these techniques shows that the barrier to entry is low.

Other vendors also published about this attack types: Microsoft[1], Reliaquest [2], rapid7 [3]. We are providing additional details and queries for hunting and detections.

Details of the Attack

Spam Burst: Creating Confusion to Enable Social Engineering

This campaign’s initial phase is deceptively simple yet effective. Threat actors began by registering the victim’s business email across hundreds of legitimate sites in a technique known as registration bombing. The result is an immediate burst of verification emails and account creation emails each coming from a legitimate source. An account is created on variety of sources ranging from a florist in Czech Republic to an attorney in Chicago. This barrage of emails quickly overwhelms the victim’s inbox, causing sudden panic and helplessness in handling the situation on their own.

At first glance, it’s easy to question —if these emails are from legitimate domains and contain no malicious links, where’s the harm? The answer is simple: this isn’t typical phishing. By overwhelming the inbox, attackers create stress and confusion, making victims more likely to respond impulsively.

In the incidents that Kudelski Security responded to, that’s exactly what happened. Even the users who are typically careful with spam and phishing emails failed to respond with caution as they were in a sense of panic seeing continuous influx of registration emails in various languages that they were never exposed to in the past. The spam burst served as the foundation for what followed, the next phase of the attack: direct social engineering.

IT Support: The Social Engineering Twist

Right when the victim needed “IT Support”, the threat actor disguised as IT support, contacted the victim through Microsoft Teams, convincing them that they were there to resolve the spam issue.

The attacker, speaking in the local language (German), further built trust with the victim, making their approach appear even more legitimate. They assured the victim that the spam problem—one they had caused—could only be resolved by remotely accessing the victim’s computer.

Remote Access: Through the Teams chat, the threat actor instructed the user to download Remote Management Tool, AnyDesk from the official AnyDesk website. AnyDesk being commonly used by IT support and other teams, never raised a suspicion. After the user provided the access key, the attacker connects.

Once the victim followed the link and installed AnyDesk, the attacker gained full access to the system. They then transferred multiple malware files, including antispam.exe. When executed, the file triggered a Windows authentication screen titled “antispam filter,” reinforcing the illusion that they were installing a legitimate anti-spam solution. Trusting the process, the victim entered their credentials into the fake prompt.

At this point the threat actor had already managed to gain initial access into the host, obtained clear text credentials and also downloaded multiple malicious binaries needed for further steps in the attack. In addition, the threat actor also convinced the victim to take a break while they work on this “issue”.

Based on the logs, we couldn’t determine whether the German-speaking individual was also the one carrying out the technical operation on the host, or if this task was the result of collaboration. This distinction is important because, if it was not the same person, it could suggest that an individual was hired to provide L1 IT support in the local language, without knowing his work was in support for malicious cyber operations. The statement of work would involve assisting legitimate IT support in installing the remote agent before escalating the ticket to L2 support, where the actual threat actor is involved.

Once the remote access tool is installed, the attack progresses to a more traditional ransomware or cybercrime group technique. At this point, we revert to classic ransomware tactics, techniques, and procedures (TTPs), which can typically be detected by conventional endpoint security products.

Threat Actor malwares

Malwares Binaries Dropped

Once the threat actor gained access to the host, they immediately dropped a series of malicious binaries onto the system.

Even if the victim pays attention during the AnyDesk session, they are very likely to assume that the “fake” IT support  was working to fix the spam problem as all the binaries were named “antispam”.  This prevents users from raising suspicion.

Each of the dropped binaries served a distinct purpose, with some recognized as known malicious files, but many of them were unknown hashes at the time of our Incident Response engagement.

Antispam.exe: Credential Theft and System Enumeration

When executed, the antispam.exe binary triggered a Windows pop-up titled “spam filter update,” and asks for victim’s username and password. Once the victim enters their credentials, the username and password is validated against the domain and both the username and password entered by the user are saved in clear text to the “qwertyuio.txt” file. If invalid credentials were entered, the file would record the input along with a note indicating that the credentials were invalid, and the window pops up again asking the user to re-enter their username and password.

In addition to capturing credentials, the binary performed basic system enumeration, running commands such as systeminfo, route print, and ipconfig /all. The output of these commands was also saved to the qwertyuio.txt file.

Once the clear-text credentials were captured, the threat actor used the AnyDesk session to copy the qwertyuio.txt file from the victim’s system, further enabling their attack on the network.

Antispam.exe (SHA1: 1a3f14465460a61e012d11cccf301424f2c0f11d)

Antispam_account.exe: Machine Account Creation and Evasion

The functionality of the antispam_account.exe binary was straightforward— create a machine account with a hardcoded password. The initial binary was detected and blocked by Microsoft Defender; however, the threat actor dropped a modified version the binary to bypass the detection and execute it.

When we analyzed the modified binary in our lab, we found that it failed to create the machine account. However, in a parallel investigation that Kudelski Security was responding to, we extracted another version of the binary and that successfully created a machine account named SRVVSSKL$ with a hardcoded password: GCmtHzw8uI$JnJB

From a defender’s perspective, it’s crucial to monitor for such machine account creations and ensure that the new account’s activities are also reviewed during the investigation

Antispam_account.exe (SHA1: dccca05c9833b78dc75c7045e80056b35815ae93, 093693a336c4ab28a4e1a3e7999a0bc6cee4ba05)

Antispam_connect_eu.exe / Antispam_connect _us.exe:

The antispam_connect_eu.exe and antispam_connect_us.exe are the SystemBC binaries dropped by the threat actor to establish tunnel and maintain persistence even after the AnyDesk session is over. SystemBC is a proxy malware that leverages SOCKS5. This provides the ability for the attacker to launch the attacks against the domain as if their workstation is directly connected to your network. SystemBC also allowed the threat actor to deploy additional tooling to launch their attacks.

The antispam_connect_eu.exe managed to establish successful connection with the Command and Control (C2) IP, 157.20.182.233. This was heavily used by the threat actor to perform Enumeration (Sharphound, Impacket, etc.) as well as for the lateral movement attempts.

Antispam_connect_eu.exe: (SHA1: 517a916a794161deabf13ff2cd45956b8b918eb4)

antispam_connect_us.exe: (SHA1: 192b284e7bc7f43f1723d99b62bdbfe71334ce10)

Antispam_connect_1i.exe:

The antispam_connect_1i.exe binary was particularly noisy, initiating numerous external connections, including multiple Russian IPs. IPs that it reached out to: 46.8.232.106, 46.8.236.61, 93.185.159.253, 188.130.206.243.

As soon as the binary was executed, it attempted to establish persistence. For victim having enabled the Software Restriction Policy (SRP), it blocked PowerShell execution on the system.

powershell -WindowStyle hidden -Command "if (-Not (Test-Path \"HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\App\")) { Set-ItemProperty -Path \"HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"App\" -Value \"C:\Users\redacted\antispam_connect_1i.exe\" }"

antispam_connect_1i.exe: (SHA1: db2067ddaa6a3396238dc3353ec1edccc0dd9030)

Enumeration:

Once the threat actor established a SOCKS proxy tunnel using SystemBC, they performed extensive enumeration activities against the domain.

They used multiple common public offensive tools for enumeration such as SharpHound ( to map Active Directory structures and relationships), Impacket modules—such as wmiexec.py, psexec.py, and smbexec.py and so on.

Lateral Movement

Multiple lateral movements paths were attempted, but none of them were successful.

SVCCTL (Service Control Manager over RPC)

Named pipes in SMB, accessed via the IPC$ share over TCP port 445, are leveraged by threat actors for lateral movement within a network. They enable a range of operations, from NULL session contexts to those requiring local administrative privileges. For instance, svcctl facilitates the creation, starting, and stopping of services to execute commands on remote hosts, a functionality utilized by tools like Impacket’s psexec.py and smbexec.py.

We could see the attempts to open svcctl and SMB access over the remote host via IPC$ share. Monitoring for unauthorized service creation can be done through capturing the 4679 events.

Observed Threat Actor Devices

During the lateral movement using RDP and Network logons, devices named vultr-guest and callous-cause.aeza.network were detected, indicating the threat actor’s infrastructure used in the lateral movement attempts.

Kerberoasting

Kerberoasting is an attack against service accounts that allows an attacker to perform an offline password-cracking attack against the Active Directory account associated with the service.

About 30 minutes into the AnyDesk session, the threat actor executes an LDAP query to enumerate Kerberoastable accounts (user accounts with a Service Principal Name (SPN) set). This was immediately followed by the initiation of the Kerberoasting attack itself.

(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=redacted,DC=com)(!(userAccountControl&2))(servicePrincipalName=*))

Kerberoasting is a technique frequently used by threat actors, and in the majority of ransomware cases our CSIRT has responded to, we’ve observed it being attempted — often being successful. We highly recommend reviewing Microsoft’s guidance on Kerberoasting here and apply necessary mitigation measures.

Detection / Threat Hunting Opportunities

For detection and threat hunting, we focus on the initial phase of the attack, as the more traditional cybercrime TTPs are already well-documented in numerous blog posts.

Alert when a user is at risk:

• External teams chat containing suspicious link to remote management tools

CloudAppEvents
| where Application == "Microsoft Teams" and        ActionType == "MessageCreatedHasLink" and       //left to keywords like anydesk, if needed        RawEventData.MessageURLs has_any("") and       // remove this line of phishing done from an internal user account        RawEventData.ParticipantInfo.HasForeignTenantUsers == true  

• Hunting query to review linked shared in one to one chat from external users  

CloudAppEvents
| where Application == "Microsoft Teams" and ActionType == "MessageCreatedHasLink" and    RawEventData.ParticipantInfo.HasForeignTenantUsers == true and      RawEventData.CommunicationType == "OneOnOne"
| summarize  count(), min_value=min(['TimeGenerated']), max_value=max(['TimeGenerated']) by tostring(RawEventData.UserTenantId), ActionType, tostring(RawEventData.MessageURLs)

• Find user that are targeted by registration bombing.

EmailUrlInfo
// Filter for URLs related to password resets coming from wordpress
| where Url contains 'wp-login.php?action=rp'    
| project NetworkMessageId, Url, UrlDomain
| join kind=inner (EmailEvents) on NetworkMessageId  
| summarize
   Count = count(),
   Urls = make_list(Url)
by RecipientEmailAddress

This query identifies emails from WordPress, as they make up a significant portion of registration bombing attempts. However, additional patterns can also be incorporated.

Security Hardening Opportunities

A well-configured Active Directory setup, along with endpoint hardening, are effective measures to slow down or even block threat actors. We strongly recommend that organizations conduct annual configuration reviews. Our incident response team’s data shows that addressing these areas can significantly reduce the impact of a breach. However, this blog post will focus on those initial steps.

Remote access tools are widely used, and in large organizations, it’s common to have multiple such tools installed. This often happens because different local IT teams rely on different remote access solutions for support. To address this, organizations should define a set of approved support tools and establish a standardized installation process. This allows for the creation of detection rules to identify any tools that deviate from the authorized list or were installed outside the defined procedure. Additionally, we recommend blocking the domains associated with these remote access tools at the host level. We advise against only doing this at the corporate firewall level, as many organizations’ home office policies mean that not all traffic is routed through the corporate environment, leaving users vulnerable. You can find the list of proposed blocking in the annexes.

To enhance the security of your Microsoft Teams environment and prevent unauthorized access, it is recommended to block external or unknown tenants from being able to interact with your organization’s Teams environment. However again it depends on your organization context and needs.

Steps to Block Unknown Tenants in Microsoft Teams:

Configure External Access Settings:

• In the Microsoft Teams Admin Center, navigate to External access.
• Set external access to Off or limit it to trusted domains only (i.e., your partner or vendor organizations).
• This setting will prevent users from communicating with external Teams tenants unless explicitly allowed.

Control Guest Access:

• In the Teams Admin Center, go to Guest access.
• Disable guest access entirely or restrict it to only specific trusted domains or user groups.
• By limiting guest access, you prevent unauthorized external users from being added to your Teams channels or chats.

Review and Restrict “Teams” Guest Permissions:

• If guest access is necessary, restrict the permissions guests have within Teams by customizing the guest settings.
• Disable sensitive features such as file sharing, meeting scheduling, or team creation for guests.

Block external users to contact user in your organization

• In the Teams admin center, go to External access.
• Turn on the People in my organization can communicate with Teams users whose accounts aren’t managed by an organization setting.
• Block external unmanaged Teams users to start the conversation, unselect the External users with Teams accounts not managed by an organization can contact users in my organization checkbox.

Threat Intelligence / Indicators of Compromise

Contact us:

Contact us here if you have any questions or if you need support in responding to such a situation.

Hardening recommendations annexes

We recommend blocking the following domains to prevent successful connections from commonly used remote access tools. Before implementing this block at the host level, it is essential to verify that no department is utilizing these tools for legitimate purposes. Additionally, keep in mind that the IP address associated with the domain can be changed to one owned by your organization, allowing you to display a custom message to users attempting to connect. Credit to https://github.com/LivingInSyn/RMML for providing the domains used for the connection.

Some remote access tools, such as RustDesk, require additional security measures because threat actors can set up their own infrastructure, allowing them to use any domain they choose.

We provide an example using the lmhosts file on Windows systems. However, these block lists can also be implemented through EDR and firewall rules. Adapt them to suit your organization’s setup.

# Network blocking anydesk

127.0.0.1 *.net.anydesk.com

# Network blocking atera

127.0.0.1 pubsub.atera.com

127.0.0.1 pubsub.pubnub.com

127.0.0.1 agentreporting.atera.com

127.0.0.1 app.atera.com

127.0.0.1 agenthb.atera.com

127.0.0.1 packagesstore.blob.core.windows.net

127.0.0.1 ps.pndsn.com

127.0.0.1 agent-api.atera.com

127.0.0.1 cacerts.thawte.com

127.0.0.1 agentreportingstore.blob.core.windows.net

127.0.0.1 atera-agent-heartbeat.servicebus.windows.net

127.0.0.1 ps.atera.com

127.0.0.1 atera.pubnubapi.com

127.0.0.1 appcdn.atera.com

127.0.0.1 atera-agent-heartbeat-cus.servicebus.windows.net

127.0.0.1 ticketingitemsstoreeu.blob.core.windows.net

127.0.0.1 a32dl55qcodech-ats.iot.eu-west-1.amazonaws.com

# Network blocking fleetdeck

127.0.0.1 ‘*.fleetdeck.io’

127.0.0.1 fleetdeck.io

127.0.0.1 fleetdm.com

# Network blocking gotomypc

127.0.0.1 ‘poll.gotomypc.com’

# Network blocking level.io

127.0.0.1 agents.level.io

127.0.0.1 online.level.io

127.0.0.1 builds.level.io

127.0.0.1 downloads.level.io

# Network blocking ninjarmm

127.0.0.1 ‘*.ninjarmm.com’

127.0.0.1 ‘*.ninjarmm.net’

127.0.0.1 ‘*.rmmservice.com’

# Network blocking QuickAssist

127.0.0.1 remoteassistance.support.services.microsoft.com

127.0.0.1 ‘*.support.services.microsoft.com’

127.0.0.1 remoteassistanceprodacs*

# Network blocking ScreenConnect

127.0.0.1 myconnectwise.com

127.0.0.1 connectwise.com

127.0.0.1 screenconnect.com

127.0.0.1 itsupport247.net

# Network blocking Splashtop

127.0.0.1 ‘*.splashtop.com’

127.0.0.1 ‘*.splashtop.eu’

# Network blocking Supremo

127.0.0.1 ‘*.nanosystems.it’

127.0.0.1 ‘*.supremocontrol.com’

# Network blocking tailscale

127.0.0.1 ‘*.tailscale.com’

127.0.0.1 ‘*.tailscale.io’

# Network blocking teamviewer

127.0.0.1 ‘*.teamviewer.com’

# Network blocking VSCodeTunnel

127.0.0.1 ‘*.tunnels.api.visualstudio.com’

127.0.0.1 ‘*.devtunnels.ms’

# Network blocking ZohoAssist

127.0.0.1 ‘*.zoho.com’

127.0.0.1 ‘*.zoho.eu’

127.0.0.1 ‘*.zoho.in’

127.0.0.1 ‘*.zoho.com.au’

127.0.0.1 ‘*.zoho.com.cn’

127.0.0.1 ‘*.zohoassist.com’

127.0.0.1 ‘*.zohoassist.jp’

127.0.0.1 ‘*.zohoassist.com.cn’

127.0.0.1 downloads.zohodl.com.cn

127.0.0.1 downloads.zohocdn.com

127.0.0.1 gateway.zohoassist.com

# Network blocking ngrok

127.0.0.1 ‘*.ngrok-agent.com’

127.0.0.1 ‘update.equinox.io’

127.0.0.1 ‘tunnel.ngrok.com’

127.0.0.1 ‘tunnel.*.ngrok.com’