One common type of attack is spawning a malicious process in a tree under perfectly legitimate processes. Suspicion can be caused by the path to the executable file: malware often uses the AppData or Temp folders, which is not typical for legitimate programs. To be fair, some auto-update utilities run in AppData, so just checking the launch location isn't enough to confirm that a program is malicious.
An additional factor of legitimacy is a cryptographic signature: many original programs are signed by the vendor. You can use the fact that there is no signature as a method of identifying suspicious startup items. But then again, there is malware that uses a stolen certificate to sign itself.
You can also check the value of MD5 or SHA256 cryptographic hashes, which may correspond to some previously detected malware. You can perform static analysis by looking at signatures in the program (using Yara rules or antivirus products). And there is also dynamic analysis (launching a program in a safe environment and tracking its actions) and reverse engineering.
There are many signs of a malicious process. In this article, we will tell you how to enable auditing of relevant events in Windows, we will analyze the features that the built-in rule relies on to identify a suspicious process. InTrust is for collecting, analyzing and storing unstructured data, which already has hundreds of preset reactions to various types of attacks.
When a program is launched, it is loaded into the computer's memory. An executable file contains computer instructions and auxiliary libraries (eg *.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 for malicious code to get into memory and run, let's look at some of them.
The easiest way to start a malicious process is to have the user start it directly (for example, from an email attachment), then use the RunOnce key to start it every time the computer is turned on. This also includes βfilelessβ malware that stores PowerShell scripts in registry keys that are executed based on a trigger. In this case, the PowerShell script is malicious code.
The problem with explicitly launching malware is that it is a known approach that is easily detected. Some malware does trickier things, like using a different process to start executing in memory. Therefore, 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:Windowssystem32cmd.exe) or an incomplete path (for example, cmd.exe). If the original process is insecure, it will allow illegitimate programs to run. The attack can look like this: the process starts cmd.exe without specifying the full path, the attacker places his cmd.exe in such a place that the process starts it before the legitimate one. Once the malicious program is launched, it can in turn launch a legitimate program (for example, C:Windowssystem32cmd.exe) so that the original program continues to work properly.
A variation of the previous attack is a DLL injection into a legitimate process. When a process starts, it finds and loads libraries that extend its functionality. Using DLL injection, the attacker creates a malicious library with the same name and API as the legitimate one. The program loads a malicious library, which, in turn, loads a legitimate one, and, as necessary, to perform operations, calls it. The malicious library begins to act as a proxy for a good library.
Another way to put malicious code into memory is to insert it into an insecure process that is already running. Processes receive input data from various sources - they read from the network or files. They usually perform validation to make sure the input is legitimate. But some processes do not have proper protection when executing instructions. With such an attack, there is no library on disk or an executable file with malicious code. Everything is stored in memory along with the running process.
Now let's look at the method of enabling the collection of such events in Windows and with the rule in InTrust, which implements protection against such threats. First, let's activate it through the InTrust management console.
The rule uses the process tracking capabilities of Windows OS. Unfortunately, enabling the collection of such events is far from obvious. You need to change 3 different Group Policy settings:
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 can detect previously unknown threats that exhibit suspicious behavior. For example, one can identify Dridex malware. Thanks to the HP Bromium project, we know how such a threat works.
In its chain of events, Dridex uses schtasks.exe to create a scheduled task. Using this particular utility from the command line is considered very suspicious behavior, similarly it looks like running 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 relevant :
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 combination and in 99% of cases are used for not entirely noble purposes. Such a list of actions includes, but is not limited to:
- Processes running from unusual locations, such as user temp folders.
- Well-known system process with suspicious inheritance - some threats may try to use the name of system processes to go unnoticed.
- Suspicious executions of administrative tools such as cmd or PsExec when they use local system credentials or suspicious inheritance.
- Suspicious shadow copy operations are a common behavior of ransomware before encrypting the system, they kill backups:
- Through vssadmin.exe;
- Through WMI. - Registry dumps of entire registry hives.
- Horizontal movement of malicious code when running a process remotely using commands such as at.exe.
- Suspicious local group operations and domain operations using net.exe.
- Suspicious firewall activity using netsh.exe.
- Suspicious ACL manipulation.
- Using BITS to exfiltrate data.
- Suspicious WMI manipulation.
- Suspicious script commands.
- Attempts to dump safe system files.
The combined rule works very well for detecting threats such as RUYK, LockerGoga, and other ransomware, malware, and cybercrime toolkits. The rule has been verified by the vendor in combat environments to minimize false positives. And thanks to the SIGMA project, most of these indicators produce a minimum number of noise events.
Because in InTrust this is a monitoring rule, you can execute a response script as a response 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 the telemetry related to the event: PowerShell scripts, process execution, manipulation of scheduled tasks, WMI administrative activity and use them for postmortems in case of security incidents.
InTrust has hundreds of other rules, some of them are:
- Detecting a PowerShell Downgrade Attack - When someone is deliberately using an older version of PowerShell because in the older version it was not possible to audit what was happening.
- High privilege logon detection - when accounts that are members of a certain privileged group (for example, domain administrators) accidentally or due to security incidents interactively log on to workstations.
InTrust allows you to use the best security practices in the form of predefined detection and reaction 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 conducting a pilot or obtaining distributions with temporary licenses via on our website.
Subscribe to our , we publish there brief notes and interesting links.
Read our other articles on information security:
(popular article)
Source: habr.com