Social Engineering Overload

Attacker Combines Spam Flooding, Vishing, and Other Steps in Single, Successful Attack

Credential Theft – Spam Flooding – Voice Phishing (Vishing) – Windows Quick Assist Abuse – Batch Script – Finance and Insurance

An attacker flooded a financial services organization’s inboxes with spam emails, then called the recipients to install remote monitoring and management solutions and steal credentials.

This attack exposes companies to severe repercussions from the direct theft of credentials that could lead to the leakage of sensitive information. This could devastate competitive standing and personal security and result in substantial financial, operational, and reputational damages that necessitate costly long-term recovery and security overhauls. This attack underscores the urgent need for robust, multi-layered cybersecurity measures.

Detailed Observations

A financial services organization contacted the Deepwatch Adversary Tactics and Intelligence team to investigate the suspicious activity. During this “zero-to-retainer” engagement, the Adversary Response team observed an attacker targeting finance department users in a spam flood email campaign. These emails came from various domains and were in different languages and the users received around 300 emails in 30 minutes. 

The attacker then called the users directly, posing as a legitimate IT help desk support employee from the organization. The attacker called from an 888 toll-free number block, which often can be spoofed. The attacker told the users they observed the spam behavior and wanted to connect to the user’s machine to fix the issue. The attacker then requested the user to open Microsoft Quick Assist and gave them a special code to establish the remote help session. 

From there, the attacker attempted to download a ZIP file (s.zip) using a curl command. The ZIP contained two files: filtersinstall.dat and s.tar. The file filtersinstall.dat is a batch script that performs several actions to create an SSH backdoor. First, it runs the OpenSSH server executable (sshd.exe), stored in the second file s.tar. Next, it adds an authorized public key (authorized_keys), allowing SSH access only to the attacker(s), as they have the private key. A detailed technical analysis of the ZIP file can be found later in this report. 

Then, two SSH tunnels are opened via sshd.exe. The first allows the attacker’s remote server to connect to the tunneled local port on the victim host machine (port 22000). This enables the attacker to access the machine over the SSH tunnel. The second tunnel is opened for file transfer via Secure Copy command (SCP) from the victim host machine to the “store/“ path in the attacker-controlled remote server’s directory. 

Next, to capture the user’s password, the user is prompted to input credentials via the PowerShell cmdlet Read-Host. The attacker then saves the input as a secure string in a file. This file, containing the entered password and other information like the username and domain belonging to the victim, is then transferred via SCP to the attacker(s). 

The script also displays messages to deceive the victim into believing “spam filters” and “updates” are being installed when, in fact, their account password and domain info are being stolen from them. 

The attacker also used the reg.exe utility to add an HKCU RUN startup entry so the tunnels and SSH server persist across reboots. 

Recommendations

User Awareness Training

End users often overlook Social Engineering attacks due to their lack of knowledge when dealing with these scenarios.

• Educate users of this social engineering attack that includes spam flooding with a help desk-initiated call
• Recommend end users to call the help desk back at the internally documented phone number vs assuming it’s the help desk or internal personnel when getting called to troubleshoot their system.

Blocking Quick Assist

If your organization does not utilize Quick Assist, you can block access to Quick Assist in several ways.

• Utilize AppLocker to prevent unauthorized applications from running.
• To disable Quick Assist, block traffic to the https://remoteassistance.support.services.microsoft.com endpoint. This is the primary endpoint used by Quick Assist to establish a session, and once blocked, Quick Assist can’t be used to get help or help someone.
• Uninstall via PowerShell
  • Run the following PowerShell command as Administrator: Remove-AppxPackage -Package MicrosoftCorporationII.QuickAssist_2.0.30.0_x64__8wekyb3d8bbwe -AllUsers

• Uninstall via Windows Settings
  • Navigate to Settings > Apps > Installed apps > Quick Assist > Select the ellipsis (…), then select Uninstall.

Reference: https://learn.microsoft.com/en-us/windows/client-management/client-tools/quick-assist

Recommended Steps

• Disable the user first and conduct the following actions:
  • Reset password
  • Reset MFA
  • Revoke session tokens
  • Check whether any devices, such as recent phones, have been added to the user’s account.
    • Check for phone downgrades 
  • Check for applications being added to the user’s account via Azure.
• Isolate the host machine via EDR isolation
  • Check for persistence mechanisms commonly found, such as:
    • Scheduled Task
    • Run Once Registry Keys 
    • Auto start services
  • Look for evidence of execution
    • Prefetch
    • Windows BAM
  • Check temp directories for single-character files

Hunting 

Hunting for anomalous command line usage of curl.

• KQL (Kusto Query Language)
• DeviceProcessEvents
  • | where ProcessCommandLine has “curl”
  • | where ProcessCommandLine !contains “expected_normal_usage_pattern” // Replace this with common benign patterns
  • | project Timestamp, DeviceName, UserName, ProcessCommandLine, InitiatingProcessCommandLine
• SPL (Splunk Search Processing Language)
  • index=your_index_name “curl”
    • | search NOT [search index=your_index_name “curl expected_normal_usage_pattern” | fields _raw]
    • | table _time, host, user, CommandLine

