Malicious Process Detection 1 — Log Analysis — Security | Sysmon | T1055
With the malicious process detection blog post, I will explain what we should pay attention to when analyzing the event through the existing logs. Process injection contains close to 11 sub-techniques. I will not go into these details here. The goal is to make an inference over the logs. This attack technique can be used to evade security devices or to privilege escalation.
Processes are used to do certain jobs on Windows systems. Some of these processes are called by the operating system, and some are called automatically or manually by users. It can be summoned by malicious hackers as well as by users.
The key here is where you got the log from. For example, you can access the hash value of the called process in the logs obtained with sysmon and detect whether any injection operations are performed on this process via this hash. But you cannot do this with the security log.
There are certain methods to understand whether a process is harmful during log analysis. Some of them are as follows.
- Cases where the process name is unusual.
For example, typing svchot.exe instead of svchost.exe. Or typing lsas.exe instead of lsass.exe.
2. Process Path is unusual.
As you can see in Visual 1.1, there is the process name and path (C:\Windows\System32\whoami.exe) opposite the New Process Name value. This path is typical for whoami.exe. If this process was in the C:\whoami.exe path, would this activity be suspicious?
Normal > %SystemRoot%\System32\svchost.exe
Abnormal > %SystemRoot%\svchost.exe
This is a suspicious activity for any process that is not in its default location.
3. Processes connecting to the outside should be our sensitive point. Where are you going, bro?
As you can see in Visual 1.2, many processes perform this activity legally. This is not always the case. This stage can often be an indication that the attackers are approaching the final stages of the attack. Processes connecting to the outside should be monitored.
The linked address should be evaluated by intelligence sources. A process running for X provides a connection to the outside. You are researching this and you get a domain. You chase intelligence for the domain for 2–3 minutes. It doesn’t seem like an abnormal activity to you when the printouts are clean.
The whois query makes a huge difference here. There may not be negative information for a newly purchased domain. Or could it not be the domain’s first fault?
Note: Let’s say you gather intelligence from IBM x-force. Here comes risk 1. You checked whois, there is no problem, this domain has been actively used for a long time. If you are controlling the domain, let’s also check the DNS record separately. If you are providing control over IP address, let’s provide Passive DNS control. Different IP addresses and domains associated with the domain or IP address are common. If there is a risky situation regarding the domains and IP addresses they are associated with, this should be included in the event. (DGA and fast fluxing techniques can add different perspectives. These two techniques need to be investigated a little.)
Note2: There are 6–7 different platforms that I use to gather intelligence. But I get the greatest benefit from searching intext:Ip_Address.(google dork)
Intelligence is something different, so I wanted to give small notes.
4. The relationship between parent process and child process can be distinctive. Abnormally related processes should be considered suspicious. Let’s take a quick look at an example.
Normal for svchost.exe is parent process services.exe. The usual parent process for lsass.exe is wininit.exe. It may not be so clear for some processes. But the information it gives us can be very useful.
If svchost.exe’s parent process is a different value, this is suspicious activity.
5. Who does this process depend on? So who was it employed by?
The user running the process will give us important information. Let’s continue with two examples.
svchost.exe generally works with Local System, Network Service, or Local Service, but different situations can be encountered. It is necessary to look at everything differently with the eye of a suspect and to initiate an investigation process for the incident.
Lsass.exe process is generally called by Local System. If someone else is calling, this may be a problem. Investigate now!
6.If there is a hash, our job is very easy.
To see the process hash, we need to log through sysmon. There is no hash in the security log.
Quality log sources are needed for quality analysis. Our log sources make an incredible difference in analyzing an event and even detecting an event (writing a rule).
The scope of the rule you will write for the log you get from Security and the scope of the rule you will write for the log you get from sysmon are very different. This gives you extra benefit in reducing false-positives. Increases employee productivity.
Note: One of the great platforms where you can collect intelligence with hash value is virustotal.com.
You can see hash values such as MD5 and SHA256 in Visual 1.3. These hash values belong to the whoami.exe file. (OriginalFileName)
For more, you can visit Miter att&ck address.
See you later in the series.
To be continued.
