How to Identify A Suspicious Process

I've attempted to compile a complete list based on SANS 504 and 508 to investigate a process. It was scattered knowledge across two courses. I have complied it here in one list. Here is the quick checklist of the Process Investigation.

User Case:

Lets say you are a Security Analyst who got an alert from an EDR about a Suspicious Process Or Help Desk Guy who is troubleshooting a problem a user complaint about on his computer about high resource utilization or a Joe whose granny told him that she restarted her Machine, but something is still wrong with her Computer.

1. Process Name

Malicious Processes name themselves to blend in with other processes so your eyes can’t detect it. Attackers will name their processes such as runddl32.exe or scvhost.exe. You didn’t notice what I did there ? Did you? I named runddl32 instead of rundll32 and I named it scvhost instead of svchost . Attackers are like that sneaky bastards, they will name their processes like that to blend in. Just like they say in Cyber Security that Security through Obscurity, attackers do the very same. they go after most commonly running processes that are ubiquitous in nature and name their processes like them. Mastering the art of hiding in the Plain sight.

No. of process instances:

We have established the context that attackers will try to impersonate the most commonly running legitimate processes. It’s important to know the process instances for such common processes. The System process (System.exe) has only a single running instance on a host. If you find two running processes with the name System.exe, then one of them will be an imposter. Explorer.exe process instances are based on the number of users logged into the machine. If a machine is used by a single user and you find two instances of Explorer.exe, then it’s a sign of a compromise and needs further investigation.

It gets difficult to know by heart which process will have how many instances. To make it easier SANS has a great Poster ‘Hunt Evil’ Whih talks about most commonly abused processes and their no of Instances and several other properties of a Process to inspect a Suspicious Process.

2. Process Signature

As per the Threat and Malware reports, the most of the malware in the wild is unsigned. its only 3 percent of the advanced malwares you will find to be signed. So when you find a suspicious process, check its Signatures. If its unsigned or signatures of the file don’t match up with the file date or signature don’t match with the product then its most probably some made up signatures. How can you do that?

The answer is Sigcheck. A open source tool by our favorite Digimon brother Sysmon.

3. Entropy ( compiled & compression check)

Entropy the order of disorder, the randomness or uncertainty what we learnt in Physics. Entropy can also be applied to a Suspicious Software. Generally a software should be unpacked and not compressed. Attackers like to compress their software to avoid detection and evade security controls.

Unpacked and Uncompressed software should have an entropy between 4–6. where as Encrypted, compressed, Zip files will have entropy near to value of 8 based on “Shannon’s Entropy” with 8 being a Maximum entropy Value.

We can again rely on Sysinternals Sigcheck to measure the entropy with the -a option.

Keep in mind that many legitimate files such as Word rooffice related documents or excel sheets they are compressed and they will generally will have a higher entropy. So only use this method on suspicious executables to avoid false Positives.

4. Process Path

Malware will try to blend in with legitimate image names but it will execute from abnormal location. This take a lot of experience to find which process should be running from which Location. but for starters, if you find a Suspicious process just look it up at Echo trail. the lookups are totally free and you can look up for any process to see its legitimate Path.

https://www.echotrail.io/insights

5. Parent Child Relation ship ,Orphan Processes and Sacrificial Processes

Understanding the Parent child and Grand Child relationship is crucial to finding if a proccess is legitimate or not. Understanding what spawned a process can reveal a lot. For example, most user apps are launched by Explorer.exe the Windows shell. But if you spot something like svchost.exe running under Explorer.exe, that’s a red flag.

💡 Why it matters:

• A process under Explorer.exe? Likely started after login.

• One under Services.exe? Probably launched at boot — could mean persistence.

• No parent at all? That’s rare and worth digging into — might signal code injection or something stealthy.

Orphan Processes: Processes without a Parent can also be a big red flag and worth looking into. In both Windows and Unix, it is unusual to see child processes without corresponding parents. This type of process is called an orphan process.

In both Windows and Unix, it is unusual to see child processes without corresponding parents. This type of process is called an orphan process.

Sacrificial processes: work by spawning child processes to run potentially dangerous code, providing many benefits beyond protection of the parent process. Sacrificial Processes provides an easy and safe place to inject code, makes passing code to other processes or systems easy, and facilitates clean-up since the attack can be segmented and processes killed as they complete However, the use of many child processes can look very peculiar when analysing memory, particularly because Cobalt Strike is heavily PowerShell-based. A classic attack pattern for this toolkit is PowerShell spawning multiple rundll32.exe processes.

