Positive Technologies - learn and secure

PHDays 10 IDS Bypass contest: writeup and solutions

2021-08-09T08:01:00.004-07:00

For the second time, the IDS Bypass contest was held at the Positive Hack Days conference. Just like last time (see blog.ptsecurity.com/2019/07/ids-bypass-contest-at-phdays-writeup.html), the players were supposed not only to find flaws in the six services and capture the flags, but also bypass the IDS, which would interfere with them. Alert messages about the facts of triggering IDS rules were supposed to help in bypassing them. And as you know from the last competition, there can be infinitely many solutions to tasks. Here we go.

192.168.30.10—Apache Tomcat

On port 8080, we can see Apache Tomcat version 9.0.17. The first search for an exploit for this version should lead to CVE-2019-0232.

This task was intended as an introductory one and was supposed to be the simplest (although some of the other tasks turned out to be simpler). In the exploit, we see a test URL with the command /cgi/test.bat?&dir. But with such a request, it just freezes, and the player sees the IDS alert:

ATTACK [PTsecurity] Apache Tomcat RCE on Windows (CVE-2019-0232)

It was intended so that the players would modify the URL in the same way as they would do it to bypass the WAF. The regular expression in the rule looks like this: pcre: "/\.(?:bat|cmd)\?\&/U"; and soon the IDS would submit to the player. In addition, some exploits already have an example of a URL with a bypass, for example: http://localhost:8080/cgi/test.bat%20%20?&dir. As a result, many easily completed the task. We have taken a look at the contest, let's move on.

192.168.30.20—PHP Bypass

On the main page, we can see an offer to test the ls command. It warns us that it may not be working.

And, as expected—it is not working. There is a message in the log:

ATTACK [PTsecurity] file_name parameter possible command injection

