Business risks and hacker attacks
Each company has a certain list of business risks that can negatively affect its work and position in the market. Depending on the line of business, this may be, for example, the suspension of production processes, disruption of operations or damage to equipment, failure to fulfill contractual obligations, major financial losses, or leakage of sensitive information. Many of these risks can be a direct or indirect consequence of a cyberattack.
As a rule, the company's management understands exactly which business risks are unacceptable for the company. To become really effective, cybersecurity must be built with consideration to these risks. It is important to understand which business systems to focus on first. To do this, you need to know how an attack that may lead to triggering particular risks will develop: then you can identify components of the infrastructure that are the most important for the business and determine the necessary means of protection and approaches to detecting attacks.
In this report, we will look at one of the most important risks for any organization, regardless of its scope of activity—money theft. According to our data, 42% of cyberattacks on companies are committed to obtain direct financial benefits. There are many scenarios of such attacks; we will analyze two common ones: money theft manually using remote control programs and using special malware—a banking trojan. We will show you how to detect an attack at each of its stages and minimize the risk.
Attack scenario
Let's outline one of the possible attack scenarios. Each stage will consist of techniques that, according to our estimates, are very likely to be used by attackers. Some techniques are successfully used in penetration tests and do not attract the attention of cybersecurity specialists. At certain stages, such as the stage of penetration into the infrastructure, we will provide several scenarios of the attack development since they seem to be of equal value to us and are often used by cybercriminals.
Both an external intruder and an insider can attack a company. In the second case, the attacker is already in the infrastructure, so there will be no penetration stage, and the starting point will depend on the privileges available. If an employee of the company is not familiar with the exact structure of the network and does not work with financial systems, then they will start an attack with reconnaissance, just like an external intruder.
Penetration into the company's network
Let's look at three most often used techniques of penetration into the company's infrastructure.
Most often, attackers get into the local network by sending phishing emails with malicious attachments. According to our data, this is how 9 out of 10 APT groups start their attack.
Another common method of hacking is to exploit a vulnerability in a web application on the company's perimeter. The results of pentesting projects conducted by our experts show that in 86% of companies there is at least one way to get into the internal network through a vulnerable web application.
The third method is bruteforcing credentials to the services available on the perimeter. If an attacker tries to bruteforce passwords to one account, such an attack will quickly be noticed, and the account will be blocked. Therefore, criminals are more likely to resort to Password Spraying—an attack in which accounts are matched against one common password.
Persistence
When attackers are able to execute commands on the system, they need to gain persistence in order to have permanent access to the infrastructure. We will look at one of the popular techniques, which implies ensuring the automatic execution of payload. Then, when the computer is restarted, the malicious file will be run again, and the file can be disguised as legitimate and its presence will not cause suspicion. This technique is very common among APT-groups: 82% of groups use it.
Collecting infrastructure data
The attackers need to understand where they are on the infrastructure, which hosts are of interest, and how to get to them. In our scenario, when the goal is money theft, the computers with access to financial systems will be points of interest for the attackers. Therefore, criminals conduct reconnaissance: they check which hosts are available, obtain the address of the domain controller and a list of administrators; find out what privileges they currently have, and in which groups the user on whose behalf they execute commands belongs to. In addition, the attackers need to know what system they are working with, for example, by getting the OS version and a list of running processes.
Attack development on the internal network
To connect to different infrastructure hosts (servers and workstations), you need to know user passwords or password hashes, or have a corresponding Kerberos ticket. In modern versions of Windows, there are mechanisms that, if configured correctly, prevent password hashes from being retrieved from the OS memory, but there are other methods, including the Kerberoasting attack. With its help, an attacker can obtain the passwords of service accounts, which are often privileged. Any domain user can request a Kerberos ticket to access the service, and such a request will be considered legitimate. To encrypt the ticket, a hash of the service account password is used, and an attacker can try to decrypt it offline by bruteforcing the password. This technique is also widely applied in penetration testing: it is successfully used in 61% of projects.
Knowing the password or the hash of the user password, an attacker can connect to the computer using shared administrative resources, such as C$, ADMIN$, IPC$. This technique (Remote Services: SMB/Windows Admin Shares) is used both to transfer the executable file and to start the service.
Gaining control over the infrastructure
As a rule, a fraudulent operation does not require full control over the infrastructure. However, the maximum privileges allow attackers to move freely between computers, so it is likely that they will try to get the KRBTGT account. The privileges of this account allow them to create Kerberos tickets to access any resources with maximum privileges. Known attack methods such as creating a memory dump of the lsass.exe process or copying the ntds.dit file is quite noticeable for security tools, so let's consider another method that is not so easy to detect—this is the replication of accounts to a fake domain controller (DCSync attack).
Access to financial systems
Having obtained the privileges of the KRBTGT account in the previous step, an attacker can generate a Kerberos ticket to access those computers that work with financial systems, for example, the computer of an accounting employee. Such an attack is called a Golden Ticket.
Money theft
There are special banking Trojans that can automatically spoof payment details. In the last few years, the RTM Trojan has been widely used in attacks. In addition, an attacker can perform a fraudulent operation manually, keeping track of the workflow and actions of the company employees. For this purpose, they install malware for remote management on computers. The dark web sells modified versions of popular legitimate products, such as TeamViewer or VNC, that work unnoticed by the user. Such programs allow attackers to spy on users, take screenshots, record videos, and intercept keyboard input. After collecting a sufficient amount of information, an attacker can connect to a computer and independently make a payment or spoof payment details.
How to detect an attack
You can detect an attack at various stages—from network penetration to the moment when attackers start withdrawing money. Let's look at how to identify the techniques listed in the previous section and where to look for signs of the presence of attackers.
At the penetration stage
Phishing emails
In most cases, a document of .doc, .docx, .xls, or .xlsx extensions with one of the payload types is used in phishing emails:
- VBA or Excel 4.0 macro
- Exploit for a vulnerability in a Microsoft Office component, such as CVE-2017-0199, CVE-2017-11882, CVE-2018-0802.
Before running the document, you should first perform a static analysis, which can show whether the file is malicious. There are quite a lot of approaches to detection: using exact hash sums of the file (MD5, SHA1, SHA256) and using more flexible hash sums, such as SSDEEP. In the simplest case, you can find ASCII and Unicode strings in the file. But the most reliable will be the analysis of code fragments, during which you can identify the characteristic sequence of operations and encryption features.
MITRE ATT&CK techniques
Phishing: Spearphishing Attachment (T1566.001)
Where to look for signs of the attack
Attachments received by email
Network traffic
Windows security event log
General approach to detection
Perform static analysis of files before launching.
Use special solutions to analyze the behavior of files in a virtual environment (sandbox).
However, static analysis does not always help detect suspicious files. A more reliable way is to run the file in a sandbox, where its behavior is analyzed.
As a result of launching a malicious file, a subprocess is usually created in the context of an office application. Calls to create a new process in user space, such as CreateProcessA or CreateProcessW, are intercepted at the kernel level by calling NtCreateUserProcess or NtCreateProcessEx. But launching a process with a malicious payload can take place in other ways:
- Creating a task in the task scheduler. As a rule, the fact of creating a task can be detected with the help of several characteristic actions.
First, it is the creation of additional keys in the registry branch HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree with the task properties. Second, it can be done with the help of the new task files in the directories C:\Windows\Tasks and C:\Windows\System32\Tasks. Third, it is the appearance of entries about the creation of a scheduled task in the event logs (events with the ID 4698). Moreover, you can not only create a task, but also change an existing one, in this case, the events in the log will have the ID 4702.
There is another technique: to track access to the COM interface 0F87369F-A4E5-4CFC-BD3E-73E6154572DD and interaction with it, because this is what schtasks.exe, the standard Windows utility for creating tasks in the console, does, for example. It is often used by attackers.
- Creating a service. The fact of creating a new service can be detected by the appearance of additional keys in the registry branches HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\ROOT\LEGACY_*. In the Windows event logs, the creation of the service will correspond to entries with the ID 4697 or 7045. In addition, you can track the RPC call to the interface 367ABB81-9844-35F1-AD32-98F038001003 of the RPC server \PIPE\svcctl.
- Autorun via the startup directory or registry. In the first case, this is a file entry in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup or %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup directories. The second one contains the registry keys HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, and others (the identification of this technique is discussed in detail in the Persistence section).
New files in the system and the memory of the created processes also need to be scanned for malicious code.
Before launching the payload, intermediate actions of various types can be performed, which should attract attention, for example:
- Collecting system information by reading the values of registry keys, such as the key HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor to get information about the processor.
- Launching the PowerShell process.
- Escalating privileges by using various techniques. For example, the Search Order Hijacking DLL, which can be implemented as follows. The malware creates a Windows system directory, but with a space in the name. A legitimate executable file with the autoElevate option in the manifest and a fake DLL are copied to this directory. When you run the file, it checks whether it can actually be allowed to run it without checking the UAC, but the space in the directory name is not taken into account. As a result, the attacker's library will be loaded, and the malicious code will be executed with maximum privileges.
The process of downloading additional malicious modules can be specific, so studying the network traffic generated when running the analyzed file also makes it possible to identify some samples of malware.
Attack on the web application
When trying to hack into a company network, attackers can exploit vulnerabilities in publicly available web applications. Such attacks can be detected both in network traffic and in event logs
Detection using event logs
It is necessary to track suspicious process launches using Windows security event log events with the ID 4688 or Sysmon log events with the ID 1. For example, running the cmd.exe command line, whose parent process is w3wp.exe (OWA service) will be suspicious. You should also monitor the creation of new processes on behalf of the user who started the process responsible for the operation of the attacked service.
The successful exploitation of the vulnerability and uploading of the web shell can be indicated by the events of creating files with certain extensions, for example .asmx, .jsp, .php, and .aspx in the file directories of running services.
MITRE ATT&CK techniques
Exploit Public-Facing Application (T1190)
Where to look for signs of the attack
Windows security event log
Sysmon agent log
Network traffic
General approach to detection
Track known techniques for exploiting vulnerabilities.
Track suspicious activity to detect unknown exploits.
Detection using network traffic
Network traffic analysis allows you to identify known techniques for exploiting vulnerabilities (for example, Path Traversal) or signs of using specific exploits.
To detect the exploitation of unknown vulnerabilities, you need to monitor suspicious activity, for example, the presence of console utility launch strings or console utility data output patterns in the traffic. Such traffic may indicate the use of a web shell, which is often the next step after successfully exploiting a vulnerability. Another anomaly may be multiple requests containing incorrect data originating from a limited number of external addresses.
Password spraying for available services
Detection using event logs
A password spraying attack can be detected by monitoring the event logs. To do this, you need to track the following events in the security event log:
- 4625 "An account failed to log on" from hosts having services installed that are available on the network perimeter, such as OWA
- 4771 "Kerberos pre-authentication failed" with the error code 0×6 "Client not found in Kerberos database" and 0×18 "Pre-authentication information was invalid"
- 4776 "The computer attempted to validate the credentials for an account" in the case of NTLM authentication, with error codes C0000064 "Username does not exist" and C000006A "Username correct but password invalid"
MITRE ATT&CK techniques
Valid Accounts (T1078)
External Remote Services (T1133)
Where to look for signs of the attack
Windows security event log
Network traffic
General approach to detection
Detect frequent authentication attempts under different accounts, but with the same password.
For events 4625, it is possible to detect the address from which the password spraying attack is carried out, so the detection logic is based on searching for multiple triggers from the same IP address, but for different users. Events 4776 and 4771 appear on the domain controller and will have the addresses of the hosts where the services are located as the source address. In this case, you need to track multiple failed authentication attempts with different accounts over a certain period of time, such as 30 seconds.
Detection using network traffic
To detect an attack in traffic, you need to clearly distinguish between the sources of authentication requests and the names of the accounts used. Usually, such an attack generates a large number of unsuccessful authentication attempts. To clearly state that multiple failed authentication attempts are a password spraying attack, you either need to see the password in the traffic, or in some other way understand that a fixed password is used in different requests. An attack can be detected with high accuracy if authentication options are used, in which the password is transmitted in cleartext, for example:
- Basic-authentication, when a username and password are passed in the HTTP request headers
- LDAP cleartext authentication, when a username and password pair are passed over the LDAP protocol
But most often, passwords are not passed in cleartext, so you can pay attention to the following signs of password spraying:
- Very frequent (from one to ten requests per second) failed authentication attempts from the same address, but with different account names
- Rarer authentication attempts (for example, one request every 5–10 seconds), but with a fixed interval between requests and different account names
The presence of sessions with the KDC_ERR_C_PRINCIPAL_UNKNOWN error with different accounts in the traffic may indicate that the usernames are being bruteforced.
The traffic will contain Kerberos errors and traces of login attempts using bruteforced credentials. Error-free sessions with successful AS_REP responses, combined with issued tickets, show which accounts have been bruteforced.
Persistence
One of the most common ways to gain persistence on a host is to add a malicious executable file to the startup. Let's look at how to detect it using event logs and, in some cases, in network traffic.
MITRE ATT&CK techniques
Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1078)
Where to look for signs of the attack
Sysmon agent log
Network traffic
General approach to detection
Control over changing some registry keys and creating files in directories
Detection using event logs
In the Sysmon logs, you need to track the addition or modification of registry keys and their values using events 12 "RegistryEvent (Object create and delete)" and 13 "RegistryEvent (Value Set)" for certain registry branches associated with the startup function.
Registry Branches
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserShell Folders
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserShell Folders
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
- HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows
Additionally, it is recommended to track Sysmon events with the ID 11 "FileCreate" in the directory C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp and check files with the extension .lnk, .vbs, .js,. cmd,. com,. bat, or. exe.
Detection using network traffic
The technique in question is not reflected in network traffic if the actions are performed locally on the host. However, it is possible to imagine a situation in which attackers perform manipulations remotely. For example, using WINREG (Windows Remote Registry Protocol) access to a remote registry, attackers add a value to the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Also, if they have the appropriate access rights, they can copy the file over the SMB protocol. For example, when copying an executable file or a BAT file with command interpreter instructions to a folder C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp, the operating system will automatically launch such a file when any user logs in.
Collecting infrastructure data
During reconnaissance, attackers will have to use many techniques from Discovery tactics. Let's look at the methods of detecting two techniques that will definitely be used—obtaining information about the system (System Information Discovery) and about user groups (Permission Groups Discovery).
Search for system information
Detection using event logs
The application of the System Information Discovery technique can be detected using the security and PowerShell event logs in Windows, as well as using the Sysmon log. You need to detect the following events:
- Starting processes:
net.exe или net1.exe с командой config,
wmic.exe с командами os, qfe,
win32_quickfixengineering,
win32_operatingsystem;
systeminfo.exe,
ipconfig.exe,
netstat.exe,
arp.exe,
reg.exe; - Reading the \Software\Microsoft\ Windows\CurrentVersion registry key
- Running PowerShell commands, including for WMI queries that allow obtaining information about the system
Analyzing access rights of user groups
Detection using event logs
A sign of using the Permission Groups Discovery technique on the local host is starting the process net.exe or net1.exe with the localgroup, group /domain, or group /dom commands. In the security event log, the process startup events have the ID 4688, and in Sysmon the ID 1.
Detection using network traffic
It is possible to identify the technique in the network traffic by tracking the corresponding requests. To obtain information about groups, you can use the network protocols LDAP, SAMR. In the case of LDAP, the searchRequest requests and their filter field are primarily interesting for detection. A request can be used to list all the groups:
The memberof keyword is often used to list the members of a particular group. For example, the following figure lists the members of the domain administrators group.
In the case of the SAMR protocol, the operations QueryDisplayInfo, QueryDisplayInfo2, QueryDisplayInfo3, QueryGroupInfo, and QueryGroupMember can be used. They allow you to list groups, obtain information about them, and list members.
Attack development on the internal network
MITRE ATT&CK techniques
Steal or Forge Kerberos Tickets: Kerberoasting (T1558.003)
Where to look for signs of the attack
Windows security event log of the domain controller
Network traffic
General approach to detection
Since the stages of this attack are similar to the legitimate behavior of users on the domain infrastructure, you can detect such attacks by profiling the events of service ticket requests: to which credentials the request was made and from which IP address.
You should analyze the encryption algorithm in TGS ticket requests. The use of the RC4 algorithm is one of the signs of a Kerberoasting attack.
Kerberoasting attack
Detection using event logs
In the event logs, you need to detect anomalies in TGS ticket requests (event 4769 "A Kerberos service ticket was requested"): analyze all accounts and IP addresses from which a request to the service was made and check whether an account usually requests a TGS ticket to the analyzed service from the same IP address.
You also need to check the encryption algorithm in the requests: use of the RC4 algorithm is one of the signs of a Kerberoasting attack.
Detection using network traffic
In network traffic, you need to capture requests for listing services in Active Directory that can become targets for an attack. This stage is necessary for attackers to select a service to attack, and precedes the request for a TGS ticket and the bruteforcing of a password offline. You can list services, for example, using LDAP and the servicePrincipalName keyword in the filter field.
In this case, the enabled user accounts are requested.
You can also use the approach described above to profile TGS ticket requests and identify requests encrypted with the RC4 algorithm.
SMB/Windows shared administrative resources
Shared administrative resources such as C$, ADMIN$, and IPC$ can be used by an attacker to remotely access the system. This technique is used both to transfer a file and to run a service on a remote computer.
MITRE ATT&CK techniques
Remote Services: SMB/Windows Admin Shares (T1021.002)
Where to look for signs of the attack
Windows security event log
Network traffic
General approach to detection
In event logs and network traffic, you should analyze accesses to shared administrative resources. In the event logs, you should also analyze the facts of starting processes and registering services.
Detection using event logs
To detect attacker actions, it is necessary to analyze events that indicate the facts of access to shared administrative resources and the launch of processes:
- 4624 "An account was successfully logged on"
- 5140 and 5145—events of access to network share objects
- 7045 "A service was installed in the system"
- 4688 "A new process has been created", where the name of the parent process is services.exe When using smbexec, the service is created not in the system directory, and further commands are executed via services.exe.
Detection using network traffic
To detect work with files, you need to monitor network accesses to shared administrative resources. Monitoring of requests using the SVCCTL protocol allows you to detect work with services. For example, the CreateServiceW request is used to create services, and StartServiceW is used to start them, and the commands themselves are passed in the Binary Path Name field.
Gaining control over the infrastructure
After obtaining a password or a hash of the domain administrator password, attackers can replicate the KRBTGT account from the domain controller, for example, using the secretsdump utility. The privileges of this account will allow them to create Kerberos tickets to access any computer in the domain. Let's look at how to detect attempts to replicate credentials.
MITRE ATT&CK techniques
OS Credential Dumping: DCSync (T1003.006)
Where to look for signs of the attack
Windows security event log of the domain controller
Network traffic
General approach to detection
In the event logs, you should track obtaining of privileges that are required to replicate the credentials from a domain controller.
In network traffic, you should detect replication requests that do not originate from a domain controller.
Detection using event logs
The DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, and DS-Replication-Get-Changes-In-Filtered-Set privileges are required to replicate credentials from a domain controller.
In the security event log on domain controllers, in events with the ID 4662 "An operation was performed on an object", you need to track these privileges, and to detect the source of the attack, you need to match these events with the event 4624 "An account was successfully logged on", which will have the same login ID.
Detection using network traffic
When specifying the -just-dc-user key, the secretsdump utility uses the DCSync technique to obtain domain credentials. The attack consists in the fact that the host controlled by the attacker is represented by a domain controller and requests replication of the credentials of specific users.
Domain controllers use the Directory Replication Service (DRS) Remote Protocol for replication, or rather calls to the RPC interface that implements this protocol—DRSUAPI RPC interface. This interface has the DRSGetNCChanges method, which calls replication. If such calls come from a computer that is not a domain controller, then this is a clear sign of a DCSync attack.
Access to financial systems
The next step of the attack after obtaining the KRBTGT account is to create a Kerberos ticket to connect to any domain resources with maximum privileges, or a Kerberos Golden Ticket attack.
MITRE ATT&CK techniques
Use Alternate Authentication Material: Pass the Ticket (T1550.003)
Where to look for signs of the attack
Windows security event log of the domain controller
Network traffic
General approach to detection
The activity during the Golden Ticket attack differs from the legitimate scenario of using Kerberos tickets in Active Directory: there is no process for obtaining a TGT ticket. A common approach to detecting an attack is to detect the use of tickets that were not issued by the domain controller.
Detection using event logs
You need to look for anomalies in the DOMAIN ACCOUNT field in events with the following IDs:
- 4624 "An account was successfully logged on"
- 4634 "An account was logged off"
- 4672 "Special privileges assigned to new logon"
Some utilities for the Golden Ticket attack may incorrectly enter values in this field: it may be empty or different from the domain name. You need to look at the type of encryption of the ticket: if RC4 is used, then this may be a sign of an attack. In addition, the Golden Ticket attack does not have any TGT ticket request events (Event ID 4769) from the user computer.
Detection using network traffic
In a legitimate Kerberos protocol scenario, the user must receive a TGT ticket during initial authentication. To do this, it sends an AS-REQ request to the domain controller, which returns the TGT in the body of the AS-REP response. The user can then request access to domain services. To authenticate to the service, you need a TGS ticket. To obtain it, the user sends a TGS-REQ request to the domain controller in which they put their TGT ticket. The server sends a TGS-REP response containing the requested TGS ticket.
Since the Golden Ticket attack involves creating a TGT ticket outside the domain controller, the AS-REQ/AS-REP steps will be omitted from the traffic, meaning a ticket that was not issued will be used. Therefore, the purpose of traffic analysis is to detect the use of tickets that were not issued by the domain controller.
Money theft
Use of remote management software
Attackers can use various remote desktop access tools, including VNC technology: TightVNC, UltraVNC, RealVNC, and VNC Connect. The dark web sells modified versions of these programs that work unnoticed by the user. The principle of operation of all products using VNC is very similar, so let's look at the behavior of TightVNC, since its source code is available.
In order to organize remote management using VNC, you need to provide the following functions:
- Interception of image changes on the target computer
- Injection of keyboard input on the target computer
- Injection of mouse clicks on the target computer
- Transfer of clipboard content
- Transfer of image frames and input commands over the network
Let's look at how you can detect malicious activity for each of the items.
Remote control function | Approach to detection |
Interception of image changes on the target computer | Tracking the installation of hooks (SetWindowsHookEx) and frequent screenshots (CreateCompatibleDC, CreateDIBSection, BitBlt, GetDIBits) |
Injection of keyboard input on the target computer | Tracking the installation of hooks (SetWindowsHookEx) on keystrokes, checking and assigning the status of pressed keys (GetKeyboardState, SetKeyboardState, GetAsyncKeyState) |
Injection of mouse clicks on the target computer | Tracking the acquisition (GetCursorPos) and assignment (SetCursorPos) of the cursor position, as well as the interception and processing of mouse clicks (SetWindowsHookEx) |
Transfer of clipboard content | Monitoring of reading (GetClipboardData) and writing (SetClipboardData) to the clipboard, the fact of changing the state of the clipboard by means of SetClipboardViewer |
Transfer of image frames and input commands over the network | The RFBprotocol is used to transfer data to the operator. In addition to the fact that the protocol can be characterized by the use of specified network interfaces (5900–5906), the packet format can also be described and detected by network signatures |
Use of banking trojans
Often, the purpose of banking trojans is to gain remote access to the e-banking or payment system. Therefore, common methods of stealing access are usually used, such as intercepting keystrokes, taking screenshots, writing data from the clipboard, or embedding it in browsers. But there are also specific techniques for this type of trojan, which should be discussed in more detail:
- Spoofing of bank details in the clipboard
- Spoofing of payment orders
- Modification of e-banking system files
- Theft of keys from payment systems and wallets
Spoofing of bank details in the clipboard
The method consists in monitoring the clipboard for the presence of payment details and their spoofing using the attacker's details. The Buhtrap ClipBanker trojan checks the contents of the clipboard for the presence of electronic or cryptocurrency wallets, and if detected, spoofs them. The list of this malware includes more than 30 names of wallets.
You can detect this behavior in the sandbox by copying the fake wallets of the most common payment systems to the clipboard, and then tracking the contents of the clipboard. You can also copy other data to the clipboard. Then, it is possible to determine with confidence this type of trojan by analyzing the nature of the changed data.
Spoofing of payment orders
In the CIS countries, the most widely used accounting system is 1C: Enterprise, which allows you to send payments to the bank using e-banking systems. The file 1c_to_kl.txt is used for transmitting payment data to the e-banking system. Attackers can make changes to this file to transfer money to their accounts, for example, this is how the RTM trojan works.
The file 1c_to_kl.txt is usually accessed by intercepting the CreateFile and WriteFile functions. The RTM module contains agents that intercept the WH_CBT event using the SetWindowsHookExA function to inject themselves in all processes, and then check if they are in one of the processes of 1C: Enterprise.
And if this is the case, then the trojan intercepts the CreateFileW and WriteFile functions, setting access to the first 0×40 bytes of each of the functions with the PAGE_EXECUTE_READWRITE memory protection parameter using the VirtualProtect function, and then overwriting them with its own code. You can detect the fact of event interception by tracking the call to VirtualProtect with the memory protection parameter PAGE_EXECUTE_READWRITE at the address indicating the CreateFileW or WriteFile functions. The detection of the SetWindowsHookExA hook installation call can also serve as an indirect indicator.
Modification of e-banking system files
This technique is used to bypass the self-protection of e-banking systems. An example is the BlueNoroff trojan, which modifies the modules of the SWIFT Alliance banking program in the memory to disable database verification and allow attackers to edit it. The trojan uses the VirtualProtectEx functions to allow writing to a code fragment, ReadProcessMemory to make sure that it changes the desired fragment, and WriteProcessMemory to overwrite the desired bytes.
You can detect the fact of modification of processes and files of e-banking systems. Calling VirtualProtectEx with the memory protection parameter PAGE_EXECUTE_READWRITE for e-banking processes is extremely suspicious, and, in combination with the call to WriteProcessMemory, it can serve as an indicator of changes in e-banking processes.
Theft of keys from payment systems and wallets
Some trojans steal private keys from payment systems and wallets: for example, Buhtrap ClipBanker steals keys from Electrum and Bitcoin wallets. It searches for these keys using the paths %appdata%\eLectrUm*\wAllEts\ and %appdata%\BiTcOin\wAllEts\walLet.dAt.
You can detect this behavior by accessing these paths. Usually, the file search is performed using the FindFirstFile and FindNextFile functions. In addition, you can track attempts to open files using CreateFileA by checking the paths to the files. In the sandbox, you can place dummy files in the appropriate paths, and then monitor access to them.
Detection of reconnaissance
Malware operators must understand that they have got to the right computer. This leads to another detection option—to detect the fact of collecting information that may relate to financial systems. Thus, it is possible to detect an attack even at the stage of reconnaissance or primary infection. Note that these methods are quite often implemented in additional modules or executed on a command from the management server, so it can be difficult to identify them in the sandbox.
Such indicators include, for example, the analysis of tabs and browser history. One of the RTM modules contains a large list of URL templates associated with different banks and payment systems. It searches for their occurrence in the addresses of tabs or browser history. Another module monitors open windows and tabs. You can detect the process of searching and monitoring tabs and browser history, but this will not allow you to understand what the data will be used for. To expressly identify this technique by behavior, you need to intercept the functions of work with strings, then you can find templates of the online.payment.ru form, even if they are encrypted.
Another indicator is the search for files related to e-banking systems. For example, the BlueNoroff module searches for certain SWIFT codes in the file passed to it, extracting information about the sender, recipient, account number, and application numbers. It is launched by another module that intercepts the CopyFileA function, so this behavior does not differ from the usual file search and does not allow you to clearly determine that this is a banking trojan. But in this case, malware can be detected by the presence of SWIFT-specific values in the file or memory dump: MOT, M95, M94, MMY, 25: Account Identification, 28C: Statement Number, :25:, :28C:.
Conclusions
The attacker actions can be detected at different stages, starting from the moment of initial penetration into the company network and up to the stage at which the money is stolen. In the course of their campaign, the attackers will have to use many techniques. In order to identify the attack as a whole, it is not necessary to identify all the techniques without exception, it is enough to notice any of its steps in time. However, the earlier the attacker actions are detected, the easier it is to prevent negative consequences.
An attack can affect various infrastructure hosts, but there are points where malicious activity is most likely to be detected—they must be under special control. First of all, these are the hosts where attackers get key privileges necessary for further advancement, for example, domain controllers. These are also workstations from which access to financial systems is possible. In general, the more infrastructure elements are under control, the higher the chances of detecting an attack at its early stages, but if only critical hosts are under control, the attack will be detected at its final stages. However, the longer path of the attacker from the point of penetration to the target system (for example, due to the correct network segmentation) provides additional opportunities for detecting an attack at an early stage.
Using different attack detection tools allows getting a more complete view of everything that happens on the network and tracking events in detail. An attack can consist of techniques that are detected using different tools, for example, some of them can be tracked using event logs, while for others, a more reliable method of detection will be the analysis of network traffic, and, in some cases, suspicious behavior will be detected in the sandbox.
Get in touch
will contact you shortly