*Would require endpoint telemetry such as 4688 with Command line audit enabled

• PowerQuery (Sentinel 1)
  • event.type = ‘Process Creation’ src.process.name contains:anycase “curl” tgt.process.cmdline contains:anycase “.zip”

|columns event.time, endpoint.name, src,process.user, src.process.name, src.process.cmdline

• CSQL(CrowdStrike Query Language)
  • #event_simpleName=ProcessRollup2 event_platform=Win ImageFileName=/curl/i
    • | CommandLine=/\.zip/i
    • | groupBy(CommandLine, function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(SHA256HashData)]))
• In this case, the threat actors used curl to download a zip file

Looking for single-character zip file names in the user’s download folders.

• KQL (Kusto Query Language)
• SPL (Splunk Search Processing Language)
  • index=your_index_name “Downloads” FileName=”?.zip” | rex field=FileName “^(?<SingleCharFileName>[^\\]*)\\.zip$”| where match(SingleCharFileName, “^[^\\]$”) | table _time, host, user, FileName, FilePath
• CSQL(CrowdStrike Query Language)
  • #event_simpleName=ZipFileWritten
    • | FileName=/(^s\.zip$|^a\.zip$|^a3\.zip$)/i
• PowerQuery (Sentinel 1)
  • event.type = ‘File Creation’ src.process.cmdline matches:anycase ‘(s.zip|a.zip|a3.zip)’
    |columns event.time, endpoint.name, src,process.user, src.process.name, src.process.cmdline
• FileEvents
  • | where FolderPath has @”\Downloads\” and FileName matches regex “^[^\\]*\.zip$” and strlen(tostring(split(FileName, ‘.’)[0])) == 1
  • | project Timestamp, DeviceName, UserName, FileName, FolderPath

Look for abnormal reg.exe activity for HCKU RUN start-up entry.

• KQL (Kusto Query Language)
• SPL (Splunk Search Processing Language)
  • index=your_index_name “reg.exe” “HKCU” “RUN”
    • | search (CommandLine=”* add *” OR CommandLine=”* delete *”)
    • | table _time, host, user, CommandLine
• CSQL(CrowdStrike Query Language)
  • #event_simpleName=ProcessRollup2 event_platform=Win ImageFileName=/reg/i
    • | CommandLine=/add.*HKCU.*(runtimebroker|runtimebroker_connect)/i
    • | groupBy(CommandLine, function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(SHA256HashData)]))

Look for SSH traffic over port 22000.

• KQL (Kusto Query Language)
• SPL (Splunk Search Processing Language)
  • index=your_network_traffic_index “SSH” TCP port=22000
    • | table _time, src_ip, dest_ip, src_port, dest_port, user
• CSQL(CrowdStrike Query Language)
  • #event_simpleName=NetworkConnect*
    • | RemotePort=22000
    • | Protocol=6
    • | groupBy(ContextBaseFileName, function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(SHA256HashData), collect([RemoteIP])]))

Look for anomalous SCP usage.

• KQL (Kusto Query Language)
• SPL (Splunk Search Processing Language)
  • index=your_index_name “scp”
    • | search NOT [search index=your_index_name “scp expected_normal_usage_pattern” | fields _raw]
    • | table _time, host, user, CommandLine
• CSQL(CrowdStrike Query Language)
  • #event_simpleName=ProcessRollup2 event_platform=Win ImageFileName=/scp/i
    • | CommandLine=/\.zip/i
    • | groupBy(CommandLine, function=([count(aid, distinct=true, as=uniqueEndpoints), count(aid, as=totalExecutions), collect(SHA256HashData)]))
• DeviceProcessEvents
  • | where ProcessCommandLine has “reg.exe” and ProcessCommandLine has “HKCU” and ProcessCommandLine has “RUN”
  • | where ProcessCommandLine contains “add” or ProcessCommandLine contains “delete”
  • | project Timestamp, DeviceName, UserName, ProcessCommandLine, InitiatingProcessCommandLine
• NetworkCommunicationEvents
  • | where RemotePort == 22000 and Protocol == “TCP”
  • | where ApplicationProtocol == “SSH”
  • | project Timestamp, DeviceName, UserName, RemoteIpAddress, RemotePort, LocalIpAddress, LocalPort
• DeviceProcessEvents
  • | where ProcessCommandLine has “scp”
  • | where ProcessCommandLine !contains “expected_normal_usage_pattern” // Replace with common benign patterns
  • | project Timestamp, DeviceName, UserName, ProcessCommandLine, InitiatingProcessCommandLine

Related Activity

The activity observed by the Adversary Response team is very similar to the activity reported after our investigation was completed. A suspected Black Basta affiliate overwhelmed companies’ emails with spam, setting the stage for direct phone scams, with attackers posing as IT support to install remote computer access. 

Once the attacker successfully accessed the system, they sent and executed batch scripts disguised as system updates. The first script checks the connection to their command and control (C2) server and downloads a zip file containing OpenSSH, RSA keys, and SSH configs.