6. Process Command Line

What is Process Command Line?

The process command line is the full string of text used to start a process, showing the executable name and any arguments or parameters passed to it.

Based on the definition I provided, analyzing a command line of a process is important for the same two reasons. To see if the process executing has the same name as the one being called in Command line. Attackers can impersonate a process looking after a legitimate one but its the command line where the exact name of the process can be revealed.

Secondly to know what parameters were passed onto the process. I have seen cases where a process like papercut is creating a Local User via parameters ‘net user’.

In the Past these commandlines were trackable only in memory and EDR tools can easily analyse the commandlines as well. but you don’t need those fancy tools to be analysing the command lines. your free Source of Truth ‘Sysmon’ Logs have these captured for you.

Living off the Land Binaries with the Fileless Less Behaviour rely on the Download Cradle Which is basically encoded command being passed through as a Parameter to the processes.

7. Process Start Time.

The time process was executed/Started can be interesting at times. Specially during timeline analysis. If you have a specific suspicious Process you are looking at and at the same time another Suspicious process execution is seen, this correlation can be interesting and it can be an interesting pivot point.

But in Memory analysis What I have learnt is processes impersonating other processes like the most common ones like svchost.exe, if all the svchost.exe starting at same time and only one svchost.exe starting 10–20 mins later that is an interesting process worth your suspicion and investigation.

8. ASEP locations

Auto Start locations are also known as AutoStart Extension Points (ASEPs). There are over 50 ASEP locations that a malicious file can place to reference it self to ensure it survives a Reboot and Hence a Form of Persistence for a Malicious Process. Most common ASEP are in the registry.

By far, the most popular ASEPs on the planet are the “run” Registry keys: Items listed in these keys are executed when a user logs on.

• NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run

• NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Runonce

• Software\Microsoft\Windows\CurrentVersion\Runonce

• Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run

• Software\Microsoft\Windows\CurrentVersion\Run

Less common, but equally lethal, is the Userinit key. SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Want to have persistence via ASEP without Admin privileges? %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

The above is not a registry but a location in the file system. Any shortcuts created in this folder will execute the representative binary upon user logon.

Tools for ASEP Detection: Tools like Registry Explorer, RegRipper have many common ASEP from Registry hive. Also tools like Autoruns and Kansa has the ability to provide this information at scale.

9. Windows Service

What is Services in windows?

Windows services are designed to run applications in the background without user interaction.

Legitimate services that are required at System Boot? DHCP client, Windows Event Log, Server and Workstation services are required at boot and must be started immediately without requiring user input. Services can be implemented as standalone executables or loaded as DLLs. To conserve resources, many service DLLs are grouped together and run under a smaller set of svchost.exe instances. svchost.exe is a Windows-generic service host process, and it is typical to see several running instances of svchost.exe (five or more is common).

Where are the service configuration are stored?

Service configurations, as well as device driver configurations, are stored in the Registry under HKLM\SYSTEM\CurrentControlSet\Services. The keys here provide the parameters for each service, including the service name, display name, path to the service’s executable image file.

Services as a Attack Vector:

Because services can be configured to reliably start at boot (often before the loading of antivirus), they are a very popular persistence vector. It also helps that the average Windows system can easily have over one hundred services registered, making it very easy to hide in plain sight. With administrator rights, it is trivial to either modify the Services Registry key or use the built-in “sc” command to create a service that auto-loads a malicious DLL or executable.

One of the classic APT examples of this technique is to add (or replace) the rarely.

10. Sch Tasks

Scheduled tasks provide an extremely granular means to create persistence in windows. The at.exe command long has been a core part of the hacker lexicon. Attackers can use Scheduled tasks as a way of persistence. So look for processes creating suspicious Scheduled tasks.

schtasks.exe

The schtasks.exe tool is an upgraded version of at.exe and has an immense number of features allowing tasks to be set and finely controlled. Tasks can even be set for specific Windows events, such as when a specific user logs on, allowing much more creativity for persistence over just using specific times

How to Detect Schtasks?

The Autoruns tool from Sysinternals will collect currently scheduled jobs from the task scheduler service. Also Windows event logging.

11.DLL Loaded

What is a DLL?

A DLL (Dynamic Link Library) is a type of file used in Microsoft Windows that contains code, data, and resources (like images or fonts) that can be used by multiple programs at the same time.

Attackers can exploit Loaded DLL by a process in following ways

Search Order DLL:

