How to detect a cyberattack and prevent money theft

Contents

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.

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.

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 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.

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.

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

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.

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.

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.

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.

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 0x40 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.