The script establishes persistence by running key entries in the Windows registry that point to additional batch scripts. Each executes SSH via PowerShell to establish a reverse shell connection. However, some variations also conditionally establish persistence using other remote monitoring and management solutions.

 All scripts stole user credentials via PowerShell, posing as system updates needing login details. Most directly send stolen credentials to the attacker’s server via SCP. Some scripts archive credentials for later retrieval. 

In one case, attackers used the NetSupport RAT, deployed a tampered DLL named 7z.dll to multiple network assets, and executed a Cobalt Strike beacon from an altered 7zG.exe. Despite these activities, these attackers have reported no data theft or ransomware deployment.

Observables

Type	Indicator	Description
Domain	chat.youtube-busines[x]com	Domain observed in HTTPS Certificate for IP address 91.90.195[x]52
Domain	watotomemphis[x]com	Domain observed in HTTPS Certificate for IP address 195.123.233[x]42
Domain	upd9a[x]com	Zip Download domain
IP	195.123.233[x]42	IP Address in batch file
IP	91.90.195[x]52	IP Address in batch file
IP	20.115.96[x]90	IP Address in batch file
Hash of filtersinstall.dat	5327f4819e7671fb25d574a5970c6c1356993a8b7c26cc826b31a599f5cc4ab0	File that contain batch commands
Hash of s.tar	246209b9c737d6a35c9ccce1cdc23592023e212d5fbc0c0d6e34f24387d0edad	Compressed file containing additional configuration files and SSH backdoor
Hash of sshd.exe	6f31cf7a11189c683d8455180b4ee6a60781d2e3f3aadf3ecc86f578d480cfa9	SSHD Program

Appendix

Malware Analysis 

Family Name/Classification: SSH backdoor

Entry Vector: Spam flooding with Vishing?

Capabilities: Backdoor over SSH, Windows account credential theft

Analysis of “s.zip”

The file in question contains two files, “filtersinstall.dat” and “s.tar”. While the extension for the first file is “.dat”, it is actually a batch file, i.e. “.bat”. Upon analyzing the first file, some variables are initialized later within the script, where the “IPS” variable contains the IP addresses corresponding to attacker-controlled remote servers.

The batch script then untars the s.tar file, which contains dependencies used later within the script. This is followed by using the Windows utility cacls to give full control of the “ida_rsa_client” file, which is a private key. Next, one of the three remote servers mentioned above is used in an argument with the SCP utility, using the private key for authentication with the attacker-controlled servers by attempting to download a file named “test.txt”. If the download is successful, the test file is deleted, and the server is considered valid and will be used for the remainder of the script.

The next behavior exhibited by the script involves moving files previously untarred into their respective file/folders, as described in Figure 1. As before, permissions are also set for the files using the Windows utility cacls. A majority of the files are moved to %LOCALAPPDATA%\RuntimeBroker, which serves as the main directory. The “authorized_keys” file contains a public key used by the attacker(s) for SSH access into the victim machine.

The script then creates several batch files. Please refer to Figure 1 for the file names corresponding to the variables included in the figure.

The file runtimebroker.bat AKA %BAT1% is created and serves to start the OpenSSH server by executing sshd.exe AKA %MAINEXE% and passes the path to the SSH configuration file (sshd_config) and host key (id_rsa) that was previously extracted from s.tar.

The file runtimebroker_connect.bat AKA %BAT2% is then created and contains two lines for starting two other batch files that are created immediately after.

The first batch file, runtimebroker_connect_a.bat serves to create an SSH tunnel with the OpenSSH server running on port 22000 on %LISTEN_PORT% (first argument to the script) and uses the private key “id_rsa_client” for authentication. This is performed to allow SSH access from the attacker’s remote server.

The second batch file, runtimebroker_connect_b.bat serves to create an SSH tunnel with the attacker’s remote server on the local port %LISTEN_PORT% + 1 (first argument to the script) and uses the same aforementioned private key. This is performed as a prerequisite to allow copying of a file containing harvested Windows credentials to the attacker’s remote server.

The Windows utility reg.exe is then used to make registry entries to ensure the aforementioned batch files are started across reboots. Next, the batch files are started, and finally, s.zip and s.tar are deleted.

The next behavior of the script involves calling the function “DownloadSpamFilters”. The purpose of this function is to social engineer the victim and simply echo a message to the victim and run the ping utility to make it look like the script is doing something. The contents of this function are as follows.

The victim’s credentials are socially engineered next, where the script prints a message claiming that the victim needs to enter their password to “update spam filters”. This password is then concatenated with the victim’s domain, username, and computer name into a new .txt file and scp is used to transfer the file through the secure tunnel opened earlier, to the attacker’s server in the directory “store/”.

After another bogus function is called that claims “spam filters” were installed, the message “Password is incorrect” is then printed to the user and asks for the password again and scp is used again to copy the second entered password and other domain information to the attacker’s server. It is highly likely the attacker(s) are collecting the password twice simply for consistency, in the event the victim accidentally used the wrong password first.

The remaining commands within the script simply serve to exit and delete the batch script (installfilters.dat).

↑