Search Order DLL Hijacking is a technique where an attacker places a malicious DLL in a location that is searched before the legitimate one when a program tries to load it.

How it works?

A program loads a DLL without using a full path (e.g., LoadLibrary("example.dll")).

Windows follows a search order to find that DLL (e.g., current directory, system folders, etc.).

If an attacker can drop a fake example.dll in one of the earlier-searched locations (like the current directory), the program loads the malicious DLL instead.

Phantom DLL Hijacking:

hijacking is a similar attack but uses the fact that some very old DLLs are still attempted to be loaded by applications even when they are completely unnecessary. In fact, some applications try to load very old DLLs that no longer even exist on modern Windows operating systems! If attackers can find such a DLL (and many are already documented), placing a properly crafted malicious file with the same name of that longforgotten DLL in the search path can lead to code execution.

DLL Side Loading:

This attack uses the Windows side-by-side (SxS) DLL loading mechanism to introduce an “updated” version of a DLL. SxS functionality is a legitimate feature of Windows and is used by many applications to prevent problems that can arise due to updated and duplicate versions of DLLs. SxS gives the ability to load updated DLLs but has few validity checks for these new DLLs and thus the loading mechanism can be abused due to missing DLLs, use of relative paths, and other shortcuts not taken into account by the application developer. This attack is often used to circumvent AV protections and provides an opportunity for a known good, even digitally signed, executable to be used as the persistence mechanism. The most notable example is the very popular PlugX RAT, which drops a legitimate executable (with a hash present in the NSRL known good hash database) and then uses SxS during runtime to load and construct a malicious DLL in memory. Amanda Stewart at FireEye wrote an excellent whitepaper describing the process.PlugX is not alone — a wide variety of remote access tools, such as NetTraveler, use similar techniques. Similar to other DLL persistence attacks, the best way to discover this behavior is to identify new executables and helper files added to the system during the attack (PlugX often creates three new files on the system).

Malicious DLL Detection:

Nearly all DLL hijacks require placing a new DLL and/or executable onto the file system. This presents a useful detection point since newly created DLLs and executables are rare on most systems. Paying attention to newly created files around a time of interest is a classic forensic timelining technique.

Memory forensics is another technique well suited to finding code running from unusual locations since all legitimately loaded code must come from disk. By looking for processes that should not be running, or those loading DLLs from strange locations, an analyst could easily find evidence of DLL hijacking in memory. Also note that hijacked DLLs tend to be the more obscure ones because the most common DLLs are already loaded in memory, preempting the loading of any evil versions with duplicate names (Windows first checks if a DLL is already loaded in memory before looking on disk). Added to this is code loaded through hijacking almost always performs other actions likely to draw the eye of an investigator. These could include reaching out over the network, creating named pipes, or injecting code into other processes. We will have many ways throughout the course to detect anomalous actions and any of them could lead back to a DLL in a strange location, and ultimately help you discover a DLL hijack attack.

12. Process Objects and Handles ( Reg, sockets etc)

Processes can have hundreds of associated objects. In fact, the preprocess limit on kernel handles is 2²⁴, so there can be a vast number of objects to review! Identifying a suspicious process object can help inform how much we trust a given process. The following objects can be reviewed:

DLLs: Dynamically Linked Libraries define the capabilities of a process. For instance, if a process needs to communicate via HTTP, it will load the “wininet.dll” file. In some cases, malware will load its own malicious DLLs to take control of a process.

Handles: A pointer to a resource, handles exist in many different forms. Some of the most important to memory analysis are:

• File handles: Identify which items in the file system or which I/O devices are being accessed by the process.Access files or I/O devices for instance a Process Might Open a file and use its handles to interact with it.

•Registry handles: These are the registry keys the process is reading or writing to. Already discussed above that registries can be interesting ASEP for Persistance.

• Mutex or semaphore handles: A mutex ensures only one process can access a resource at a time. Malware often sets a mutex to “mark” a compromised system and prevent reinfection by the same malware. Also called “mutants”, these objects control or limit access to a resource. For instance, a mutex might be used by an object to enforce that only one process at a time can access it. Worms commonly set mutexes as a way of “marking” a compromised system so that it does not get reinfected.

Threads: A process is just a container for all of the items that do the real work. Multiple threads run within every process interacting with various system objects.

• Memory sections: Every process has a collection of virtual memory pages where DLLs and files are loaded, and code and data are stored. The Virtual Address Descriptor tree (VAD) maintains a list of these assigned memory