You might think that in the task you have to exploit RCE and get the flag, but the idea was different. In the summer of 2019, an author under the pseudonym "@Menin_TheMiddle" published an article (secjuice.com/abusing-php-query-string-parser-bypass-ids-ips-waf) about the IDS and WAF bypass. It said that a number of characters in the name of the GET parameter the PHP interpreter leads to an underscore ("_"). Our IDS, unlike PHP, does not do this. For example, the author used one of the public IDS rules of our AttackDetection team. And since the crucial part of the Suricata rule looked like this: pcre: "/file_name\s*=\s*[a-zA-Z\.]*[^a-zA-Z\.]/U";it was possible to bypass it simply by replacing the file_name parameter with, say, file[name. Due to an error in the Suricata rule, you could get the flag simply by sending file_name=.

192.168.30.30—He said yes

We see a form and instructions on how to get that flag. It is enough to give a simple answer "yes" to the HTTP request.

The players started a web server on their nodes, answered "yes" to incoming requests and saw the following line in the logs:

JOKE [PTsecurity] Sometimes Positive Technologies hurts! No 'yes' allowed

The rule checked all HTTP responses and did not allow those with the "yes" string inside. The game host also accepted the "yes" string in lowercase only, and this task received the largest number of different solutions!

The idea was to redirect the incoming HTTP request to the HTTPS protocol and answer "yes" in the new request. For this vector, the allow_redirects=True and verify=False parameters were specially used in the requests library. The solution looked like this:

echo -ne "HTTP/1.1 302 Redirect\r\nLocation: https://10.8.0.2/hi_there\r\nContent-Length: 0\r\n\r\n" | sudo nc -nkvlp 80

echo -ne "HTTP/1.1 200 OK\r\nContent-Length: 3\r\nContent-Type: text/html\r\n\r\nyes" | sudo ncat -nvklp 443 –ssl

The player @vos used a hundredfold nested gzip compression for the HTTP response, and the player @webr0ck used zero filling of almost 2 megabytes in size before the "yes" string. In both cases, Suricata turned out to be powerless.

192.168.30.40—DCERPC

It was the most expensive task in the competition. The players were given the administrator account credentials and asked to show their knowledge of Windows protocols. To get the flag, it was necessary to extract the list of all the users on the device.

Those who are familiar with AD security can immediately think of the samrdump.py script from the impacket set, but the script addresses SMB port 445 that is closed on the host. The binding string in the script ncacn_np:*hostname*[\pipe\samr]is fixed and leads to the SMB pipe. In addition, of all open ports on the host, only port 135 is detected, the so-called Endpoint Mapper listens to it. EPM is responsible for resolving RPC interfaces.

Another script from the impacket set, rpcdump.py, uses EPM to obtain the list of currently active RPC interfaces.

> python rpcdump.py Administrator:TastesG00d@192.168.30.40

Protocol: [MS-SAMR]: Security Account Manager (SAM) Remote Protocol

Provider: samsrv.dll

UUID : 12345778-1234-ABCD-EF00-0123456789AC v1.0

Bindings:

ncacn_ip_tcp:192.168.30.40[49668]

ncacn_np:\\TASK4[\pipe\lsass]

Among all the interfaces, we can see the one we need, SAMR, which is responsible, among other things, for user management. Using the SAM interface, the samrdump.py script extracts the list of users. That is, in addition to the SMB pipe, we can directly connect to port 49668 and request the list of users via the DCERPC protocol. To do this, we need to patch the samrdump.py script so that it directly addresses the SAMR interface instead of the pipe. The players @vos and @Abr1k0s opted for a different solution. They used a ready-made walksam tool from the rpctools set, the only difficulty of which is using the flag RPC_C_AUTHN_LEVEL_PKT_PRIVACY instead of RPC_C_AUTHN_LEVEL_CALL. Alternative methods were to use atsvc, svcctl, dcom, and other interfaces. All of them allow arbitrary code execution and are closed by IDS rules. The shutdown interface was also closed. The most unusual way to solve this task involved remote search for user creation events using wevtutil:

192.168.30.50—RDP me

The task is simple: to connect via RDP with a known account and read the flag from the desktop. The difficult part is that most of the known RDP clients are blocked by IDS rules. The players received one of the following messages every now and then:

TOOLS [PTsecurity] xfreerdp/vinagre/remmina RDP client
TOOLS [PTsecurity] xfreerdp/remmina RDP client
TOOLS [PTsecurity] MSTSC Win10 RDP client
TOOLS [PTsecurity] MSTSC Win7 RDP client
TOOLS [PTsecurity] Rdesktop RDP client

Sometimes different RDP clients behave the same way: for example, many Linux clients are built around the same library. The task has several solutions.

The first one, which was originally envisaged, is a head-on solution. The player goes through different launch options or tries different clients and sees different IDS alerts. After traffic analysis, it becomes clear which packet is blocked by the IDS. Based on this, the player can draw a conclusion about how the rules work. The rules are triggered on certain channel sequences (channelDef) in the ClientNetworkData field and on the header order itself.

Going through the launch options of the xfreerdp client of the latest versions, the player may come across the echo option:

xfreerdp /v:192.168.30.50 /u:user /p:letmein +echo
And xfreerdp with exactly these parameters will slip past the IDS rules.

Another way was demonstrated by @vos, @Abr1k0s, and @astalavista—they connected to the server using the Mocha RDP Lite mobile client. A fundamentally different solution using netsed was found by @webr0ck. Netsed, like a regular sed, is able to replace network data on the fly. The player simply zero-filled all the channel names in the ClientData RDP package.

192.168.30.60—LDAP

The description contains an IP address with open port 389. There are no credentials in the task, but the LDAP service supports anonymous connections (bind). However, with a simple connection using the Python library ldap3, we see the IDS alert in three lines.

server = ldap3.Server('192.168.30.60', port=389)

connection = ldap3.Connection(server)

connection.bind()

TEST [PTsecurity] LDAP ASN1 single byte length fields prohibited

We captured the dump of our traffic and we see that the bind itself is successful, but the searchRequest that the library sent after that remains unanswered. The IDS rule is triggered on it.

The Windows utilities ADSIEdit and ldp, as well as the Linux utility ldapsearch, give similar results, but with different alerts:

TEST [PTsecurity] LDAP ASN1 1-byte length encoded found

TEST [PTsecurity] LDAP ASN1 2-byte length encoded found

TEST [PTsecurity] LDAP ASN1 4-byte length encoded found

The whole point turns out to be how the lengths of individual fields in LDAP messages are encoded. The byte x in the byte sequence 30 8x yy yy yy is responsible for the length of the length field in bytes. For example, the sequence 30 82 00 02 encodes two bytes of the length field 00 02. Thus, the players were required to try fields of a different length and find that the IDS is not triggered on the field of 3 bytes long. The flag is in the response among the namingContexts fields. The task implied the only solution, and only two of the players managed to do the task.

Results:

1 place: @vos—Apple Watch Series 6 + backpack

2 place: @psih1337—cash reward + backpack

3 place: @Abr1k0s—backpack

Author: Kirill Shipulin, Positive Technologies

APT31 new dropper. Target destinations: Mongolia, Russia, the U.S., and elsewhere

2021-08-03T07:38:00.003-07:00

Our pros at the PT Expert Security Center regularly spot emerging threats to information security and track the activity of hacker groups. During such monitoring in April 2021, a mailing list with previously unknown malicious content was sent to Mongolia. Similar attacks were subsequently identified in Russia, Belarus, Canada, and the United States. According to PT ESC threat intelligence analysts, from January to July 2021, approximately 10 attacks were carried out using the discovered malware samples.

Some of the files found during the study had rather interesting names ("хавсралт.scr" ["havsralt.scr"] (mong. attachment), "Информация_Рб_июнь_2021_года_2021062826109.exe") and, as the study showed, they contained a remote access trojan (RAT). A detailed analysis of malware samples, data on the paths on which working directories and registry keys were located, techniques and mechanisms used by the attackers (from the injection of malicious code to the logical blocks and structures used) helped correlate this malware with the activity of the APT31 group.

In this article, we will study the malware created by the group, focus in more detail on the types of droppers discovered and the tricks used by its developers. You may find the whole text of the research and indicators of compromise that can be used by cybersecurity specialists to identify traces of the group's attacks and search for threats in their infrastructure here.

Dropper

The main objective of the dropper, the appearance of the main function of which is shown in Figure 1, is the creation of two files on the infected computer: a malicious library and an application vulnerable to DLL Sideloading (this application is then launched). Both files are always created over the same path: C:\ProgramData\Apacha. In the absence of this directory, it is created and the process is restarted.

Figure 1. Overview of the dropper's basic function

At the second stage, the application launched by the dropper loads the malicious library and calls one of its functions. It is noteworthy that MSVCR100.dll was chosen as the name of the malicious library in all cases. A library with an identical name is included in Visual C ++ for Microsoft Visual Studio. It is available on almost all PCs, but in a legitimate case it is located in the System32 folder (Figure 2). Moreover, the size of the malicious library is much smaller than the legitimate one.

Figure 2. Parameters of the legitimate MSVCR100.dll

It is also worth noting the trick of the malware developers: by way of exports, the library contains names that can be found in the legitimate MSVCR100.dll. Without a doubt, this was done to make the malicious library as identical to the original version as possible.

Figure 3. Part of the exports of malicious MSVCR100.dll

However, the number of exports in the malicious sample is much smaller, and most of them are ExitProcess calls.

Below is an example of a call to a malicious function from the created library. After the call, control is transferred to the malicious code. Note that the names of malicious functions were most often those used during the regular loading of applications.

Figure 4. Calling a malicious function inside a legitimate application

During the analysis of malware samples, we detected different versions of droppers that contain the same set of functions. The main difference is the name of the directory in which the files contained in the dropper will be created. However, in all the instances studied, the directories found in C:\ProgramData\ were used.

The version of the dropper that downloads all files from the control server is worthy of particular note. Let's take a closer look. At the first stage, the presence of a working directory is also checked, after which connection is made to the control server and the necessary data is downloaded from it.

Figure 5. Checking for a directory

Communication with the server is not encrypted in any way, nor is the control server's address inside the malware. Downloaded files are written to the created working directory.

Figure 6. Creating files in the working directory

Figure 7 displays the code sections responsible for downloading all files from the server (the last reviewed case), while Figure 8 displays the code for loading the main library (first instance).

Figure 7. Downloading files from C2

Figure 8. Downloading a malicious library from C2

Examining the open directories of control servers revealed unencrypted libraries (Figure 9).

Figure 9. Encrypted and unencrypted libraries on the server

It is also worth noting that in some cases, particularly during attacks on Mongolia, the dropper was signed with a valid digital signature (Figure 10). We believe that this signature was most likely stolen.

Figure 10. Valid digital signature of a dropper

Malicious library

Execution commences with receipt of a list of launched processes. That said, this has no impact on anything and is not used anywhere. The library then checks for the presence of the file C:\\ProgramData\\Apacha\\ssvagent.dll. This is the encrypted main load downloaded from the server.

In fact, this is a 5-byte XOR with a key built into the library. Inside the binary file, the key is stored in the form xmmword with the constant 9000000090000000900000009h (the fifth byte is added to the memory by the malware itself using the direct address). In fact, encryption is performed with byte 0x9. After decrypting the C2 address, it connects to the control server and downloads the encrypted payload from it. Then the received data is saved in the file C:\\ProgramData\\Apacha\\ssvagent.dll, and the legitimate application ssvagent.exe is restarted. The main part of the described functions is presented in Figure 11.

Figure 11. Decrypting the C2 address, loading and launching a new instance of ssvagent.exe

If the payload has been loaded earlier, it is checked for an application that is already running. To do this, a mutex named ssvagent is created; if it has been created, the application ends.

The library then writes the legitimate ssvagent.exe to startup via the registry, as shown in Figure 12.

Figure 12. Persistence via registry key

After this, the file downloaded from the server is decrypted using a XOR operation with a 5-byte key. Then the decrypted data is placed in the application memory, and control is transferred to it.

Payload

The main library starts its execution by creating a package that will be sent to the server. Officially, the package is created from three parts:

main heading
hash
encrypted data

The research describes their structures (learn more).

To generate a hash, which is preceded by the main heading, the malware obtains the MAC address and PC name (the result of executing GetComputerNameExW). These values are concatenated (without using any separators), after which an MD5 hash is taken from the resulting value, which is then converted into a string. An example of hash generation is presented in Figure 13.

Figure 13. Example of hash generation

The third part of the package is then formed.

Figure 14. An example of a generated package

The format of a complete generated package is presented below. The main heading is highlighted in green; the hash, in red; the encrypted data, in yellow.

Figure 15. Encrypted package with all headings

Figure 16. Decrypting data from a specific position within a binary file

The generated package is encrypted with RC-4 with the key 0x16CCA81F, which is embedded in the encrypted data and sent to the server. After this, malware waits for commands from the server.

Let's take a look at the list of commands that the malware implements:

0x3: get information on mapped drives.

0x4: perform file search.

0x5: create a process, communication through the pipe.

0xA: create a process via ShellExecute.

0xC: create a new stream with a file download from the server.

0x6, 0x7, 0x8, 0x9 (identical): search for a file or perform the necessary operation via SHFileOperationW (copy file, move file, rename file, delete file).

0xB: create a directory.

0xD: create a new stream, sending the file to the server.

0x11: self-delete.

The code for processing the last command is particularly intriguing: all the created files and registry keys are deleted using a bat-file.

Figure 17. Code for removing all components

A more detailed description of the payload is available in the full report.

Attribution

During our study, we found a Secureworks report describing the APT31 DropboxAES RAT trojan. Analysis of the detected malware instances allows us to assert that the group is also behind the attack we studied. The criteria on the basis of which the attacks were attributed are detailed in the report (read more).

Conclusion

We analyzed new versions of the malware used by APT31 in attacks from January to July this year. The revealed similarities with earlier versions of malicious samples described by researchers, such as in 2020, suggest that the group is expanding the geography of its interests to countries where its growing activity can be detected, Russia in particular. We believe that further instances will be revealed soon of this group being used in attacks, including against Russia, along with other tools that might be identified by code correspondence or network infrastructure.

Follow the link to read the full report and get indicators of compromise. You can see more PT ESC reports on current cyber threats, new malware samples, activity of APT groups, hacker techniques and tools in the blog on our website.

Authors: Denis Kuvshinov, Daniil Koloskov, PT ESC Threat Intelligence, Positive Technologies

How to detect a cyberattack and prevent money theft

2021-07-19T03:54:00.007-07:00

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

Figure 1. String with the request to read the file /etc/passwd

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.

Figure 2. Example of event 4771 with error code 0x18

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.

Figure 3. Example of the Add Values event

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 "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:

● Starting processes:

− net.exe or net1.exe with the config command,

− wmic.exe with the commands 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

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:

Figure 4. Listing user 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.

Figure 5. Listing 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.

Figure 6. Listing services in Active Directory

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

Figure 7. DCSync attack traffic (Wireshark)

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.

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.

Figure 8. Legitimate request order in the traffic

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.

Figure 9. Code fragment of the Buhtrap ClipBanker trojan

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