One of the most common types of attacks is the spawning of a malicious process in a tree under quite good processes. The path to the executable file can cause suspicion: often malware uses the AppData or Temp folders, which is uncommon for legitimate programs. It's fair to say that some auto-update utilities run in AppData, so just checking the launch location isn't enough to claim the program is malicious.
An additional factor of legitimacy is the cryptographic signature: many original programs are signed by the vendor. You can use the absence of a signature as a method to identify suspicious startup items. But then again, there is malware that uses a stolen certificate to sign itself.
You can also check the value of the MD5 or SHA256 cryptographic hashes, which may correspond to some previously detected malware. You can perform static analysis by looking at the signatures in the program (using Yara rules or antivirus products). And then there is dynamic analysis (running a program in a safe environment and tracking its actions) and reverse engineering.
There can be a lot of signs of a malicious process. In this article, we will describe how to enable auditing of the corresponding events in Windows, we will analyze the signs that the built-in InTrust rule relies on to identify a suspicious process. InTrust is a CLM platform for collecting, analyzing and storing unstructured data, which already contains hundreds of predefined responses to various types of attacks.
When a program is launched, it is loaded into the computer's memory. The executable file contains computer instructions and auxiliary libraries (for example, * .dll). When a process is already running, it can create additional threads. Threads allow a process to execute different sets of instructions at the same time. There are many ways malicious code can penetrate memory and launch it, let's look at some of them.
The easiest way to launch a malicious process is to force the user to launch it directly (for example, from an email attachment), then use the RunOnce key to launch it every time the computer is turned on. This includes "fileless" malware that stores PowerShell scripts in registry keys that are triggered-based. In this scenario, the PowerShell script is malicious code.
The problem with running malicious software explicitly is that it is a known approach and is easily detected. Some malware does more subtle things, such as using a different process to start executing in memory. Hence, a process can create another process by running a specific computer instruction and specifying an executable (.exe) file to run.
The file can be specified using a full path (for example, C: \ Windows \ system32 \ cmd.exe) or an incomplete path (for example, cmd.exe). If the original process is unsafe, it will allow illegitimate programs to run. The attack may look like this: the process launches cmd.exe without specifying the full path, the attacker places his cmd.exe in such a place so that the process starts it before the legitimate one. After launching a malicious program, it, in turn, can launch a legitimate program (for example, C: \ Windows \ system32 \ cmd.exe) so that the original program continues to work properly.
A variation of the previous attack is DLL injection into a legitimate process. When a process starts, it finds and loads libraries that extend its functionality. Using DLL injection, an attacker creates a malicious library with the same name and API as the legitimate one. The program downloads a malicious library, and it, in turn, downloads a legitimate one, and, as necessary, calls it to perform operations. The malicious library begins to act as a proxy for the good library.
Another way to put malicious code into memory is to insert it into an unsafe process that is already running. Processes receive input from various sources - they read from the network or from files. They usually check to make sure the input is legitimate. However, some processes are not adequately protected when executing instructions. In such an attack, there is no library on disk or an executable file with malicious code. Everything is stored in memory along with the process being exploited.
Now let's figure out the methodology for enabling the collection of such events in Windows and with the rule in InTrust, which implements protection against such threats. First, we activate it through the InTrust management console.
The rule uses the process tracking capabilities of the Windows OS. Unfortunately, the inclusion of the collection of such events is far from obvious. There are 3 different Group Policy settings to change:
Computer Configuration> Policies> Windows Settings> Security Settings> Local Policies> Audit Policy> Audit process tracking
Computer Configuration> Policies> Windows Settings> Security Settings> Advanced Audit Policy Configuration> Audit Policies> Detailed Tracking> Audit process creation
Computer Configuration> Policies> Administrative Templates> System> Audit Process Creation> Include command line in process creation events
Once enabled, InTrust rules allow detecting previously unknown threats,that exhibit suspicious behavior. For example, you can identifyThe Dridex malware described here . Thanks to the HP Bromium project, we know how such a threat works.
Dridex uses schtasks.exe in its chain of actions to create a scheduled task. Using this particular utility from the command line is considered very suspicious behavior, similarly launching svchost.exe with parameters that point to user folders or with parameters similar to the "net view" or "whoami" commands. Here is a snippet of the corresponding SIGMA rule :
detection:
selection1:
CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'
selection2:
ParentImage: '*\svchost.exe*'
CommandLine:
- '*whoami.exe /all'
- '*net.exe view'
condition: 1 of themIn InTrust, all suspicious behavior is included in one rule, because most of these actions are not specific to a particular threat, but rather are suspicious in a complex and in 99% of cases are used for not entirely noble purposes. This list of actions includes, but is not limited to:
- Processes running from unusual locations, such as custom temporary folders.
- Well-known system process with suspicious inheritance - some threats may try to use the name of system processes to go unnoticed.
- Suspicious execution of administrative tools like cmd or PsExec when they use local system credentials or suspicious inheritance.
- — - , :
— vssadmin.exe;
— WMI. - .
- , at.exe.
- net.exe.
- netsh.exe.
- ACL.
- BITS .
- WMI.
- .
- .
The combined rule works very well for detecting threats like RUYK, LockerGoga and other ransomware viruses, malware and cybercrime toolkits. The rule has been verified by the vendor in production environments to minimize false positives. And thanks to the SIGMA project, most of these indicators produce the minimum number of noise events.
Because in InTrust this is a monitoring rule, you can execute a response script as a reaction to a threat. You can use one of the built-in scripts or create your own and InTrust will automatically distribute it.
In addition, you can check all telemetry related to the event: PowerShell scripts, process execution, scheduled task manipulation, WMI administrative activity and use them for postmortems in security incidents.
InTrust has hundreds of other rules, some of which are:
- Identify a downgrade PowerShell attack - when someone deliberately uses an older version of PowerShell because the older version did not have the ability to audit what was happening.
- High privilege logon detection - when accounts that are members of a particular privileged group (for example, domain administrators) log on interactively to workstations by accident or due to security incidents.
InTrust allows for best security practices in the form of predefined detection and response rules. And if you think that something should work differently, you can make your own copy of the rule and configure it as needed. You can send an application for a pilot or receive distributions with temporary licenses through the feedback form on our website.
Subscribe to our page on Facebook , we publish short notes and interesting links there.
Read our other articles on the topic of information security:
How InTrust can help reduce the frequency of unsuccessful authorization attempts via RDP Detecting an ransomware attack, gaining
access to a domain controller and trying to resist these attacks
What is useful to get from the logs of a Windows workstation (popular article)
Tracking the life cycle of users without pliers and tape
And who did it? We automate information security audit
How to reduce the cost of ownership of a SIEM system and why you need Central Log Management (CLM)