sections.

•Sockets: These are network connection endpoints. Every network socket is assigned to a specific process, allowing us to trace back suspicious network activities.

13. Process Network Connections

A process network connection refers to any network activity (like sending or receiving data) that is initiated or handled by a specific process (i.e., a running program) on a system.

But before we go further, lets clear a confusion between the most common and similar terminology used alternatively that causes confusion.

What is the difference between a Named Pipe, Process Socket and a Process Network Connection?

🔹 What is a Named Pipe?

A named pipe is a method of inter-process communication (IPC) that allows data to be exchanged between processes on the same system, and occasionally over a network.

“Named” because it has a name in the file system (e.g., \\.\pipe\MyPipe in Windows or /tmp/mypipe in Linux).

Can be one-way or duplex (two-way).

Used by applications, services, and sometimes malware to communicate quietly between processes.

📎 Security Note: Named pipes are often used by attack tools (e.g., Cobalt Strike) for stealthy lateral movement within a network.

🔹 What is a Socket?

A socket is a software endpoint that allows a process to communicate over a network or locally using protocols like TCP or UDP.

It’s a programming interface that defines how to send/receive data.

Can be used for:

• Local IPC (e.g., Unix domain sockets)

• Remote communication (e.g., client-server over TCP/IP)

• Created using code like:

• socket(AF_INET, SOCK_STREAM, 0)

📎 Security Note: Malware often opens sockets to act as backdoors or to initiate command-and-control (C2) traffic.

🔹 What is a Network Connection?

A network connection is an active communication session between two systems or devices, typically over TCP or UDP, established using sockets.

• Represents an actual data exchange between a local and remote host.

Includes:

• Local address & port

• Remote address & port

• Connection state (e.g., ESTABLISHED, LISTENING)

• You can view them using tools like netstat, ss, TCPView, or Sysmon (Event ID 3).

There are several things to look for when analyzing network connections for suspicious activity:

• Suspicious ports.

• Suspicious connections

• Any process communicating over port 80, 443, or 8080 that is not a browser

• Any browser process not communicating over port 80, 443, or 8080

• Connections to unexplained internal or external IP addresses. For example, why did a process have a TCP connection to a system in Russia? External resources like IP reputation services can also provide additional context.

• Web requests directly to an IP address rather than a domain name

• RDP connections (port 3389), particularly if originating from odd IP addresses. External RDP connections are typically routed through a VPN concentrator.

• DNS requests for unusual domain names

• Workstation to workstation connections. Workstations don’t typically RDP, map shares, or authenticate to other workstations. The expected model is workstations communicate with servers. Workstation to workstation connections often uncover lateral movement.

14. Process Security Context

Security Identifiers:

Security Identifiers (SIDs) are unique identifiers assigned to objects by Windows systems and domain controllers. Behind the scenes, Windows uses these SIDs to reference specific accounts and to check security privileges for those accounts. SIDs will be unique within a Windows instance, and domain SIDs will be unique throughout the enterprise.

Every Process executed has a security Context to it. the Associated SID or the user name through which the Process was executed with. This is very important identifier to detect Suspicious Processes.

Our Web Browser Process should be running under the Security Context of a standard User not with Built in Windows Local account such as System or Local System etc.

Some SID/Security Context Suspicious Examples:

A system-based Process or Core Windows services (should never run under a normal user), such as svchost.ex,e shouldn’t run under normal user John. Lsass should also not run under a normal/standard user context, it should only run as the built-in System Account Context.

15. Process Creating Users

Process creating user accounts for persistence mechanisms. Powershell, net.exe, cmd.exe, or wmic.exe, or any other process like papercut.exe, is being used to create a user. Earlie,r we talked about investigating the command line of the process to see what parameters passed through the process. It's the same thing, but we are especially looking for a process creating a user account. In my IR Experiences, I have worked on paper cut process exploited to create a user account.

16. No of Process Instances on a Machine (Finding Suspicious Processes through Least Frequency Analysis/Stacking)

This approach is more aligned with threat hunting and is typically performed using a SIEM solution or by exporting logs from a machine and analyzing them in a tool like Jupyter Notebook. The primary purpose is to identify outliers and anomalies. In a normal baseline environment, there should not be any occurrence of malicious processes. Therefore, if you are hunting for a suspicious process, it should be rare in an enterprise environment.

