Money theft is one of the most important risks for any organization, regardless of its scope of activity. According to our data, 42% of cyberattacks on companies are committed to obtain direct financial benefits. You can detect an attack at various stages—from network penetration to the moment when attackers start withdrawing money. In this article, we will show how to detect an attack at each of its stages and minimize the risk, as well as analyze two common scenarios of such attacks: money theft manually using remote control programs and using special malware—a banking trojan.
Where to look for signs of the attack
Penetration into the company's network
Phishing emails
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.
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.
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\WindowsNT\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.
Attack on the web application
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.
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.
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
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.
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 0x6 "Client not found in Kerberos database" and 0x18 "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"
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.
For details on how to detect a password spraying attack in network traffic, see the full version of the research.
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. One of the most common ways to gain persistence on a host is to add a malicious executable file to the startup. 82% of APT-groups use this technique. Let's look at how to detect it using event logs and, in some cases, in network traffic.
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. Look for registry branches here.
Additionally, it is recommended to track Sysmon events with the ID 11 "File Create" 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.
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
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.
Search for system information
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:
Analyzing access rights of user groups
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.
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.
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.
Kerberoasting attack
With the help of the Kerberoasting attack, 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.
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.
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.
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. The method of detecting this technique using event logs and network traffic is contained in the full report (learn more).
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. Let's look at how to detect attempts to replicate credentials.
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
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.
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.
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.
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.
The final stage — 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.
Use of remote management software
Attackers can use various remote desktop access tools, including VNC technology: TightVNC, UltraVNC, RealVNC, and VNC Connect. The darknet sells modified versions of these programs that work unnoticed by the user. They 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.
The principle of operation of all products using VNC is very similar, so let's consider the behavior of TightVNC, since its source code is available. Let's look at how you can detect malicious activity for various remote control functions.
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.
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.
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 full research describes how to detect this malicious activity (read more).
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.
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.
You may find the whole text of the research here. Other Positive Technologies' studies are available in the Knowledge base on our website.
Author: Ekaterina Kilyusheva