You filter for Windows Event ID 4688, Sysmon Event ID 1, or both, and then sort the results based on the process name and its frequency of occurrence. The processes with the lowest frequency or rarest occurrence are considered anomalies and should be investigated. This is a commonly used technique in threat hunting.

This method is also effective when hunting for lateral movement. For example, you might observe user accounts that have rarely logged in or have never been seen before suddenly performing logins, which warrants further investigation. This least-frequency analysis approach is valuable across multiple types of threat hunts but requires a SIEM tool, a log explorer, or an environment like Jupyter Notebook.

17. Resource Utilization

For this, you simply use the Windows Native End Task and see all the processes and their relative resource usage. A normal process shouldn’t be consuming too many system resources, such as Memory or CPU. Even if it's a legitimate process like Chrome.exe or any other favorite web browser, if it's a single instance but utilizing too many system resources, maybe check for any network connections it is initiating and check it for all the things we discussed above. In short, you can find a process by simply seeing its resource utilization.

Now there is no simple way to do this at a Large Scale in your SIEM. We are mostly only taking the Windows Security logs as Application and System logs, which are noisy and difficult to find such behaviour.

There is one good way we can extract this information from any Windows OS. Windows keeps tracks of Processes and their Resource Utilization in a file called SRUM.dat.

SRUM: stands for System Resource Usage Monitor. It’s a feature in Windows introduced with Windows 8 and later, designed to track system and application resource usage over time. The data is stored in a file located at:

‘ %SystemRoot%\System32\SRUM’

What SRUM Tracks:

• Network usage (bytes sent/received by apps)

• Application activity (runtime and launch times)

• Power consumption

• CPU usage

• Battery impact

SRUM.dat file can be easily open in tools like Excel or for better experience can be opened in Time line explorer. This way you can find the Process Anamoly via Resource Utalization. SRUM.dat can also be used for Forensics as a way to find the execution artifact.

18: Windows Error Reporting ( wer)

Windows Error Reporting is a heavily underused artifact. Windows Error Reporting (WER) is a built-in feature in Windows that helps Microsoft and developers identify and fix software issues by collecting and sending diagnostic data when an application or system component crashes or encounters an error.

Why is it important for our Investigations and Threat Hunts? because attackers, when they create malware, it simply doesn't work on every system. Even with the battle-tested malware techniques, I have experienced the most reliable techniques like Metasploit. If you use the Migrate command for the DLL Injection to do a Privilege Escalation, at times in my personal experience, it crashed the shell access on the victim host.

Now, for such advanced DLL attacks, chances are the required logging wasn’t enabled or there were no Detection Rules in place to detect such advanced attacks, but all these attacks might have initially caused the system or the victim application to crash. With Windows Error Reporting, we can detect those. and also based on a Stacking and Least Frequency technique we discussed above, the system crashing events are least in Frequency and can also be an outlier for such advanced attacks.

WER files can be located at

• •C:\ProgramData\Microsoft\Windows\WER

• • %User Profile%\AppData\Local\Microsoft\Windows\WER (also check Default, Public, and All Users profiles).

These files can be opened in a Notepad. Or if you want a better Gui Experience, you can try to Open these files in Reliability Monitor.

WER at Scale:

if you want to analyze the Windows Error Reporting events in your enterprise at Scale, then Event ID 1001 is your friend. You can easily view this in SIEM given that the application logs are enabled.

19. Anti Virus and Defender Logs/ Alerts:

Our Good Old legacy friend, Anti Viruses are the first line of Defense. Even with advanced tools and techniques attackers use to evade detections, chances are the malicious Process might have some detection in your Anti Virus tools. Even during forensics Collection, the Forensic Triage tools like Kape will try to collect the artifacts from your Anti Virus. Even Time Line analysis tools have this targeted analysis that includes Anti Virus folder.

So take my word and don’t solely rely on your EDR, which attackers these days bypass it, if they do they might even hit some kind of detections in Anti virus or crash an application which will create a log inWER which we discussed just above.

For Windows Defender the logs we can routinely check to see the malicious Process is Event ID: 1116–9. These events are again perfect for threat hunting and you can easily do stacking / least frequency analysis in your SIEM to hunt for Malicious processes.

There are other things such as a Process Memory Sections and how it is exploited for Persistence, but to reach to that point of Investigation where you have to investigate a Process Memory Section you have already identified a malicious Process and you are doing a Deep Dive Memory Forensics at this point.

There are also WMI Event Consumers that are being used for persistence. But I think we can call it a Complete and detailed list Process Investigation checklist based on what we have discussed so far.